Friday, August 11, 2023

AppKit vs. SwiftUI: Stable vs. Shiny

Milen Dzhumerov:

Mitchell Hashimoto has been working on a new cross-platform terminal written in Zig and posted a update on the project’s progress. […] So, usage of SwiftUI constrained the product to have bugs and missing features.


Because of its maturity, AppKit does not change often nor significantly: it provides a stable foundation to build upon. Desktop OS innovation is quite slow as resources are focused on mobile and spatial. In turn, this means lower likelihood of breaking changes on each major release and more time to focus on your product.


SwiftUI is tackling a much harder problem along multiple dimensions[…]


SwiftUI can be thought of as a unifying rewrite of AppKit and UIKit, so the usual rewriting caveats, risks and benefits apply.


7 Comments RSS · Twitter · Mastodon

Old Unix Geek

"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 ). 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.

Old Unix Geek

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.

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.

Leave a Comment