SwiftUI's Pros and Cons vs UIKit

This article is for the Day 24 of the Unifa's Advent Calendar 2022.

Greetings everyone! My name is Cyan and I'm working as an iOS Engineer at Unifa. For today's blog post, I will be going through some of the pros and cons of SwiftUI against our usual UIKit. SwiftUI and UIKit are two different UI frameworks used for building apps for Apple platforms, such as iOS, iPadOS, macOS, watchOS, and tvOS. UIKit has been around since 2008 while SwiftUI has been around since 2019.

Recently, I've been trying to learn SwiftUI on my free time. I've used UIKit all throughout my entire career and through the years I've actually noticed some of the little things that bother me while using UIKit. Thus when I tried SwiftUI for the first time, I was really surprised on how good it was, and how easy it is to create things. Whereas in UIKit, it would take quite a few steps to implement something, however in SwiftUI, it will just take a single line of code.

Let's get right onto it. Here are some of the pros and cons of SwiftUI compared to UIKit.

Pros of SwiftUI

Solving merge conflicts is way easier on SwiftUI

In UIKit, if there is a merge conflict on a Storyboard/XIB file, basically you just have to choose which change you will use and the other person's changes is just lost, and that person's efforts are now gone. In order to prevent this from happenning, you have to always make sure that no two developers are working on the same Storyboard/XIB file at the same time.
But since SwiftUI doesn't use Storyboard/XIBs, you can just easily fix merge conflicts just like you would on ordinary .swift files.

Making UI is faster

This entirely depends on the expertise of the developer. But I noticed that when I am trying to implement some things on SwiftUI, it would take less steps compared to when I am implementing them using UIKit. I am just going to put some examples here so you could see what I mean.

Creating ScrollViews

For UIKit, I actually have a note about the step by step guide on how to implement it since I always forget how to implement it properly. Although, you could also implement it via code as well.

For SwiftUI, you just have to use a ScrollView, enclose a VStack inside of that. Then, in your VStack, just put the elements inside. Could be a Text, an Image, or any custom View you have created.

Creating TabViews

For UIKit, you could either set everything up in Storyboard/XIB, or write it via code as well.

For SwiftUI, similar to implementing of the ScrollView, you can just enclose your elements inside the TabView, then the tab items should just have the .tabItem modifier.

Creating TableViews

For UIKit, you could also either set it up in Storyboard/XIB, or write the setting up of constraints via code but that actually takes a lot of time to do.

For SwiftUI, just put the elements in a List and your job is done.

Live Preview

Another great feature of SwiftUI is the Live Preview. SwiftUI is designed to be more reactive and responsive to changes in the underlying data. When the data changes, SwiftUI automatically updates the user interface to reflect the changes. This can make it easier to build dynamic and interactive user interfaces.

For UIKit, you have to change something on the Storyboard/XIB or on the code, then you have to keep re-building and re-running the project to confirm the changes. Depending on the machine you use, it doesn't take that much time, but having to re-build and re-run the project just to see the minor changes you have done is kinda hassle sometimes. In SwiftUI, just changing the code will trigger the update in the LivePreview screen, and this is really amazing in my opinion.

Declarative Programming

SwiftUI is a declarative framework, which means that you describe the user interface using clear, easy-to-read code, rather than imperative code that tells the system how to build the user interface. This can make it easier to write and maintain code. Basically, SwiftUI kinda does it much more smarter than UIKit, because you would just tell SwiftUI to use a List with these elements inside, and everything from setting up the constraints are done in the background. However for UIKit, you have to tell it everything how to implement things.

Cons of SwiftUI

Some developers might not know SwiftUI yet

So if you are working on a team of developers, if you use SwiftUI on your project, some of the other developers might not know SwiftUI yet. SwiftUI uses a different approach to building user interfaces than UIKit, which can be challenging for developers who are used to UIKit. It may take some time to learn and become proficient with SwiftUI.

Some things can be done in UIKit only

Some things can only be customized using UIKit so using SwiftUI can be limited in some cases
For example, if you want to show rich editable text you would use UITextView in UIKit, but SwiftUI’s own TextEditor will only handle plain strings. Or if you want to show a text field in an alert, it’s right there in UIKit but not possible with SwiftUI.
Another thing that I have noticed as well is the adjustment of the table's separator inset. At the moment, you can't do that in SwiftUI, but in UIKit you could do that very easily. These are straightforward in UIKit, but unavailable in SwiftUI.

Can only be used on iOS 13 or above

SwiftUI requires iOS 13 or later, which means that it may not be suitable for building applications that need to support older versions of iOS.

It is still a relatively new framework

SwiftUI is a relatively new framework and is still evolving. As a result, it may have fewer features and capabilities than UIKit, and it may be less well-documented and supported.

Summary

It seems that you need to write more code in UIKit order to achieve the same things in SwiftUI. Just to implement a simple UIScrollView / UITableView / UITabBar in UIKit, I had to do a lot of setting up of constraints from the Storyboard/XIB file, or on the swift file if you are implementing it via code. However, in SwiftUI it is just enclosing the things inside the ScrollView / List / TabView. I think you could already see how simple it is to implement stuff in SwiftUI.

In summary, SwiftUI offers many benefits over UIKit, including a more modern and reactive design, greater flexibility and adaptability, and easier-to-read code. However, it may not be the best choice for all developers or situations, especially if you need to support older versions of iOS or if you are more familiar with UIKit. I am so used to UIKit for a long time now, and now that I have seen the capabilities of SwiftUI, I think I will start learning it as well since in the next coming years, SwiftUI might takeover UIKit. Just like how Swift overshadowed Objective-C. But that is life in tech, you adapt to advancements of things or else you'll get left behind.

Well, thank you so much for reading! It is my first time posting a tech blogpost, so I might not be so good at it. Hoping I'll get better at it in the next coming blogposts so stay tuned! :)

On another note, UniFa is actively recruiting. If you're interested, please check our website for more details: unifa-e.com

ユニファ開発者ブログ

ユニファ株式会社プロダクトデベロップメント本部メンバーによるブログです。