In Praise of SwiftUI
In Praise of SwiftUI
26th May 2026 • 1,323 words • 6 minutes reading time.
#AppKit
#SwiftUI
#UIKit
Recently, I have seen multiple posts on Mastodon suggesting that SwiftUI is a failure, that nobody is using it, and that Apple should have focused on improving or replacing AppKit and UIKit instead of wasting everyone's time with SwiftUI. While I have great respect for some of the people saying these things, I disagree. I love using SwiftUI, I think a large number of developers are using it, and I want to explain what I find so great about it.
Perhaps one problem was the name. Yes, it allows you to define your user interface in Swift, but so do AppKit and UIKit. For me, the part that I miss most when going back to work on an older project is the data flow and the reactive nature of SwiftUI, and that's not reflected in the name at all.
Data Flow
I have written several articles about SwiftUI's data flow. The most recent one was in 2023 and it's still valid today: SwiftUI Data Flow 2023. I won't repeat all the details here, but SwiftUI gives us features that allow for concise and logical data control, while making it clear which view owns the data and provides the single source of truth.
The reactive aspect of SwiftUI feels like magic! It allows me to have something like a stored setting with a default value, connected to a menu item with a checkmark, a toggle in a settings window, a button in the toolbar, and a switch on the main interface. SwiftUI keeps these all in sync without any effort on my part. This sort of flexibility was a lot of work in AppKit and UIKit, and it was easy to end up with sections of the UI out of sync with the data. In AppKit apps, you could use Cocoa Bindings, but these were tricky to set up, not good with source control and totally opaque to any developer new to the project.
User Interface
Let's go deeper into the UI part. AppKit and UIKit have two options for creating user interfaces. You can either build graphically in Xcode's Interface Builder, or write all the interface in code. The "interface-in-code" lobby has always been very vocal and while I only ever did this for small sub-views, I can see part of the appeal. It's definitely better for source control as the interface is saved as text instead of in Xcode's strange XML that changes frequently for no apparent reason. But it's also a lot of code to write, and it doesn't give the interface positioning guidelines and the easy access to interface element properties that Interface Builder provides. However, unlike SwiftUI, both these methods give you pixel perfect control over the positioning, even if AutoLayout frequently drove me to distraction.
SwiftUI takes a very different approach and to some extent, it takes the power away from the developer and insists that Apple knows best. This means that when designing apps for different platforms, you don't have to remember the differences between the AppKit and UIKit versions of a control and you don't have to apply the different interface guidelines. SwiftUI applies styling and behavior for each platform, but this doesn't always give the result that people want and expect.
Paulo Andrade wrote an article recently titled Using SwiftUI to build a Mac-assed App in 2026. He thoughtfully detailed several ways in which SwiftUI fails to create the Mac experience that we have learned to expect. A lot of his points were to do with how the app indicated selections, but he also covered toolbars, drag & drop and keyboard shortcuts. While I understand what he's saying, and agree that SwiftUI and AppKit provide different experiences, I would argue that the Mac experience has changed many times and in lots of ways over the years. We developers are familiar with the small details and notice the changes, but to most users, this is just how Mac software is now. I got my first Mac in 1985, so I may have a broader perspective on this than most people. I do agree with his point that the Mac doesn't seem to matter inside Apple these days, but I also think it's part of the general trend of Apple rushing to release the big yearly OS updates and not taking the time to test and polish them, which lowers the quality of all their software, not just macOS or SwiftUI.
AI
Critics of SwiftUI are using AI as an excuse to go back to AppKit or UIKit. There is no doubt that these older frameworks require a lot more boilerplate code, especially if you're designing the interfaces in code. The AI proponents argue that if AI is writing all this verbose code, then there is no need for the more concise SwiftUI. While I have started using AI to write some code, I still review every line and the more the AI writes, the harder this becomes and the more likely it is that there will be un-detected bugs.
There's no doubt that right now, the various LLMs have had access to a lot more AppKit and UIKit code than they have SwiftUI code. This is purely a factor of the ages of the frameworks. But that...