SwiftUI: A Story
I’m back, folks, and I’m working on a book about SwiftUI.
“Now?” you ask. “There are already plenty of people already writing about it. Aren’t you a little late? Are you just jumping on the bandwagon?”
Well, no. Well, maybe. But not so much. I can’t really say I’m late exactly. Let me tell you about a little meeting I attended in 2015, about a year after I joined Apple.
It was a big conference room, seating about 25–30 people or thereabouts. There were two giant screens at one end, on which were displayed a Keynote presentation and the contents of the presenter’s Xcode window. There were some heavyweights from the UIKit and WatchKit teams there. A couple of unit directors from watchOS, people involved in the watchOS-specific UI frameworks. Some people who were really excited about Swift.
Jerry Garcia. Jimi Hendrix.
Quite an audience, and quite a show. A couple of rather clever chaps, Jacob Xiao and Kyle Macomber, were showing us a new UI framework they’d devised, and were proposing as the official way to write watchOS apps that ran on-device—a replacement for WatchKit, which at that time ran all code on the companion iPhone. Their approach was to make use of immutable value types to represent views and their state, with all of the benefits that brought to an increasingly multi-threaded and parallel world. In fact, Jacob and WatchKit engineer Alex Migicovsky presented on this very topic at WWDC in 2016: Protocol and Value Oriented Programming in UIKit. This talk describes quite well the aims of this new framework, which would be announced to the public three years later under the name of SwiftUI.
Things changed in the years since I last looked at the project (some time in 2017 I believe), and the various features added in Swift 5.1 to create the declarative UI DSL weren’t even being talked about (at least, not where I could hear them). The SwiftUI framework that is being released this fall with macOS 10.15 and iOS 13 is a markedly different beast.
One thing I remember being tackled a lot was the problem of relating a SwiftUI View struct to the underlying CALayer or similar, so we might insert and remove views from the hierarchy and have the right animations occur. For instance, going from two text fields to three by insertion: "red" | "blue" to "red" | "green" | "blue". Does the content “blue” change to “green” and a new “blue” appear? Or does the existing “blue” move out of the way to allow “green” to appear? What if we insert “green” while changing “blue” to “mauve”? Just think about how you’d tie these things together properly, and then how you’d do so with the absolute minimum of burden on the user.
It was a seriously hard problem, and they nailed it—there’s no need to attach identifiers to view structures in SwiftUI. The framework is able to figure it all out on its own. We now have view preferences (see Javier Nigro’s excellent three-part series), @Environment, we have @State and @Binding, and we have the Combine framework and all that entails. So much of the work that went into SwiftUI was focussed on reducing the visual complexity of all these common tasks, and they’ve succeeded admirably.
I’ve been waiting with bated breath for several years now to see this project unveiled, and now it’s here I’m excited to see what we can do with it, and how it’ll shape UI APIs on Apple platforms in the years to come.