AppKit vs. SwiftUI: Stable vs. Shiny

"But over time, new abstractions become necessary"

[Citation needed]

There have been many "declarative UIs" for Haskell over the years. They all sounded good. None really succeeded.

AppKit wasn't perfect when I last used it. They could have more usefully spent the time fixing it instead.

So, usage of SwiftUI constrained the product to have bugs and missing features. But why are developers choosing to use SwiftUI if it’s the source of such problems?

To answer that, let’s rewind back to June 2022.

WWDC 2022: The SwiftUI Vision

At the Platforms State of the Union session during WWDC 2022, Josh Shaffer set out the vision of the future platforms:

The Objective-C language, AppKit and UIKit frameworks, and Interface Builder have empowered generations of developers. These technologies were built for each other and will continue to serve us well for a long time to come.

But over time, new abstractions become necessary.

A bit later in the session, he clearly communicated the direction, so that developers know where to invest:

The best way to build an app is with Swift and SwiftUI.

Translation: we should use SwiftUI because Apple management said so. There was a time when Apple recommended writing Mac Apps in Java. Not saying it will turn out the same but be careful because “everything will get better next year” may not ever happen and failure is a real possibility. Apple isn’t shy about encouraging developers to adopt a technology to essentially be their Beta testers.

The problem with "declarative" UI frameworks are (at least) threefold:

1. They aren't actually "declarative". They are procedural/functional, as in you write a procedure that builds the UI (fluent builder APIs) What is meant by "declarative" is that the structure of the code somewhat matches the structure of the tree of objects rendered on screen. This matching is actually the good part, but achieving it this way has major negative consequences.

2. UIs are not a pure function of their model (See https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html ). One of the many places this conceit breaks down is that the major architectural feature of UIs, connecting the UI with the model, has to be hidden magic. Hiding your architecture in magic tends to be a bad idea.

3. Last not least, blowing up and rebuilding your skyscraper each time you turn a single light on or off doesn't just appear to be a bad idea superficially, it also leads to the UI being inherently unstable, when it should be inherently stable.

Specifying UI remains a conundrum. Doing it in data (IB, HTML, XML) is great for tooling and/or "declarativeness", but tends to fall down in ability to abstract and integration with code. Doing it in code got you that integration and ability to abstract, but used to mean writing procedures that configure and connect the pieces in a piecemeal and very indirect fashion that is both verbose/clunky and difficult to read.

IMHO, the solution is to adapt languages to actually be able to express both the building and the connecting naturally, so you have that direct mapping without having to pretend things that aren't true and thus come back to bite you later.

The "settings" app in Sonoma is still horribly broken.

Thanks for the link, Marcel.

Lots of “SwiftUI is buggy” posts don’t include source to demonstrate the authors know left from right. That large diff for the full screen feature shocks me, having written similar window resizing and leveling features… back in the second release.

That WWDC video also implies that SwiftUI is not such a great fit for the Mac:

> A powerful UI framework provides abstractions that make it easy to describe your interface, to populate it with data, and to keep it up to date. It should scale well with complexity. And it should be designed for the platform you're targeting, giving you full access to the power of the device. Your UI framework should help you make your app feel familiar and intuitive. It should make it easy to create standard controls and native interaction patterns, with options for advanced customization. And it needs to have an expressive API that allows you to quickly prototype your ideas and see the results across a range of devices.

https://developer.apple.com/videos/play/wwdc2022/102/?time=1079

In favor of the imperative frameworks

1. async await has been great for them
2. they still have loads of room for improvement,
3. gettting apps to 'feel' great unavoidably requires loads of tweaks and customisation points, SwiftUI can't compete here.

I think Apple's software management has seen this and they are still investing in the the imperative frameworks teams.