Lots of free SwiftUI tutorials are already available.
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:
SPONSORED In-app subscriptions are a pain. The code can be hard to write, hard to test, and full of edge cases. RevenueCat makes it straightforward and reliable so you can get back to building your app.
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!
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.
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.
I'm busy digging through all of the new SwiftUI documentation – get to it!
SPONSORED You know StoreKit, but you don’t want to do StoreKit. RevenueCat makes it easy to deploy, manage, and analyze in-app subscriptions on iOS and Android so you can focus on building your app.
Paul Hudson is the creator of Hacking with Swift, the most comprehensive series of Swift books in the world. He's also the editor of Swift Developer News, the maintainer of the Swift Knowledge Base, and a speaker at Swift events around the world. If you're curious you can learn more here.
Link copied to your pasteboard.