Every time something new comes out this question comes up. And ever time the answer is pretty much the same: Learn both. Learn UIKit first, it’s solid and drastically less buggy than SwiftUI right now (as SwiftUI is only in beta previous to it’s first release). And also because SwiftUI is based in UIKit.
Look, there’s millions and millions of lines of code out there in millions of projects (and that’s just the shipping ones) that use UIKit with Swift, or (gasp!) UIKit with Objective C. None of that is going away soon. It has to be maintained, updated, and someone has to do that work. Over time more and more of it will be converted to Swift and perhaps to SwiftUI. But never all of it.
Sure, there will be brand new projects using just SwiftUI, but most work isn’t on brand new things. There’s a very many times more projects out there that will require work on existing code with some portion of it being updated with new code. Even if you just work on the new code (very very highly unlikely) then you’ll still have to read that old code.
You want a good job? Learn both UIKit and SwiftUI. Learn both Objective C and Swift. The goal is not “I want to code in SwiftUI”, the goal is “I want to get
Most professional developers know multiple languages and SDKs, that’s the way this field works. Some developers know and have used over a dozen languages. Your second language or SDK is easier than you first, and your third is easier yet.
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 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.
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-1 or n-2 (e.g. iOS 12 and iOS 11) 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 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!
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.