SwiftUI in Production? 6 Pros and Cons You Need to Consider
By: Manuel Schulze
Tags: Swift, Xcode, Mobile, Swiftui, Programming

Cons (Why You Shouldn’t Use SwiftUI)

Let’s start with the negative things, things that argue against the adoption of SwiftUI in your next project.

Users on older operating systems can’t use your app

According to this unofficial data by Mixpanel, already 93.08% of users run iOS 13 or higher (last checked: 28th November 2020). That means SwiftUI can already be used by over 90% of your potential users.

That’s a large number, and pretty common for Apple’s mobile devices. It’s also the reason why we developers feel pretty comfortable to support only the two latest iOS versions in our apps.

However, you may have other requirements. If your next or current project needs to run on older devices or support an operating system version of iOS 12 and lower, you can’t use SwiftUI.

Problems will be harder to solve as no one faced them before

Let’s face it, more often than we like, we have to find a solution for our current problem by searching the internet. Stack Overflow is a common source for results.

While I want to caution you to not blindly copy and paste a potential solution, it is still great to know that there is nearly no problem that no one else has faced before.

However, that’s only the truth for UIKit. SwiftUI is only two years out and not widely used by companies in production. Therein lies the danger, that you will be the first one who struggles with the problem at hand.

I’ve created a small SwiftUI iPad app and had to work through three or four of those issues that took me a few weeks overall. Make sure that you realize that this could happen to you, too.

There are some features that are only available in UIKit so far

The last welcome additions to SwiftUI in iOS 14 include lazy stacks, a grid (like UIKit’s CollectionView ), along with many other features like adding a video player or map to your SwiftUI view.

However, there are still missing pieces to make SwiftUI able to completely replace UIKit’s ViewControllers in your apps. There is no support for WebKit or for adding a text field to an alert.

You should consider this and realize that your app may not be able to be 100% SwiftUI. But more on that later.

It will take more time because you are not that familiar with the toolkit

It probably took you some time to become a pro in UIKit, and it will take some time in SwiftUI as well.

SwiftUI is very easy to get started with. However, you may have years of knowledge in UIKit, and this includes common bugs and gotchas, how to use the controls, delegates, testing, and shortcuts.

You won’t move at as fast a pace as what you are used to.

Other developers in your team may not know SwiftUI

That’s one of the biggest issues. You may think of an older developer who has stopped learning much and doesn’t like to try out new things.

I know companies where the lead developers told their interns that they can’t use Swift because it won’t be successful and Objective-C will still be the most-used iOS programming language in ten years. They were also not allowed to use ARC (automatic reference counting) because this wouldn’t be “real” programming anymore.

I’m not talking about this kind of silly developers. Your colleagues may just not have the time and are stuck in UIKit projects. As soon as you leave (vacation, sickness, or quitting your job) the other developers will have a harder time working on your code. That’s a questionable way of making yourself more valuable for your company. You should definitely consider your current team composition and discuss this point with your teammates.

Think also about future developers that will join your company. If you are certain that they will be checked for SwiftUI knowledge, this is not a showstopper. However, if that is not the case, think twice before hopping on to the SwiftUI train.

Best practices are not yet formed

You may only work on small applications where best practices tend to be ignored. But if you want to increase your value as a developer, you should adopt common patterns that are used by big companies to build large and scalable applications.

In UIKit, we already have many great architectures and we know how to structure our code. RxSwift is state-of-the-art, and we know how to do the bindings with it. Maybe you have already heard of stuff like MVVM, coordinator-pattern, and design patterns, and how they are used for iOS projects.

Your knowledge isn’t lost and many things can still be applied in SwiftUI. However, especially in combination with the Combine framework, you have to rethink how to properly write and structure your code in order to write good SwiftUI iOS applications.

Many of those best practices for programmatic navigation and other common problems are not formed yet. Therefore, you need to consider, that you may have to heavily restructure your current project in the next years as soon as your knowledge about proper solutions increases.

One thing I really miss from Apple so far is a complete guide on how we should approach testing of SwiftUI views. Especially for enterprise software, adequate code coverage is a requirement. Sadly, I haven’t seen much love for this topic from them yet.