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.
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.
- It’s undocumented: Well, we are iOS developers, and we’re probably all too used to how bad Apple is at writing documentation. But you know what, now, the community did this really well (for example, Paul Hudson). So for me, I’m not worried about this at all.
- Last but most important: Now will be the gist of the whole article. I know SwiftUI has a lot of bugs but, to be fair, they are not systematic. These bugs are fragmentary, not a blocking type, or kind of no-hope ones. The most important issue, I think, is the navigation feature when we combine them with the tab bar or drawer. But even with this, we still find a work-around solution (take more time and effort, though). Therefore, these shortcomings cannot mask the fact that SwiftUI is the future of iOS programming.
Therefore, these shortcomings cannot mask the fact that SwiftUI is the future of iOS programming.
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.
Also, the community of developers using SwiftUI is expanding and I believe that when the time is ripe, SwiftUI is strong enough to play big projects.
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.
Also, the Combine framework (an Apple’s tool) enhances the state binding paradigm, by borrowing concepts from RxSwift. And this is revolutionary for Apple platforms, and we, as iOS developers, cannot be happier.
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.
I approached SwiftUI very early and do a couple of complex apps with it, so, if you have any questions or concerns about this framework, do not hesitate to comment with your thoughts. Hope you love this.
