SwiftUI vs. UIkit: A Mobile Developer's Perspective

With the introduction of SwiftUI in 2019, Apple made clear what direction it wanted developers to take on the framework. Many saw it as a move needed to bring the Apple ecosystem to new heights—especially in terms of innovation and competitiveness.

Others, however, saw many unnecessary obfuscations. They worried that Apple was willing to sacrifice the power of UIkit for approachability and ease of use.

So, which is it? Is Apple pushing for innovation and ease of use? Or is Apple prioritizing approachability over the power of UIkit?

In this article, we’ll explore the disparities between SwiftUI and UIkit. We’ll examine their approachability, performance differences, community support, and testing. All this is focused on informing you if you’re an engineer debating which workflow to embrace.

Let’s get started.

SwiftUI vs. UIkit: A Little History

Those of us who develop for the Apple ecosystem have rarely been spoiled with options. We had a long period with only Objective-C and some C++ for the hardcore. Since the introduction of Swift, developers have had the pleasure to see a language evolve and bring innovation. However, in terms of UI development, we’ve had UIkit to work with only.

Ever since iPhone OS 2, UIkit has been the framework available to create views and design the user experience in iPhones. For more than 11 years, UIKit has evolved and matured into a powerful and versatile framework for UI development. As a result, the UIkit community has had time to create a wealth of know-how. And this means developers have been able to create elegant and high-performing apps that are successful in the market.

SwiftUI, on the other hand, is bringing new paradigms and workflows to the platform. In addition, it brings bold and ambitious tools that simplify and modernize the development experience. So, a somewhat archaic and cumbersome development process becomes more streamlined and intuitive.

Approachability

First, I want to clarify what I mean by approachability. To me, it’s the apparent ease of use and intuitiveness of the platform. How inviting is it for engineers who have no knowledge of it?

To illustrate, here’s what you see when you start a new SwiftUI project.

It’s friendly, minimal, and intuitive.

All right. How about a new UIkit project?

I wouldn’t blame you if you ran away the moment you saw this intimidating disaster.

To this day, I still don’t understand what was in the minds of the folks at Apple when they decided that the first window of a new project should be the project configuration panel.

In this regard, SwiftUI is the better choice.

Before the introduction of the Swift language in 2014, the idea of focusing your career on developing for iOS required some thought and consideration, to put it mildly. Objective-C is still considered an “odd one” in the programming language family, and many people found it obtuse and unintuitive.

That’s not to say that UIkit appeal should be equated to Objective-C. Nothing could be further from the truth! After all, you can program for UIkit in Swift.

But the point stands that the team at Cupertino saw UIkit as a remnant of the old age of programming history. And many developers in the sphere agreed that change needed to happen.

Also, working with storyboards can be hectic and overwhelming. With UIkit, you still have the option to work with a more programmatic UI workflow by creating nibs. But Apple heavily pushed the storyboard workflow until recently.

Performance

For this aspect, I’ll consider app performance and developer performance.

I haven’t noticed any discernible difference in the performance of both frameworks in terms of the final product. Since SwiftUI uses UIkit and AppKit behind the scenes, this means that rendering isn’t any faster.

However, in terms of development build time, SwiftUI usually performs better than UIkit. That’s because the hierarchy of view resides in value-type structs stored on the stack, which means no costly memory allocations. And that means greater performance in some situations.

Also, the fact that you can glance at your changes while developing dramatically enhances productivity.

Therefore, I have to give SwiftUI the win on this one.

What’s next?

Support

This one is no competition. UIkit’s extensive wealth of know-how and documentation, available for all developers of all levels, greatly outnumbers what’s available for SwiftUI.

Don’t believe me? Go to Stack Overflow, and count the number of questions and answers available for each platform.

So there are 41,917 results for SwiftUI.

And there are 94,687 results for UIkit. That’s more than double!

Now, is this the most reliable assessment of the amount of support you might find if you decide to embrace one or the other? Probably not. But it’s a solid indication of how the community has matured over the years and how likely you might find a solution to any issue you might have.

There’s been momentum from the embrace of a very prolific community of developers. And all of them are eager to get their hands on a more modern framework. Coupled with the extensive work they’ve done to create documentation, it might be years before we get to the levels the UIkit community has achieved. However, with such a professional community and an extremely fertile and profitable market as the Apple ecosystem, it will happen!

Let’s move on to the next factor.

Testing

I’ve found the lack of documentation on testing appropriately and simulating user behavior on SwiftUI elements quite frustrating. At times, it’s even been off-putting. Of course, that’s not to say that it’s deterred me from finding my own solutions. And those seem to yield good results most of the time. But if you’re considering working with SwiftUI, I think you should be aware that this is the one aspect that has matured most slowly for the platform.

Creating UI tests with XCTest is pretty similar between SwiftUI-based applications and UIKit-based applications. Yet, for some reason, the engineers at Cupertino chose to neglect the documentation on how to simulate behaviors properly.

Fair warning: I haven’t explored the UIkit side of creating a test in XCTest in about four years. So, please take my advice with a grain of salt.

Is testing is a critical aspect of your development cycle? (Let’s be honest—it should always be!) Then I recommend you consider Waldo.io‘s code-free testing solution. Waldo has an extensive toolset for UI testing, which is very intuitive and productive. There’s also a helpful blog with articles on mobile design and mobile engineering. You can try Waldo for free.

So Who Wins?

All right, then. What’s the best option?

Both frameworks have their strengths and bring different values to developers, depending on their preferences and priorities.

Suppose you’re more comfortable with the more modern and graphic-centric workflows from other platforms. Also, you find manually coding views cumbersome. In that case, you might prefer what SwiftUI is bringing to the table, especially if you don’t want to stray too far from the standard tools offered by the team at Cupertino.

However, what if you’re looking for a tool that offers you the power and customizability to create complex solutions that seasoned developers manage? In that case, maybe UIkit is still the best option. Working with storyboards or even just nib files offers a level of control that you might struggle to reproduce in SwiftUI. And that’s one of the main reasons some find it difficult to part ways from it.

The days when the prospect of developing for the Apple ecosystem was intimidating and costly are long gone. (Well, maybe it’s still a bit pricey.) Nevertheless, it’s now easier than ever for a new developer to pick up Swift and start creating elegant and high-performing solutions for the platform in a profitable market.

SwiftUI still needs some polishing. There are still aspects with limited features, and much needs to be added to get to the maturity levels that UIkit has achieved.

Nevertheless, the engineers at Apple are now entirely focused on bringing all the bells and whistles to their new platform and giving developers the power they’re used to in this era.

Learn more about Waldo's SwiftUI support here.