What is SwiftUI ?
Although storyboards and XIBs have served us well, they aren’t to everyone’s liking – they can be messy to use with source control, they make it hard if not impossible to move between code and visual layouts, and they rely on a flaky system of connections using actions and outlets.
SwiftUI sweeps all that away in several important ways:
There’s a new declarative UI structure that defines how our layouts look and work.
Updating the UI preview automatically generates new Swift code, and changing the Swift code updates the UI preview.
Any bindings in the Swift – e.g. outlets and actions, effectively – are now checked at compile time, so there’s no more risk of UI failing by surprise at runtime.
Although it uses controls from UIKit and AppKit behind the scenes, it sits on top of them, effectively making the underlying UI framework an implementation detail rather than something we care specifically about it.
How to use SwiftUI
I am busy pushing SwiftUI as hard as I can with Xcode 11, while also speaking to Apple engineers here at WWDC, so as I learn best practices from them I’ll be trying to distill them down to tutorials to help you get up to speed as fast as possible – watch this space!
There are some gotchas
Before you dive headfirst into SwiftUI, there are two important provisos to be aware of. First, it’s Swift only – you can’t use SwiftUI from Objective-C, which isn’t much of a surprise given the name. Although I’m still poking around, I expect this year’s release to not give us the full range of power we’re used to, so existing iOS developers will probably want to stick to the regular code they know until SwiftUI matures. I’ll know more once I’ve spent more time with the tool, but given that this is an early release I would imagine Apple prefers to play it safe.
The dramatic simplification of UI creation with SwiftUI does a number of things for Apple.
First, it absolutely brings them one step closer to Xcode for iPad – it was always going to be hard to get something the size of Interface Builder onto iOS no matter what size screen your iPad has, so having the simpler, faster, and safer SwiftUI takes one massive leap towards true platform independence for developers.
Second, it continues to build a story they’ve been working on since Swift launched: everyone can code. This started off with Swift itself, expanded into Swift Playgrounds, and now into a wholly new user interface system that helps avoid large swathes of problems newer developers hit.
Third, although you might look at SwiftUI today and think it’s not for them, you need to think of it more like the initial step towards where Apple wants to be. By eliminating pain points around source control, by removing our tight dependency on UIKit, by eliminating some of the connection confusion you can run into with Interface Builder, and, yes, by enforcing the use of Swift, Apple is sending a clear message: we should be relying on tools as heavily as possible, and SwiftUI is a view of what the future looks like.
Swift Evolution becomes a little clearer
Before we’re done, I want to add that the announcement of SwiftUI is really helping me join the dots a little for some previous Swift evolution changes – implicit returns for single-expression functions, opaque return types, and (the still not yet approved) Swift style guide all seem like they would be helpful in making SwiftUI work more smoothly.
