UIKit to SwiftUI-Managing the swift transition
Live previewing has been anticipated for quite some time, SwiftUI’s declarative style turns out to be icing on the cake.
Why is there a great hype around SwiftUI? Is it just another framework announced in a WWDC or more than that? How should you be planning the transition from UIKit to SwiftUI, should you jump right in or wait for it to gain maturity? Read on to know more…
SwiftUI, the beginning of “Swift Apple”
Nicely explained by Brent Simmons here that SwiftUI is a transition from NeXT era to Swift era in Apple. Yes, it has clearly shown a glimpse of how the future of app development will be.
From Apple Developer documentation,
SwiftUI is an innovative, exceptionally simple way to build user interfaces across all Apple platforms with the power of Swift. Build user interfaces for any Apple device using just one set of tools and APIs. With a declarative Swift syntax that’s easy to read and natural to write, SwiftUI works seamlessly with new Xcode design tools to keep your code and design perfectly in sync.
What is declarative programming?
By definition, Declarative programming is more about “What” than “How”. For instance, on a payment screen when the payment is processing, the loader must be on, and when the payment is not confirmed, the next button should be disabled. This is, if done in imperative way, will have to consider a lot of cases. As it depends on a lot of different external triggers and specifically on their order of occurrence. Thus the complexity increases exponentially with every dependency. Whereas in Declarative way, it can be handled easily. How?
As the UI/View at any given time is a result of some state variable and not dependent on external triggers, so there is only a single source of truth available. This really simplifies the process, and in line with Swift’s principles this makes it harder to have run time issues.
UIKit to SwiftUI
Inspite the end result being the same (presenting native UI experience), there is a significant difference between the two.
At it’s core the building block of UI in SwiftUI is a struct that conforms to View protocol. Whereas in UIKit, the UIView is a class and views are created in hierarchies subclassing it. Essentially every buttons, controls, labels and views in UIKit are a concrete representation of a full fledge object- a sub class of UIView. Whereas, in SwiftUI, the View is just a snapshot of the UI at a given time. It’s the abstract representation, which makes it really light weight. This is essential, given the whole UI updates frequently with every change in the state variable, owing to the declarative nature of the framework.
UIKit pain points that SwiftUI aims to solve
- Managing so many different platforms : In UIKit, iOS apps can be made universal to cater to both iPhone and iPad. However, creating a native experience on so many different screen sizes is a pain point, plus there is no way that a single code can be used to target iOS, MacOS and WatchOS. SwiftUI is trying to bridge this gap by creating a framework layer to manage the platform level customisation of the view on our behalf. True, that every platform has its unique characteristics and vastly differs from another in terms of screen size, use case and purpose, but writing completely different code for each platform is clearly not the way to go. It becomes difficult to manage and scale such codebase and is prone to bugs.
- Efforts needed to incorporate basic app features : Handling uniform fonts across the app, making apps accessible, making great animated transitions which is interactive and interruptible. And, the newly introduced Dark mode is the latest entry on the list. Making apps compatible with these little things take a lot of effort and the complexity causes bugs. Basic features like these, no matter how insignificant they are individually, make a great app GREAT. With SwiftUI, the framework takes care of most of these on our behalf so that we can focus more on the unique capabilities of our app and worry less about meeting the standard threshold.
- Architecture pattern debate : Whatever architecture you chose to follow, the aim is to have a strong separation of concern within the code base, which makes it easier to read, change and maintain.
MVC is really a great architecture pattern without much glitch. However, within iOS community, architecture pattern has been debated for long, more here. SwiftUI seems to end this debate now, it has been designed to make it harder to write tightly coupled code - Use storyboard vs code, to design the UI : Creating UI using storyboard OR through code have their respective pros and cons. In SwiftUI, you can use either the canvas(visual editor) or the code to design the UI and the result is just the same. SwiftUI automatically adds the code for the edits you make in the canvas. This is not the case with UIKit, designing the UI through the code or the storyboard is a different game all together. Although they are compatible with each other, they aren’t interoperable.
Transitioning from UIKit to SwiftUI
Dive right in or wait? No doubt, SwiftUI is relatively new framework. Lot of UIKit capabilities aren’t available yet. Less adoption means less support. And above all, you can’t even write apps for iOS versions less than 13. Which means, it will take at least 1–2 years for it to be viable for production apps following the N-2 convention (Supporting the last 2 versions of iOS). That being said, with all its goodness, SwiftUI is going to be the future of app development for sure.
What about a mixed approach? Understanding and practicing the inter-operability of SwiftUI and UIKit is really important. We are now in the midst of a transition where we can’t fully embrace SwiftUI as of now or can’t just ignore it. The best strategy will be utilising the brilliance and convenience of SwiftUI at the same time avoiding its shortcomings.
SwiftUI evolution is going to be different than Swift evolution : The downside of Swift evolution was that in the first 3 iterations (Swift 1,2 and 3), Swift has gone through some major changes and complete refactoring in some cases. Thus, those who have rushed to write production apps in the earlier versions of Swift, had to rewrite the entire code. Although it has been quite stable after that and now Swift5 has been ABI stable.
However, SwiftUI seems to be taking a different path. In contrast to UIKit, SwiftUI doesn’t have all the features that we need for UI design (like UICollectionView or UITextView), but whatever it has, probably won’t change.
Previewing the view : It is the coolest and greatest feature available in XCode11. The preview isn’t an estimation of how the app is going to be, it is the real app compiled, run and being updated in the real time. XCode uses some background optimisation to make this process efficient. More on this here
Pro tip : Even though you are not willing to use SwiftUI for production apps as of now, you can still leverage the power of live preview feature in XCode. Although technically it’s available only for iOS 13 and SwiftUI, there is a workaround to use it even for lower than iOS 13 targets and for UIKit as well, thanks to UIKit-SwiftUI interoperability :) WWDC session on this. It not only works with code written in Swift, but also in Objective-C (As it should be, since Objective-C and Swift are inter operable)
Basically you can preview the view written in any language or framework that XCode understands, more here.
Objective-C to Swift transition did take some real effort, but it was rewarding at the end and was worth it. So, keep learning, keep updating your programming arsenal. Stay hungry. Stay foolish :)
