There is no better time than now to write about the reasoning behind using Swift UI or UI Kit in your native iOS apps. Why now? iOS 16 brings many new, exciting features. What’s more important, is that it gave us developers all the goodies that come with the latest iteration of the Swift UI; we can use the latest APIs that were recently unavailable.
Lucky Coincidence? A Well-Planned Strategy?
You may call it a lucky coincidence or well-planned strategic decisions by Apple engineers when crafting the complete update experience, but the reality is that iOS users tend to keep their devices updated more than not. That’s important because it defines what APIs can be used and keeps the balance between supporting older OS versions and being efficient at developing with latest APIs. The fragmentation of system versions is not as visible as it used to be (and still is) in the Android world.
Obviously, not all users update their devices the same day an update is available (one aspect is the bugs, another is not everybody has the mind or the internet connection for it). That would have been too good to be true; at least for us, developers. That’s why we rarely see an app that supports just the latest version, especially if we’re still freshly after the date the update was made available.
From our experience, apps usually support the latest 2 major releases of the operating system, i.e., iOS 15 and iOS 14. The time in the fall after Apple publishes the new major OS update is always the time when we would drop the oldest version and (eventually) clean up the code to go with the new set of the latest features supported by the last 2 major OS versions. For example, following that logic now we’re getting into the period where it is time to increment the minimum OS version needed to run our apps to iOS 15. Keep in mind, the decision about what’s the minimum version that we should keep supporting was always made by looking at usage statistics for the app. It’s just that repeatedly, year over year, we were finding out that eventually in the fall most users were running one of the 2 latest iOS versions. If most of your users are still using the iOS version from 3 years ago, don’t drop the support for them.
That’s good news for Swift UI as when targeting iOS 14 there are some significant APIs missing, and we would easily hit major obstacles if we wanted to do “too much” with Swift UI and still wanted to support iOS 14.
We’ll show some code examples about how we could implement some features that would be not worth the effort if we wanted to create those features in the declarative Swift framework. On the other hand, iOS 15 provided solutions to all those listed issues, and we will demonstrate how a solution would be created with Swift UI.
If our job was to create a UI element that was supposed to display a text, where every character could have its own attributes, we would choose UI Kit when targeting iOS14. Since now, we can drop iOS14 and keep only iOS15 and iOS16, we may safely use Swift UI. The code examples below show how to achieve more-or-less the same result, but first using Swift UI, and then using UIKit.
Let's dive in.
Let's start off with a simple task.
Creating a Text View Where the Text Is Colored as a Rainbow, Every Character in Its Own Color.
The ContentView implementation
And the RainbowText implementation
For the sake of comparison, here’s a UIKit implementation for a similar UI component:
Navigation on an iPad
Here’s an example with navigation, UIKit vs. SwiftUI (iPad-specific)
CoreData & Two-Directional Collection View
Do notice the difference in the length between the implementations.
In the projects from the past five years, it's hard to find an edge case that would make using UIKit a better choice. Surely, there still are completely valid use cases where it makes sense implementing a specific UI feature with UIKit. If a few years ago you wanted to have an app that’s mostly built with UIKit, and occasionally you would include a Swift UI view in just some parts of the UI; as a component wrapped in a container. Currently, we could say that we have the opposite situation: we should be able to build apps efficiently using the new framework and eventually if we run into an edge case where a Swift UI implementation would exceed the expected complexity, then you implement that component using UIKit and just wrap it with a Swift UI view.
One last thing; Swift UI's learning curve. Probably the majority of us would agree it’s quite a gentle learning curve. Especially when looking at Swift UI demo videos from Apple or following some tutorials, the learning curve seems even gentler - you can easily achieve all the results you want...
...except when you don’t. Until you get enough mileage, it’s easy to make an error and spend hours to find a solution and eventually giving up and falling back to good old UIKit. The better you know it, the easier it is to fall back to it, too. But the time is right, embrace Swift UI with open hands, it won’t bite. Alternatively, if you need help migrating to SwiftUI, contact us, and we will be glad to help.