First thoughts on SwiftUI

June 20, 2019

I spent a few hours last night playing with Apple’s new approach to user interface development, SwiftUI.

I haven’t yet gone through any of the WWDC videos yet, which I fully intend to do. I just have limited time for learning these days and need to carefully target how I spend it. I decided to just follow the official tutorial to get a high-level taste of what’s going on, and to follow it up later with in-depth look.

After a few hours of the topic, here’s some initial highly subjective thoughts based on just a sampling of the tools, and not really having digested it fully.

The biggest change in my 10 years of iOS building. I started to play with iOS development around 2008, and have done a lot of UI(Kit) since then for both commercial and hobby projects, with a fair bit of Mac (AppKit) thrown in. SwiftUI is the biggest paradigm shift through this whole time because it completely changes how to think about building and running the user interface. Even the switch from Objective-C to Swift a few years ago wasn’t that big of a change, because programming Swift against UIKit is not really all that different from programming Objective-C against UIKit. The approach to building UI has gotten a bunch of changes over the years (autolayout and storyboards come to mind), but the core of it has remained the same. Now, though, this is all out of the window, replaced with a whole new world.

It helps to understand declarative and imperative programming styles. I don’t have formal Computer Science background and started out as many of us do, by just dabbling around, following examples and the like. At some point, though, I found it interesting to reason about more theoretical concepts, with programming styles being one of them. One of the clarity points was when I realized the difference between declarative/functional and imperative styles. Lately I’ve been gearing towards the functional style anyway. So even though SwiftUI is completely new, it doesn’t feel alien if you’ve done declarative work, which most of us have, because we’ve done HTML and CSS. I’ve taken great pleasure in my web work to avoid JavaScript by using CSS features which were previously only possible with JavaScript “programming” (e.g animations, even basic state management). SwiftUI fits neatly right into that world view.

No more Interface Builder, XIBs. Yep. Completely gone. Out of the window. Practically this is the biggest change on the tools side for me. Not sure if I’ll miss it. The XIB and storyboard formats were always this weird opaque thing. You’d build them in Interface Builder, and hope you wouldn’t get any merge conflicts because the format was a pain to work with, in the old binary NIB world and also the newer XML format. That whole world has just disappeared.

No more autolayout. People like to trash autolayout and especially designing constraints in Interface Builder. I didn’t mind it, but also, I don’t mind this simpler world of basic boxes that are sufficient to express all of the layouts that I’ve had to deal with lately. I remember when UIStackView/NSStackView were introduced a few years ago. Until that point, I felt the layout world had always marched towards more depth and complexity with storyboards, autolayout etc. I suppose these simple stack views, which are also an important SwiftUI layout building block, were a precursor of things to come.

No more Core Graphics drawing. I suppose that makes sense, there is no explicit “draw” function for views. There is a similar replacement, which the tutorial covers.

No more ViewControllers? I have yet to figure out what this means. In the old UIKit/AppKit world, view controllers were a central building block, and did a lot of manual shuffling between view and model. In the SwiftUI world, the view binds directly to the model, the glue is gone, and I have yet to figure out if there is any “logic” left which previously lived in ViewControllers and would still need to exist, or can I just forget about the whole ViewController concept.

Designer-editable UI? I keep bouncing ideas around with my designer friends around design/development tooling, and one of the discussion points has been how hard it still has been for designers to play with native development. In the old world, the UI was scattered between Interface Builder and view controller code, was easy to mess up, and you had to go through the whole build process to witness the outcome. IBDesignable was a nice attempt, but too little. In this new world, UI is isolated, code is compact and modular, and you get live previews without having to do a full build. Exciting and promising.

I need to learn about bindings and Combine. I’ve done a fair bit of work with notifications, Cocoa Bindings, key-value observing etc, to know that they are all pain in different ways. The new Combine approach, and how view and model work together, are a key of SwiftUI, and I don’t yet know enough about it.

The world will be a messy hybrid for a while. All of the above is a hypothetical SwiftUI-only situation. In reality, it is good to know that you can freely mix and match the old and new worlds, running UIKit inside SwiftUI or vice versa, which affords for gradual migration of older stuff, just like Swift/Objective-C mixing which seems like it has worked fine for the world.

Less code, less bugs, more modular approach. Fortunately I am not in a position where I have to support major legacy codebases, and most of my iOS these days consists of just hacking around or playing with hobby projects that don’t need to support several versions back. So all in all, an interesting new world has arrived, and I’m looking forward to diving in and producing most of my future UI in SwiftUI.