Fully updated for Xcode 11.2
Of all the SwiftUI questions I’ve been asked, one comes up more than any other: “I’m learning Swift: should I learn SwiftUI or do I need to learn UIKit as well?”
The answer folks seem to want to hear is “forget that old UIKit thing – you should focus on SwiftUI!” However, the simple truth is that the vast majority of people won’t find success with that advice, and it’s worth explaining why in a little detail.
Before I get into detail I want to make one thing clear: SwiftUI is a remarkable user interface framework, and is 100% absolutely going to be the future of app development on Apple’s platforms. However, if you want to build great apps today – or indeed any point in the next one to two years or so – you also 100% absolutely need knowledge of UIKit, particularly if you intend to make app development your career.
OK, with that out of the way, the problems with focusing on SwiftUI while ignoring UIKit come down to three things:
Let’s break that down…
Regardless of whether you want to work for a company or just build hobby apps in your spare time, one drawback of SwiftUI is that it does not currently have the same broad API coverage as UIKit.
For example, if you want to show items in a grid you would use
UICollectionView in UIKit, but SwiftUI has no equivalent. Or if you wanted to let the user enter multiline text you would use
UITextView in UIKit, but SwiftUI has no equivalent either.
This isn’t Apple being lazy, and instead seems to be deliberate: rather than releasing wrappers for all their APIs up front then having to make changes later, they are instead taking a much more cautious approach and adding APIs incrementally. This should (I hope!) reduce the number of breaking changes we see in the future, because it gives Apple’s engineers more time to hone the subset of APIs they intend to ship.
A lot of the time you’ll find workarounds, but honestly it’s tiring when you know a particular thing is trivial in UIKit but hard if not impossible in SwiftUI. Sometimes it’s even simple things: how can you change the separator insets on a table? Or how do you add a text box to an alert? These are a single line of code in UIKit, but unavailable in SwiftUI.
As each year goes by I fully expect to see more functionality added to SwiftUI to bring it to parity with UIKit, but right now we’re a long way away.
SwiftUI was only announced at WWDC2019, and is available in iOS 13 devices or later. This immediately means that:
This means that if you intend to get a job as an iOS developer in the next three years, UIKit experience is effectively mandatory because that’s what existing codebases use. In fact, I fully expect UIKit to still be the dominant UI platform in four years’ time. No one – not even Apple, I think! – expects the iOS community to migrate over to SwiftUI at any sort of rapid pace. There’s a lot of code, a lot of time, and a lot of money invested in UIKit apps, and it has a long and happy life ahead of it.
Some folks try to draw parallels between adoption of Swift and adoption of SwiftUI, which isn’t helpful. Adoption of Swift was fast because it worked across every one of the frameworks Apple supported (UIKit, SpriteKit, etc), and also already supported iOS n-1, so many companies could switch to it immediately.
Again, I want to reiterate that SwiftUI is absolutely going to be the future of development for Apple’s platforms, but it will take a long time to gain adoption at the level of UIKit.
In the meantime, SwiftUI is the perfect candidate for personal apps, hobby apps, prototype apps, or general experimentation. And if you’re lucky enough to join a company that uses SwiftUI exclusively, enjoy it!
UIKit has been around over ten years now, which means a) almost every problem you might face has probably already been faced and solved by others, and b) there are lots of libraries out there that provide extensions and customizations.
While some learners might imagine that senior developers hold vast amounts of UIKit in their head, the simple truth is that we all use Google, Stack Overflow, Hacking with Swift, and more to find solutions to problems. When you’re desperate that might literally be pasting error messages into a website, but regardless of how you get answers it saves a lot of time finding them online.
SwiftUI, simply by virtue of being significantly newer, has significantly fewer solutions available. In fact, it’s common to look for things that no one has tried before – you’re literally the first person. That can be a lot of fun, but if you have an actual project that you actually want to ship it can also be a frustrating time sink.
No! SwiftUI is great fun to work with, and you can build marvelous things with it. The whole rest of this book is designed to help you get started with SwiftUI as quickly and efficiently as possible – I wouldn’t have written it if I didn’t think SwiftUI was awesome.
What I’m trying to say is that the existence of SwiftUI hasn’t somehow rendered UIKit obsolete: if you intend to get an iOS development job within the next three years, knowing how to use UIKit will either be a firm requirement or a strong bonus.
So, to answer the question directly: yes should get busy learning SwiftUI because it is the future of app development on Apple’s platforms, but you still need to learn UIKit because those skills will be useful for years to come.
As each year goes by, all three problems listed above will become reduced as SwiftUI grows in strength, adoption, and support, and as SwiftUI grows UIKit will start to shrink. However, for now at least, you really do need both.
SPONSORED Instabug helps you identify and resolve severe crashes quickly. You can retrace in-app events and know exactly which line of code caused the crash along with environment details, network logs, repro steps, and the session profiler. Ask more questions or keep users up-to-date with in-app replies straight from your dashboard. Instabug takes data privacy seriously, so no one sees your data but you! See more detailed features comparison and try Instabug's crash reporting SDK for free.