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 some 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:
- Limited API coverage.
- Limited adoption.
- Limited support.
Let’s break that down…
Limited API coverage
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 rich editable text you would use UITextView in UIKit, but SwiftUI’s own TextEditor will only handle plain strings. Or if you want to show a text field in an alert, it’s right there in UIKit but not possible with SwiftUI.
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 disable smart quotes in a text field? 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 many key components are still missing.
Limited adoption
SwiftUI was only announced at WWDC2019, and is available in iOS 13 devices or later. This immediately means that:
- Almost every app written to date uses UIKit.
- Any app that needs to support iOS n-2 or earlier (e.g. iOS 12) cannot even begin to switch to SwiftUI for a year or more.
This means that if you intend to get a job as an iOS developer in the next two 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 a year or two. 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 I don’t think is 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 smaller apps, 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!
Limited support
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.
So… are you saying I shouldn’t learn SwiftUI?
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 two 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.
