SwiftUI is not the future anymore but is right now

Obviously, in the last years, for iOS developers, SwiftUI has drawn lots of attention. Although it looks promising, its initial shortcomings and most importantly, the iOS system is limited from iOS 13 have made the community hesitant about applying this in production. After a few surveys, I know (and totally understand) that in the next 2 years, not many teams will choose this nascent framework to build apps for production. But I believe that, 2 years later, this rate is going to dramatically increase. Here are a few certain points to prove this.

Image credit: apple.developer.com

SwiftUI is a game-changer

What is coming will come when other platforms (especially hybrid ones) that use declarative styles have come a far way and Apple can’t stay out of the game for too long. Overall, iOS developers like us must also keep up with the trend.
Changing mindset from imperative style to declarative one will take a lot of time and effort to do properly. Therefore, during the next 2 years, taking advantage of the time when SwiftUI has not entered the main stage, we should get acquainted with it.
Code speed and performance using the SwiftUI platform is much faster and more convenient than UIKit. I have experience when receiving a screen from the client. With UIKit, I estimate it takes 8 hours, whereas SwiftUI only takes around 2 hours.
For those of you who believe that UIKit still has a place in the future, look at the similar story of Obj-C and Swift. The demand for Obj-C related jobs remains and will remain since there are projects, SDKs having been around for a long time and requires maintainers. But to approach new things, with only Obj-C knowledge, can you keep up with the trend? Not to mention the disadvantages of Obj-C compared to Swift, which cause you to spend more effort when coding. The story is similar to SwiftUI and Interface Builder.

Current bugs are not a big deal

Some points say: SwiftUI is buggy, immature and undocumented. I totally agree. But let’s think more about that. Are they really that bad? My answer is not really:
- It’s immature: It’s fine. Anything newly launched is going to have bugs. But if you wait till it becomes perfect to learn. It’s too late.

SwiftUI has been increasingly improved

I’ve been a follower of SwiftUI since it was in beta — and looking back now, it truly has been maturing. Not only the new features but also improving long, hard-to-read APIs. Of course, SwiftUI still can’t cover all the components that we need, so with those, we have to go through a wrapper class — with the main content still taken from UIKit. But I believe through each release, Apple will gradually convert them to SwiftUI native components such as Map, ProgressView, and so on.

The suitable architecture

This was one of the big challenges for me in the early stages when the programming style was different from the way I did before. The good news is that there is a team having a suitable architecture for SwiftUI done. That’s outstanding architecture — and I am pretty sure you will love it. It solved problems that vanilla SwiftUI is facing. That’s the Composable Architecture of the PointFree team. In the next articles, I am going to dive deeply into this architecture — its theories as well as actual practices.

Conclusion

I totally understand the reasons why very few people would dare to bet on it at the moment, but it is no coincidence that apple constantly SEOs for this framework. When the percentage of iOS 13 accounts for more than 95% of the users (currently more than 85%), then, SwiftUI will no longer be a consideration, but the first choice when starting a new project. Trust me, soon enough, that day will arrive.

Product Management + Technical Architecture + Explore new technologies.