SwiftUI in Production? 6 Pros and Cons You Need to Consider
Should you use SwiftUI or UIKit in your next project?
SwiftUI was introduced at WWDC 2018 and has been supported by iOS since version 13.
Usually, two years are enough for us, the iOS developer community, to start using a feature in production code. However, for really big changes, like moving from Objective-C to Swift or now from UIKit to SwiftUI, a little more analysis is required.
Here are 6 cons and 6 pros that will help you make a profound decision for your next or current iOS project.
Cons:
- Users on older operating systems can’t use your app.
- Problems will be harder to solve as no one faced them before.
- There are some features that are only available in UIKit so far.
- It will take more time because you are not that familiar with the toolkit.
- Other developers in your team may not know SwiftUI.
- Best practices are not yet formed.
Pros:
- You can use previews and live previews for rapid UI development.
- SwiftUI makes it easier for designers and web developers to work with you.
- You will write less code to achieve the desired result.
- WidgetKit extensions require SwiftUI and you may need to use it anyway.
- It’s an opportunity to learn a valuable skill and the toolkit of the future.
- In the future, it’s easier to find developers that can work with SwiftUI.
This article will show you why the decision is not that easy and provide a solution that may help you if you still can’t decide between SwiftUI and UIKit.
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.
Pros (Why You Should Use SwiftUI)
Okay, maybe now you are already thinking SwiftUI is not production-ready. That’s why I now want to show you why you actually should start your next project in SwiftUI.
You can use previews and live previews for rapid UI development
SwiftUI provides us with a beautiful preview feature to immediately see the results of our code changes to the view.
That comes in especially handy when you consider that many modifiers produce different results depending on their order.
Consider the following code.
Both Text views have the same modifiers. However, the results are completely different:
The preview and especially the live preview, where you can even interact with buttons, etc., can really help to avoid unexpected behavior and many rebuilds for the simulator.
SwiftUI makes it easier for designers and web developers to work with you
As mentioned above, SwiftUI has a beautiful preview. The preview is not just great for us as developers, it also helps those who are not familiar with Storyboards, like designers or web developers.
You actually can create some of the UI with code but another part of it just with the powerful UI tools that Xcode provides to create SwiftUI views. You can even build complete user interfaces without the need to write a single line of code.
If you work on a team with a technical affine designer, it could make sense to show them the basics and let them create the user interfaces on their own. This reduces the coordination between the two of you and lets you focus on implementing the business logic, which will allow for faster feature deployment.
One bonus point here: I also like that the SwiftUI code and views are always in sync. With storyboards or xib-files, you always had to remember where you changed certain properties. You also couldn’t easily find changes that you’ve made in the visual tools because they never produced code that was easy to search for. With SwiftUI it doesn’t matter if you write everything in code but your colleague uses the visual tools. There is always code and its visual presentation.
You will write less code to achieve the desired result
You may have heard it already, but SwiftUI reduces the code you need to write in order to build your user interface. There were many example apps, but I like the comparison of Paul Hudson on his YouTube channel:
Note: Be careful here. Yeah, Paul was faster with SwiftUI, and you will be faster in the future as well. However, if it’s one of your first SwiftUI projects, it doesn’t make much sense to compare yourself to a person who has already written a good amount of SwiftUI tutorials and books over the last two years.
They say the best code is the one you never write. Therefore, it’s great to see how much the lines of code (LOC) can be reduced just in a small app. That’s really something I like a lot.
WidgetKit extensions require SwiftUI, and you may need to use it anyway
WidgetKit extensions were introduced in iOS 14. They are really appreciated by the users, so it’s logical that many apps that you write will also provide a WidgetKit extension.
However, due to the short time that your code has in order to load and display its information, the widgets need to be lightweight. What else could be used for that task than those lean SwiftUI view structs?
Apple only allows WidgetKit extensions when they are written in SwiftUI. If you have to use SwiftUI anyway, it is maybe a good idea to use it for the whole application as well.
It’s an opportunity to learn a valuable skill and the toolkit of the future
In the future, more and more features will be added to SwiftUI. I’m certain that it will be the defacto standard to create user interfaces in Swift.
You can wait until you adopt it and go with UIKit for another five years easily. Yet, at some point in time, you will find fewer projects that use UIKit. So why don’t you learn it right away?
Now, could be a great moment to get a head start with this framework and become an expert before the others start learning it. It can be very beneficial to be an early adopter. This is definitely a great skill to have to progress in your career as an iOS development expert.
In the future, it will be easier to find developers that can work with SwiftUI
Oftentimes, we think a lot about how we can write clean code that will be a pleasure to work on a few years from now. That’s a good thing!
However, we also often forget how the business for which we work could evolve. New, younger developers will join our team. I often meet new developers who never learned Objective-C.
Imagine I still write every single project with Objective-C, Then I leave the company as my contract ends, and the company hires a new developer who only knows Swift. They will have a hard time maintaining my code.
That’s not exclusively a problem for contractors like myself. Your company will hire other developers, and you don’t want to give them three-week UIKit training just because you decided against SwiftUI a few years back.
Do yourself and your future colleagues a favor by using SwiftUI as soon as possible.
The Hybrid Approach
Both sides, pros and cons, have valid points. Even if there are no dealbreakers against SwiftUI (like support for iOS 12 and below), you may still struggle to decide what to do in your next project. That’s why I want to help you make a decision.
If you can’t decide, use both.
Apple did a fantastic job by allowing us to use a SwiftUI view inside of UIKit and start a UIViewController from SwiftUI. For my next project, I will try to start with SwiftUI to keep my code modern and lean. If I reach a point where I can’t find a solution in SwiftUI, and if UIKit provides support for the feature without using third-party code, I will switch.
It’s worth giving “SwiftUI first” a try — just make sure that you know the consequences.
If you are still anxious about starting the new project in SwiftUI, it’s a good idea to slowly transition. Start with what you are familiar with in a plain old UIKit project and use SwiftUI views here and there while getting used to the new way of building UIs in iOS.
Note: A WidgetKit extension is always a good place to start SwiftUI.
Conclusion
SwiftUI is a great tool to write user interfaces for all Apple devices. It’s great to see many designers and developers with different backgrounds joining the community.
However, for some of you, it will still be too early to adopt SwiftUI for the next project. That’s okay, we have side projects where we can play, and WidgetKit extensions provide us with a great place to start with SwiftUI.
If you struggle to decide between UIKit and SwiftUI, try to use a combination: either “SwiftUI first” or a conservative UIKit project with some SwiftUI views here and there.
With that, thanks for your time, and have fun with SwiftUI!
