Have to admit that it bothers me: the amount of criticism SwiftUI gets from the developers I follow on Twitter, a few blogs, and a few podcasts that boils down to “it sucks” or “it’s a boondoggle” or “Apple has lost it”. It feels like these folks gave it a small try, then wrote it off as insufficient for the complex apps they write. Thing is, how many of them have started writing an application from scratch, lately? And how many of them have built up a deep intuition about AppKit or UIKit over many years and don’t realize they have to set all that aside with the new framework? How many of them remember the months of struggle they went through to do the simplest things with AppKit? SwiftUI will not help you write better UIKit apps, or help smooth off the edges of AppKit. You have to unlearn all that in order to give SwiftUI a fair shake.

Let’s say you’re a new developer (at least to the platform) and you want to write a Mac App. AppKit or SwiftUI? AppKit will let you do everything that’s possible to do, sure, but to do any of that sophisticated “non-toy” stuff requires even more work then to figure out how to do something similar-enough with SwiftUI. I think you can get a lot further a lot faster with SwiftUI both in terms of the application you want to write, and in terms of your intuition about how to go about it, how to troubleshoot, how to adjust your initial expectations about what a desktop app should act like given your current skills. Writing an app is a process, obviously enough. An old timer tells you your app isn’t mac-like in some specific way? Great! Now you have new and interesting challenges.

AppKit is difficult and non-obvious (responder chain, delegates, layers, autolayout, nibs, storyboards, events, UI validation) until you “get” it, at which point you kinda understand the underlying culture of it. Thing is, the more you understand it, the more you realize that culture is built on Objective-C’s dynamic nature. Swift is engineered to participate in that domain (amazing in itself, I think), but by its nature it doesn’t help you understand the fundamental message-passing paradigm underneath AppKit. How many practitioners know about message-send vs function-call method dispatch? Do you really need to know that to kinda “get” the responder chain? That kind of stuff never comes up in SwiftUI. I don’t think it needs it. If you do, based on your intimate knowledge of the platform, you’re going to see SwiftUI as extremely limited.

Let’s say you can’t make the perfect Mac App with SwiftUI (perfect being something that provides the affordances common 10 to 20 years ago and still good ideas today), but you can get close. If you’re just starting out, you don’t even know what a perfect Mac app is, where you should have keyboard shortcuts, when to use an inspector vs. a modal form, etc, etc. You have to get something that functions, and then you refine and learn and refine: see someone else’s app and think, “I should do that,” or “I never noticed before how many apps do that, I should, too”. For the most part, if you can’t quite get it done in SwiftUI, the fallback to NSRepresentable is more straightforward then doing everything in AppKit. You can find good examples for, say, how to embed WKWebKit in SwiftUI.

My own experience with SwiftUI is that I make things super complicated for myself, paint myself into a corner, then step back and realize that there’s a simpler way, and reduce my code down to something simple. Part of the process is that SwiftUI makes it easy to iterate on UI designs so that you can make a lot of mistakes in a short period of time.

It’s not that either SwiftUI or AppKit is better than the other for some notion of better, its that you don’t have to disparage the one you’re not inclined to use. You don’t even have to say, “It’s not for me.” How about, “It’s a really neat system. I kinda get the idea of it. Useful! Hey, how do you do this one thing?”