Tuesday, October 22, 2019

SwiftUI Is Still the Future

Brent Simmons:

We very much want to use SwiftUI, and we believe it’s the future of Mac and iOS development — but emphasis should be on future, because it’s not quite ready in the present.

Which should surprise nobody, given that it’s so new. But I thought it might be interesting to know exactly what issues we ran into when using it.

It’s no secret that the available controls and features are much more complete for watchOS than for iOS or macOS. But this post is an example of some limitations and bugs around areas that you would expect to work.

Overall, SwiftUI seems less suited than Swift itself to incremental adoption because, although you can make a hybrid UI that includes regular Cocoa views, it looks like you can run into a dead end where you have to back out and redo the container/controller as well.

Update (2019-10-23): Jeff Johnson:

“SwiftUI will be great next year” is the new “Catalyst will be great next year”.

Colin Cornaby:

Important distinction: SwiftUI isn’t wrong, it’s just small. There isn’t really a downside to release a small, base API early.

Catalyst is kind of the opposite to this. Release everything, and then try and pick up the pieces afterwards. You get the advantage of having all your API, but the downside of it not working right. That’s harder to pivot from without breaking things.

Jason Brennan:

I was quite surprised to find it doesn’t offer any rich text display or editing. You can style text with fonts and colours and the like, but the style applies to the whole run of text. There’s no equivalent components for creating a rich text editor in SwiftUI yet.

1 Comment RSS · Twitter

My major issue at this point is that macOS is a second class citizen.

One major difference when designing for macOS, is that it very common to support multi-selection in list (unlike iOS where multi-selection is non-existant).
With Cocoa Binding, multi-selection and multi-editing was supported from day 1. Today, Swift UI don't support multi selection (trying to drag two items at once in a List make it crash)

An other example, List selection is poorly implemented. Each time the selection change, the whole list is recomputed. With big data set, it make them plainly slow. This is not a deal on iOS as you can't change selection easily, but on macOS, there is a 'arrow up/down' keys design for that.
And there is plenty of other macOS issues. Why is SFSymbol not supported on macOS ? PopUp panels don't support semi-transient behavior (which is the most commonly used behavior, event by Apple apps), …

Maybe SwiftUI 2 will improve the situation, but until then, I'm not going to lose time debugging it.

Leave a Comment