|< SwiftUI vs Interface Builder and storyboards||Answering the big question: should you learn SwiftUI, UIKit, or both? >|
Fully updated for Xcode 11 GM
Lots of people are already asking me questions about SwiftUI, and I’ve done my best to ask other people who know much more to try to find definitive answers as appropriate.
So, here goes…
This question has been asked so many times I added a dedicated chapter to this book so I could go into more detail: answering the big question: should you learn SwiftUI, UIKit, or both?
SwiftUI runs on iOS 13, macOS 10.15, tvOS 13, and watchOS 6, or any future later versions of those platforms. This means if you work on an app that must support iOS N-1 or even N-2 – i.e., the current version and one or two before that – then it will be a year or two before you can even think of moving to SwiftUI.
However, it’s important you don’t think of SwiftUI as being a multi-platform framework similar to Java’s Swing or React Native. The official line seems to be that SwiftUI is not a multi-platform framework, but is instead a framework for creating apps on multiple platforms.
That might sound the same, but there’s an important difference: Apple isn’t saying that you can use identical SwiftUI code on every platform, because some things just aren’t possible – there’s no way to use the Apple Watch’s digital crown on a Mac, for example, and similarly having a tab bar on a watchOS app just wouldn’t work.
No. Many parts of SwiftUI directly build on top of existing UIKit components, such as
UITableView. Of course, many other parts don’t – they are new controls rendered by SwiftUI and not UIKit.
But the point isn’t to what extent UIKit is involved. Instead, the point is that we don’t care. SwiftUI more or less completely masks UIKit’s behavior, so if you write your app for SwiftUI and Apple replaces UIKit with a singing elephant in two years you don’t have to care – as long as Apple makes the elephant compatible with the same methods and properties that UIKit exposed to SwiftUI, your code doesn’t change.
While Auto Layout is certainly being used for some things behind the scenes, it’s not exposed to us as SwiftUI designers. Instead, it uses a flexible box layout system that will be familiar to developers coming from the web.
SwiftUI is screamingly fast – in all my tests so far it seems to outpace UIKit. Having spoken to the team who made it I’m starting to get an idea why: first, they aggressively flatten their layer hierarchy so the system has to do less drawing, but second many operations bypass Core Animation entirely and go straight to Metal for extra speed.
So, yes: SwiftUI is incredibly fast, and all without us having to do any extra work.
When working with SwiftUI it’s helpful to be able to see both the code for your view and a preview of your view – how it looks – side by side. If you can see the code and not the preview, chances are you have yet to upgrade to macOS 10.15; it’s required to make the preview work.
When you make any change to the preview it will also update the generated code. Similarly, if you change the code it will update the user interface too. So, the code and preview are identical and always stay in sync.
SwiftUI gives us standard system colors like red, blue, and green, but these aren’t the pure red, blue, and green you might be used to from
UIColor. Instead, these are the new style colors that automatically adapt to light and dark mode, which means they will look brighter or darker depending on your system appearance.
No! Apple has a massive stack of new UIKit functionality airing at this week’s WWDC. If Apple are still doing WWDC talks about new features in UIKit, you’re quite safe – there’s no risk of them retiring it by surprise.
Yes! You can embed one inside the other and it works great.
LEARN SWIFTUI FOR FREE I have a massive, free SwiftUI video collection on YouTube teaching you how to build complete apps with SwiftUI – check it out!