SwiftUI: should I use it in my UI project?

After a few months of working with SwiftUI, I’ve noticed a few nuances that prevent SwiftUI from being a go-to option for any UI project. Even if you don’t feel that way about SwiftUI, it still won’t hurt to have another look at the main disadvantages of SwiftUI and possible issues that might arise during the development process using this framework.

With an extensive array of valuable features, an entirely new approach to building interfaces, and faster rendering, SwiftUI is a big step up for Apple developers. However, having been released only a couple of years ago, the framework isn’t mature enough to keep up with UIKit. But what exactly makes SwiftUI lag behind UIKit? Let’s take a closer look.

Article content

1. What is SwiftUI?
2. What is declarative programming?
3. IOS app development with SwiftUI: my key takeaways
4. So, what to choose?

What is SwiftUI?

SwiftUI is a framework for building user interfaces on Apple platforms using Swift code. Released along with iOS 13 in September 2019, Apple’s brainchild made an immediate splash in the developer community. Many began talking about the imminent “death” of UIKit, its predecessor. And it wasn’t surprising: the new framework made UI development easier due to the following features:

Still, these features are not the main reason why there’s been so much buzz around SwiftUI. The greatest advantage of the framework is that it’s declarative. Let me elaborate on this below.

What is declarative programming?

In declarative programming, we specify what we want our UI to look like and do in different states. Contrast that with an imperative approach, which implies instructing our UI how we want to make it happen. It’s like asking your friend to wash your car (declarative) instead of telling them in detail how to do it (imperative). And this actually makes SwiftUI and UIKit different.

For example, we want a view to interact with input data and display a number. Here’s what the process looks like in each framework:

Given the advantages of a declarative paradigm, it’s easy to jump to the conclusion that SwiftUI allows you to build UIs with less code than UIKit. But unfortunately, things are not as clear-cut. Let’s unpack this below and try to answer the main question of this article, “Why is it impossible to build any UI using purely SwiftUI?”

IOS app development with SwiftUI: my key takeaways

As a declarative framework with a bunch of novel features, SwiftUI is alleged to make UI development faster and easier. But is this always the case? Let’s take a look at what you should keep in mind before choosing SwiftUI for your next UI project.

OS limitations

SwiftUI supports only iOS 13 and above. This means that by switching to this framework, you exclude everyone using older versions of iOS. Based on data provided by Mixpanel, 4% of Apple users won’t be able to access an app built with the help of SwiftUI, which is millions of people.

The lack of expertise

Frameworks aren’t learned overnight, and the lack of sufficient expertise is a common challenge associated with brand-new technologies that evolve fast. That’s why if you are planning to use SwiftUI for your next project, be ready for unexpected problems. For example, your SwiftUI developers might not be able to properly support and maintain a solution they built, and you might need to hire additional talent.

Insufficient support

If you look through SwiftUI’s documentation at Apple Developer, you’ll notice that it covers the basics of SwiftUI development without going into detail. Of course, we don’t expect granular descriptions. Still, the framework is strikingly different from what we had before, so it’s sometimes unclear how we should use this or that component.

There are other places to find information about SwiftUI. But here’s another catch: since the framework was released just a couple of years ago, you might find yourself facing an issue nobody has experienced before. In contrast, UIKit offers a huge knowledge base on tackling UI development challenges of varying complexity, which accelerates the development process. No doubt, SwiftUI users will achieve the same level of know-how, but it will take some time.

Complexity issues

There’s no denying that SwiftUI makes development easier. However, based on my experience, this applies only to building simple interfaces. This means that if you need to code, say, something like a Facebook user profile, SwiftUI (in its current state) isn’t your best option.

The trick is, building complex interfaces with SwiftUI implies nesting multiple views and subviews inside each other, and it’s easy to get lost in these hierarchies. Plus, to make a view dynamic, you’ll need to include multiple “states” to control its behavior. That’s not to mention adding more elements to such code or (please, no!) reading and analyzing it.

In addition, SwiftUI doesn’t have essential elements (or their equivalents), such as UIActivityIndicatorView, ImagePicker, UIViewControllerTransitioningDelegate, or UIModalPresentationStyle. Of course, you can add them separately as wrappers over SwiftUI’s standard views, but this implies more chaos code, especially if you need to make up for more than one missing component. In this case, the chances are that finishing a UI project using purely SwiftUI won’t be possible. So what’s the point, then?

Performance

Certainly, SwiftUI isn’t all disadvantageous. For example, when it comes to a product’s build time, SwiftUI can outperform its predecessor for two reasons. First, SwiftUI stores all view hierarchies in value-type structures, so you don’t need any additional memory allocations. Second, SwiftUI “redraws” a view only when its state changes. Both factors lead to a boost in development performance in some cases. So, in this battle, SwiftUI wins over UIKit.

In terms of an end product, I haven’t noticed any differences in rendering speed or other performance indicators between the frameworks. Which isn’t surprising: SwiftUI has UIKit running behind the scenes.

So, what to choose?

Numerous SwiftUI tutorials are singing the praises of the framework, saying that SwiftUI makes building awesome apps easier and faster. However, if we try to dig deeper, it becomes clear that SwiftUI will hardly suffice even for building a product of average complexity. In my opinion, SwiftUI, for the time being, lags far behind UIKit.

Still, if we look at both frameworks from a broader perspective, we’ll see that each has its own strengths. For example, SwiftUI is an ideal choice for simple projects, such as watchOS apps. It can also be a go-to option for anyone who prefers visual-oriented development or can’t stand writing too much code manually. However, if you need a time-proven tool for building complex solutions, UIKit is probably what you need as it gives a higher level of control.

No matter which framework you decide on, I strongly recommend making a choice before the development process begins: switching from SwiftUI to UIKit or vice versa often implies writing the entire code from scratch. Sounds overwhelming? Don’t despair. At NERDZ LAB, we offer a full range of iOS application development services. Our experts will help you with choosing a suitable framework, building a stellar UI, and beyond. Just contact us.