Last Week on My Mac: Why SwiftUI?

Most days I watch sheep in the fields nearby, often seeing a ewe or two leading a long file of followers from one patch of grass to another. We may laugh at how easily led sheep are, then go off to behave little different. In the introduction to their book on Thinking in SwiftUI, Chris Eidhof and Florian Kugler point out how little has been written about the concepts it’s founded on. Are we being led like sheep to recast our code simply because it’s a different patch of grass, or is there something more behind it? Why SwiftUI rather than anything else?

If you take Apple’s documentation as your starting point, then all you’ll see are claimed benefits that may not turn out as good as they seem, such as:

SwiftUI does rely on declarative code, but in practice that can create problems rather than solving them. Most current coders are also unfamiliar with declarative programming, as declarative languages haven’t been popular for many years.
Although coding an interface using SwiftUI can make it easier to implement across multiple platforms, interfaces still need to be designed and optimised for each platform they’re going to run on. SwiftUI can give you a start, but it’s only part of the solution.
It’s possible to create beautiful interfaces using AppKit and UIKit, just as it’s equally possible to create ugly and grim interfaces using SwiftUI.
Designing any GUI using non-GUI tools, as you must in SwiftUI, isn’t a beautiful experience.
SwiftUI remains woefully incomplete in many respects, particularly for macOS, and has been painfully slow to evolve. It also continues to change, and has limited backward compatibility.

The only clue given by Apple comes in a single word buried in the sentence “Share code between apps on multiple platforms with views and controls that adapt to their context and presentation.” The key word there is adapt. SwiftUI is a forceful move in delivering an adaptive human interface, one that adapts to the user, the task, the data, and the platform.

Adaptive interfaces have been around even longer than proper GUIs. A simple example that we take for granted are contextual menus. (That’s the term Apple originally used, but I regret that has now been turned into fractured English as the context menu, which would only be appropriate for a menu of contexts.) On a larger scale, Stage Manager switches between interface scenes according to the apps and windows you want to work with. Tool ribbons in apps have been less of a success because they demonstrate one of the dangers of an adaptive interface, in that poor design can confuse instead of clarifying.

There are already some wonderful examples of adaptive interfaces implemented using SwiftUI. My favourite is in OmniFocus 4, a superb task manager that delivers optimised interfaces across all five platforms it supports. On macOS its settings let you choose whether to view your Actions using a traditional column view:

or using its new Fluid view crafted using SwiftUI:

Column views don’t cope at all with the many variations in OmniFocus’s Actions, as they can have multiple tags, times and dates, location information (through a tag), a comment and attachments. It’s not practical to squeeze all of those into a single row, so much of the information has to remain hidden.

The Fluid view, though, accommodates whatever is associated with that Action, as it adapts to the data available thanks to skilful implementation in SwiftUI.

I expect that you’ve seen other interfaces implemented with SwiftUI that are just as elegant and purposeful.

Although I’m sure that an adaptive interface could have been engineered using Objective-C, even Swift didn’t appear a particularly good fit for SwiftUI. Some of the delays in development have occurred because of the need to modify Swift giving it support for features like property wrappers, so enabling SwiftUI internals. While SwiftUI doesn’t appear to incur much memory overhead, dynamic views and layouts can be demanding on the CPU, and the superior performance of Apple’s M-series chips is a definite aid.

In the long run, changes brought in SwiftUI are going to radically alter the way we interact with our Macs, and with other devices as well. As with all fundamental changes in the interface, these won’t happen suddenly, but progressively, and through trial and error. Most of the interface paradigms in macOS are still firmly rooted in Classic Mac OS. Those who adopted that rarely had more than a decade using a GUI, and had no experience at all of using mobile devices. Many of today’s 25 year-olds have grown up with computer GUIs, and may have been using mobile devices for a decade or more.

SwiftUI isn’t about a greener patch of grass, but supporting the evolution of the adaptive interface of the future.

References

OmniFocus 4, from the App Store or direct from Omni Group.
Chris Eidhof and Florian Kugler (2023) Thinking in SwiftUI, objc. ISBN 979 8 3972 4668 2.