UIKit vs SwiftUI - should I learn UIKit in 2024

How stable is SwiftUI in 2024?

I want to start this blog post by stating that I am a huge fan of SwiftUI.

I remember when SwiftUI first came out in 2019 after the Apple WWDC conference, I was so amazed by it, that I wanted to try it out right away. The response I got from my managers back then was:

• It is not yet stable
• It can’t support complex designs of our apps
• We have to support lower iOS versions than iOS 13.0 also

While all of these points are valid, in general, I felt that it was a fear of new technology, and people were just too used to using good old UIKit.

Luckily enough, in 2021, I had a chance to work on the same project with one amazing iOS engineer, who was passionate enough to rewrite the whole app in SwiftUI and started doing it by the time I came to the project. It was at the time iOS 15.0 was introduced, that he got the green light to bump the minimum supported version to 13.0.

In that project, although we have migrated around 80% of screens and views to SwiftUI, for some pieces of code that had to be performant, or just couldn’t be done in UIKit, we had to fall back to using UIKit components and wrap them in UIViewRepresentable or UIViewControllerRepresentable to use it with the rest of SwiftUI code.

For example, we had performance issues when trying to use List or simple ScrollView with VStack for rendering big lists of elements simply because those components don’t support the lazy loading of cells, something that UITableView already did. LazyVStack, with the functionality of lazy loading, was provided later, in iOS 14.0.

During the following years, SwiftUI has become much more stable so everything you can do in UIKit right now, you can pretty much do it in SwiftUI also, without any “hacky” solutions to make it work.

If we fast forward 5 years from the SwiftUI launch in 2019:

• SwiftUI is getting mass adoption through the Apple ecosystem. According to https://blog.timac.org/2023/1019-state-of-swift-and-swiftui-ios17/, in iOS 17, 21% of the binaries with UI in iOS are using SwiftUI, while 79% are still in the UIKit. For comparison, in iOS 15, only 7% of the binaries with UI were using SwiftUI
• More and more iOS apps from big companies introduced SwiftUI in their codebases
• It is hard to find an iOS job posting without some SwiftUI knowledge requirement
• When we onboard new junior iOS developer, we now start with SwiftUI, and then, get to parallels between SwiftUI and UIKit and not vice versa
• I am super happy I started early and have 3 years of commercial SwiftUI experience

What do you need UIKit nowadays?

I still receive a bunch of questions from people who are just starting to learn iOS development regarding whether should they learn UIKit or immediately start with SwiftUI.

I also think about this quite often actually, and a couple of days ago, in the office, this topic was brought up again. I am a big fan of SwiftUI and that’s why I love engaging in conversations like this with the team. I think that this kind of conversation is crucial for the team and for moving the tech stack you use forward.

Whoever joins our team, will immediately start learning and working with SwiftUI. That’s not because I think UIKit is not relevant anymore, but it’s mostly because I think that SwiftUI is and will be a good solid ground for all iOS projects in the future. But one iOS developer from my team said to me today, I feel like I have a gap because I don’t know much about UIKit after 1 year of writing purely SwiftUI?

I get that. In the end, SwiftUI is built on top of UIKit. But you will not get anything if you start learning UIKit and then you start learning SwiftUI and start using it in the projects. I am a firm believer that you can only learn something actually by doing it on a concrete project. So when it comes to UIKit, I believe that at the moment, the best approach would be to learn it the moment you need to create some UIKit component using UIViewRepresentable, and not devoting time at the beginning of your iOS career to UIKit, you will eventually learn it, once you need it.

What I think is important to understand is that we are in a kind of profession where we have to constantly learn. The second most important thing is that as soon as you are aware that you will never know absolutely everything, that’s when you feel a lot less pressure. That is the moment you start progressing and all pieces of the puzzle start coming together.

63% of iOS developers from my LinkedIn community said that they are already using SwiftUI in their iOS apps in the previous edition of my Sunday poll.

Why not both?

What is also really important to understand is that every big codebase of iOS project that has been around for a longer period of time, very probably still contains UIKit, and possibly some Objective-C, and that is completely fine.

Hopefully, if the team was enthusiastic enough to give SwiftUI a shot at some point, it has some SwiftUI code also.

Working on a codebase just like that has helped me a lot. I am now able to understand on a higher level how SwiftUI and new things like async/await integrate into a large-scale project and work interoperably with older code and UIKit.

There are a lot of SwiftUI success stories from large companies that are stating they have already moved a lot of parts of their codebase to SwiftUI, or that they are using SwiftUI for all of the new features in their iOS apps.

In the end, why wouldn’t they? Some of the benchmarks I did internally with my team showed us that developing UI things in SwiftUI is approximately 30% faster than doing them in UIKit. Of course, these are not 100% correct data which will be the same for every iOS team out there, because there are just too many factors that affect it. But there will be a speed increase when using SwiftUI, that’s a fact.

On the other hand, I came across one interesting article that the iOS team at Ollie, an app for organizing and manipulating photos by leveraging AI has made to switch from SwiftUI to UIKit. When I first saw this, I was confused about why they made that decision but as I kept reading the article it made more and more sense to me.

Since they are an app that relies heavily on operations like image processing and AI, performance is really important to them. They do a bunch of stuff on a really low level and that’s why they need to get the app to be as optimized as it gets.

Because of that, these are some of the things they had issues with in SwiftUI:

1. Performance optimization for large collections with immediate improvement noticed when they reverted to UICollectionView
2. Swift concurrency with async await caused weird edge case bugs when used in combination with libraries like CoreML and GooglePhotos which have their way of working with threads
3. Weird re-rerenders of SwiftUI views and not being able to control the view lifecycle completely
4. Unexpected StateObject behavior when combined with Binding
5. Attribute graph tracking and debugging

I am a big fan of SwiftUI, but for this scenario, I can say that I kind of agree with their decision to fall back to UIKit entirely.

‍

Conclusion

In the long run, SwiftUI came here to stay. The adoption rate is getting bigger each day. But in the next couple of years, the iOS developers will still have to know UIKit, that’s for sure, because most of the codebases they will be working on will be a mixture of UIKit and SwiftUI.

‍