UIKit is dead???

If you have read two of my previous posts regarding MVC design pattern in iOS development and making your code cleaner, it’s time to consider a major shift in framework for developing User Interfaces in iOS apps.

SwiftUI Introduction Presentation, WWDC 2019

In WWDC 2019, Apple has introduced a completely new framework named SwiftUI for developing User Interfaces. SwiftUI helps write less and cleaner code for creating UI. It is declarative, cross-platform (in Apple’s ecosystem) and enables real-time interaction with UI previews.

TL;DR

1. SwiftUI is a powerful tool for creating declarative UIs which eventually eliminates state inconsistency
2. Drastic paradigm shift that brings reactive functional programming along the way
3. Although SwiftUI is still a bit immature, it is Apple’s vision for the future

UIKit has been well-established as a primary framework for developing iOS apps and is well-documented by Apple. It has been introduced since 2008 and is still a great framework to build interactive user interfaces. However, why Apple decided to bring SwiftUI instead?

UI bugs and State Inconsistency

UIKit it is a powerful tool for creating user interfaces for iOS apps, but the root cause of the introduction of SwiftUI is the state inconsistencies brought by UIKit.

SwiftUI Introduction, WWDC 2020

Modification of data would always result in state change that should be reflected in a UIView. What if an unexpected event occurs and UIView fails to update its state? It causes a UI bug.

Since most of the UI interactions are asynchronous, i.e. they may fire in any order, UIView is not capable of consistently updating its state. Moreover, what if we have multitude of events that would occur because of one another?

SwiftUI Introduction, WWDC 2020

Consider an example of only 4 states that are persistent on the screen. User can zoomOut, zoomIn, enhance (quality of an image rendered), completion (completion block executes). Only 4 events being fired after one another can cause these much permutations since actions are executed asynchronously. Only 4 events is 4! combinations that would be fired in any order and UIView would be inconsistent for the rest of the app lifecycle.

Data flow primitives and Source of Truth

SwiftUI Introduction, WWDC 2020

UI bugs are easily eliminated in SwiftUI by introduction of a single Source of Truth. Defining a single source of truth implies that the modification of it would cause an automatic update in the entire body of a view.

SwiftUI Introduction, WWDC 2020

Remember tricky case with 4 events fired on a screen? The problem is eliminated since the only entry point of any view in SwiftUI is its computed body property.

SwiftUI Introduction, WWDC 2020

Take a closer look at a screenshot taken from a SwiftUI Introduction view at WWDC 2020. zoomed variable defines whether a content mode for an image is fill or fit and whenever a user taps on an image, it automatically changes its content mode since a boolean variable is toggled. As the body property of a view is only an entry point, the entire view is recomputed. How simple is it? Handling UI updates has never been this simple!

Functional Reactive Programming

Asynchronous callbacks in views to change their state results in a shift to FRP. Remember we had to keep track of 4 events in state inconsistency section that would occur arbitrarily and all of them should have been handled somehow? Resolving the events in functional paradigm becomes a nightmare as the number of asynchronous events increases. 4 events being fired result in 16 different combinations that would happen in any order!

SwiftUI incorporates FRP by changing UI elements with respect to the change in source of truth. Whenever a state change is triggered, body is recomputed and the view is in a consistent state.

SwiftUI is still immature

Different great apps were built using UIKit and it is a powerful framework to be used to these days. SwiftUI has been introduced in mid-2019 and is still in progress. Apple is doing a great job by improving SwiftUI with the introduction of SwiftUI 2.0 at WWDC 2020.

However, UIKit has been a niche for so long and Apple has not yet built up the SwiftUI to the level comparable to that of UIKit. If you have ever had your hands down to using SwiftUI in practice, you would clearly notice its drawbacks since some UI elements are not direct counterparts of UIKit.

SwiftUI is immature, yet it is the Apple’s primary vision for the future for building powerful and consistent apps. Proactivity is your comrade in keeping up your iOS skills for the future!