A birds-eye view of SwiftUI
SwiftUI is a framework for designing powerful and rich user interfaces for a wide range of devices across the Apple ecosystem. Apple introduced this UI framework in WWDC19 which is going to be the future of UI development. This article provides a high-level insight on the SwiftUI framework.
As we think about the adoption of any new framework, the first and foremost factor that we consider is the minimum OS version that supports the framework. Swift UI is supported only on devices that run on iOS 13 and above. So if the app’s deployment target is still below iOS 13, then it is time to bump it up unless we have a strong reason for not doing so. As per the latest statics released by Apple on December 15, 2020, already 81% of iPhones released in the last 4 years are running on iOS 14.
SwiftUI is an alternative for the UIKit framework which provides a wide range of APIs and core elements to build the user interface. Let us try to draw some parallels and comparisons between these two frameworks.
SwiftUI uses code to build the user interface whereas UIKit makes use of xibs and storyboards for the same. As a developer, the moment we read this, the immediate thought that runs in our mind is
Why do I have to write code when I have a simpler way of building and visualising my UI with storyboards & xibs?
The short answer to the question is SwiftUI does not leave us just with the code but rather it provides a dynamic preview of the code using the SwiftUI’s canvas editor. We still have the flexibility to add UI elements into the canvas editor as we used to work with storyboards. Also as an added bonus, the SwiftUI code will be automatically updated as we modify the layout in the canvas editor.
UIKit is an event-driven framework that uses an imperative programming paradigm whereas SwiftUI uses a declarative programming paradigm. Let us understand the difference between these two paradigms with a simple example. Consider a simple OTP screen with textfield and Submit button. With UIKit, we would listen to the textfield changes with the help of delegates and then update the Submit button’s state when the entered OTP becomes valid. In SwiftUI, we would simply bind a state variable to the textfield. SwiftUI takes care of automatically disabling or enabling the Submit button as the text changes.
As we saw in the above example, the UI is driven by the state. So the factor that drives the app design in SwiftUI would be the state of the application and not the events.
Another interesting point to be noted from the snippet is that views are struct that confirms to the View protocol in the SwiftUI framework. These views when nested together produce the interface that is required for the app.
In the example shown above, the body returned by the SwiftUI view is a NavigationView that contains a List which in-turn contains an HSatck(Horizontal Stack) of Image and Text. In UIKit, this is analogous to a UITableViewCell that is nested in a UITableView that is again nested in a UINavigationController.
Building a list has been never this simple!!! One need not be aware of the various components in the UIKit like UITableView, UITableViewCell, UITableViewDataSource, UITableViewDelegate, etc that is involved in building a list view.
By now we must be wondering if these views would be added as subviews in a ViewController. Not at all. It's time to bid goodbye to the ViewControllers which used to be the backbone for building a screen. SwiftUI treats the views as components that are used for rendering the user interface. The image below demonstrates how a SwiftUI app built using various components like WindowGroup & ContentViews.
The next factor that we would definitely be worried about is the app’s performance. So the obvious thought that strikes our mind would be
If I keep embedding more and more views into the view hierarchy would it affect the app’s performance?
One of the major drawback that has been observed with the UIKit framework is that as we add more and more subviews to the view hierarchy, there would be a significant impact on the app’s performance. Unlike the UIKit, SwiftUI’s views are extremely lightweight, and also the rendering engine is optimized to render only the views whose state has changed over the course of time.
Looking at the powerful features and the simplicity that is provided by the SwiftUI we would be obviously excited to start using it in our existing projects. So the next question that we would have is
My project is completely built using UIKit. Will I have to rebuild my app from scratch? Are all the UI components in the UIKit readily available in the SwiftUI?
Apple has always ensured interoperability for any new frameworks that they introduce. So the good news is that SwiftUI is completely interoperable with UIKit framework. SwiftUI can be seamlessly integrated with the UIKit by wrapping a SwiftUI view in a UIHostingViewController. On the other side, UIViewRepresentable protocol helps us to embed any UIKit view into the SwiftUI environment.
Some of the other advantages that are offered by SwiftUI are
- Two developers can now confidently work on the same layout file. There is no more fear of resolving conflicts in xibs or storyboards
- SwiftUI has brought in great support for reactive programming with object binding and combine framework
- No more app crashes because of a faulty IBOutletConnection from storyboards to view controllers
- It is guaranteed that SwiftUI will always generate a valid layout. This means that we would not have to watch out for auto layout bugs that result in an undesired UI
- The super-powerful SwiftUI preview allows you to visualise the navigation from one screen to another without having to build the entire app to test the navigation flow which saves a lot of build time.
While SwiftUI seems to be super exciting for a developer, we would need to familiarise ourselves with the following concepts as we start using it.
- Switching from imperative programming to declarative programming
- Thinking about the design of the app from the perspective of state rather than events
- Understanding the property wrappers like @State, @Binding, @EnvironmentObject, etc which makes the development in SwiftUI easier and less error prone
As Swift has now become the language for iOS app development, SwiftUI will become the framework for building user interfaces within next few years. So what are we waiting for? Let’s leverage the super-powerful SwiftUI framework and ship awesome apps.
