Easier than what? SwiftUI vs. UIKit

To fully understand the extent of positive changes, it’s important to know what preceded them. In this instance, it means knowing the predecessor of SwiftUI, a framework that has been with us for more than a decade – UIKit, which launched in 2007.

Since then, it had plenty of time to mature and so did its users. UIKit has a sizable community, meaning the knowledge is probably already available online for those facing development-related issues. Additionally, UIKit allows developers to achieve well-optimized, high-performance visuals, which is crucial when a fluent and responsive UI is required.

However, UIKit is not without its drawbacks. As an imperative framework, it has a very steep learning curve, and it can make UI building time-consuming due to how many stages need to be defined to generate the UI. UIKit is also only meant for iOS and iPadOS apps. While definitely younger, the declarative SwiftUI deals with all these problems. Before we discuss more details, let’s briefly compare SwiftUI to a similar solution created for Android developers, since it’s interestingly similar.

The Android equivalent of SwiftUI

Developers of the competing platform can write app UI in a modern way as well, thanks to Android’s toolkit called Jetpack Compose.

The similarity between the two stems mainly from the fact they are both declarative frameworks designed to tackle virtually the same challenges and streamline the UI development process. Their structure and syntax are both almost indistinguishable, and they also share the capability to sequentially yield multiple values or a data stream from asynchronous tasks. Jetpack Compose accomplishes this through Flow, while SwiftUI achieves the same with the assistance of the @Published property wrapper and the Combine API.

That being said, SwiftUI and Jetpack Compose aren’t identical. Where they differ is in framework distribution and platform coupling.

What has already gotten easier

Since SwiftUI reflects the shift that’s occurring in the approach towards UI development, it’s only natural that it manages to solve all of the above issues that troubled its predecessor.

Current trends in this area favor time efficiency and accept the fact that, at some point in the development, it might be required to completely rebuild some parts of the UI. Which is precisely what declarative frameworks like SwiftUI allow.

This also means that the likelihood of bugs occurring is greatly decreased, simplifying app maintenance and updates.

As mentioned earlier, the syntax of SwiftUI makes it much easier to learn how to use the framework. Even though its community is younger than that of the UIKit, the newer framework does not require a deep understanding of its components and APIs, so it’s easier to find workarounds independently.

In theory, the declarative nature of SwiftUI could be perceived as a disadvantage, as it provides developers with smaller customization possibilities when compared to UIKit. While it might be limiting in the case of apps that require highly customized UI, it’s worth remembering that SwiftUI is very flexible and offers a high degree of interoperability with UIKit, greatly enhancing code reusability both within itself and with its predecessor.

The development experience is another area of improvement – thanks to the live preview feature, SwiftUI allows developers to observe changes they’ve introduced in real time. Finally, SwiftUI deals with a major drawback of UIKit: the framework is cross-platform compatible and can be used for Apple devices other than those running iOS and iPadOS.

What will get easier next

Despite its core objective of making things easier, SwiftUI still has limitations that don’t allow it to make programmers’ lives a breeze.

One of the major obstacles as of now is related to the limited API coverage it has. Some features are missing, pushing devs to work around the issues or use UIKit. Another problem is the small adoption of SwitfUI. It only works on iOS 13 and later, leaving many existing apps dependent on UIKit. Consequently, if a project requires programmers to support older iOS versions, they may need to opt against using SwiftUI.

Curiously, despite SwiftUI being interoperable with UIKit, it lacks backward compatibility, forcing developers to choose between older devices and SwiftUI. The first version of SwiftUI, dedicated for iOS 13, was very limited. The next two versions brought some improvements but not crucial ones.

The optimal choice for writing apps in SwiftUI is iOS 16 and later. That release introduced many crucial changes and improvements, like improved navigation. The lack of backward compatibility can be limiting when aiming for wide device compatibility or utilizing the latest features of the newer framework.

The last major obstacle is that Apple hasn't proposed any unified architecture for apps written in SwiftUI. As a consequence, many different solutions have been proposed by the Swift developers community. The most promising one is the TCA library (The Composable Architecture). It has become very popular and it seems TCA is going to be the best choice for most projects written with SwiftUI.

However, regardless of these minor shortcomings, after 4 years since its introduction, SwiftUI is shaping up to be a very potent tool. Some polishing is obviously still required for it to reach UIKit’s level, but let’s not forget that the latter has been out there for much, much longer.

After all, even though it’s made for developers, it’s also developers themselves who form the SwiftUI community and help continuously improve the framework.