I’m starting to learn macOS development and I’m a bit torn on SwiftUI. As someone who’s primarily done web development the last few years, and comfortable with React, SwiftUI is pretty appealing from the standpoint of being a similar mental model.<p>On the other hand, it doesn’t quite feel ready. SwiftUI seems to be missing enough components that I end up needing to know how to use the existing AppKit stuff with autolayout, or know how things work under the hood to debug SwiftUI oddities. On top of that, there are few resources out there for learning macOS dev specifically — tons of stuff for iOS, which sorta translates, but not perfectly. I’ve been learning from the Hacking with macOS book, which is very good, and plenty of trial and error.<p>The other ding against SwiftUI for Mac dev seems to be that it’s only supported in Catalina, and it seems an awful lot of Mac users have held back from updating, so the user base might be diminished.<p>Most of these seem like temporary problems, but as a newcomer to this world it’s hard to tell if it’s too early to commit to SwiftUI.
One thing I am a bit upset is how Apple approaches SwiftUI / Combine, as these two to me, are foundational pieces to the Swift language ecosystem. Particularly:<p>1. There is no way to bundle SwiftUI / Combine to the app so you can ship to earlier iOS versions, making development exclusively done on newer OS version. More over, for any bug fixes on SwiftUI / Combine, you have to wait for the OS updates for the fix. Just updating your Xcode is not enough.<p>2. While the SwiftUI required language features are all upstreamed to Swift language, and core developers have been patient to articulate why. If SwiftUI / Combine development was done in public (i.e. open-source), bug-fixes and language improvements will be much smoother.<p>To Apple, point 2 probably is a big leap. But they've done Swift open-source release, and it works relatively well with a sizeable open-source ecosystem on other platforms now.
These are good changes. “View builders” are quite powerful but it was always strange to be able to get so far so fast and then be hit by a weird limitation involving fairly basic logic. Fortunately, there are work-arounds.<p>I’ve ported a few different AppKit interfaces to SwiftUI “1.0” on the Mac and the tech is pretty impressive; I am looking forward to exploring the Big Sur version of it.<p>The biggest problem they have right now is that subtle but important <i>behaviors</i> are being lost in the SwiftUI versions of controls, and they need to add them back. You start to notice how maybe keyboard focus isn’t quite the same, certain key bindings don’t work, tooltips aren’t present, etc. and it adds up. It is really quite easy to get something <i>working</i> in SwiftUI right now but it is really hard to <i>polish</i> it to the standards that Macs used to have.
The amount of compiler magic used by SwiftUI is staggering. By itself it's not a deal breaker, but closed source makes it almost impossible to understand what is going on.
I really wonder where this is going.<p>Swift had to interop with objective-c right from the start, which itself had to interop with C.
SwiftUI feels like a wrapper over UIKit (or at the minimum CoreFoundation).<p>All in all, it seems impossible that so many layers of compromise over so many years, can lead to anything clean in the long run.
Love the ability to remove AnyView, that was a really confusing one for me the first time I saw it.<p>I'm really impressed by SwiftUI, it seems like Apple took a couple hundred really good UI engineers and threw them at this. Coming from a web background it's really refreshing to have these APIs. Swift as a language is part of it, changes to <i>JavaScript</i> like those mentioned in this article would be hard to come by (for good reason!)
Honestly, I think Swift UI's mess of syntax really makes the case for lisp. Four different function calling syntaxes? Trailing function calls? Jesus Christ.