SwiftUI is fantastic, but not perfect. Some of these imperfections are expected from a nascent 4-year-old framework, but just one creates the roadblock to wider adoption.
Today, I’m going to tell the story of my SwiftUI journey at 3 startups; and explain my solution to the critical flaw preventing you from using SwiftUI full-time.
SwiftUI through the years
I’ve been lucky enough to be primarily using SwiftUI since its inception.
When the beta dropped in 2019, I was working on a side-project-slash-start-up, Fixr—think Uber for car repairs. Like all naïve engineers on our first rodeo we decided to build everything before getting our first customers.
This app had everything. A map, onboarding, profiles, job requests, payments, a repair-in-progress flow, and a second companion app for mechanics. It’s safe to say it was a pretty complex beast, and it’s safe to say SwiftUI was not ready for this in late 2019 and early 2020.
Early UIKit inter-op was janky and it was difficult to pass state about. This was a problem when two major features used the Google Maps SDK (MapView didn’t exist!) and the camera. Worst of all, Navigation was entirely broken in SwiftUI 1.0. We eventually ended up using modals for the vast majority of in-app navigation.
I co-founded Carbn in late 2020; a startup aimed at helping you develop greener habits and reduce your carbon footprint. By now, iOS 14 had come out and SwiftUI was ready for showtime. We got @StateObject, lazy stacks, ScrollViewReader, and my favourite - matchedGeometryEffect - but most importantly, people started to work out how to use SwiftUI to structure apps properly.
Today, I’m mobile engineering lead at Gener8, where we’re helping you to control and get value from your own data. We’re fortunate enough to target iOS 15+, giving us access to material effects, refreshable, the task modifier, markdown rendering, and more!
It’s safe to say SwiftUI is chugging along on all cylinders now; and at some point in the last 4 years it went from an experimental toy to a fully-fledged UI framework on which you can build a serious business.
…but is it production-ready?
Look, if you use it in production, then it’s production-ready!
Before Swift got ABI stability, there was a sizeable minority of Objective-C folks who denied that Swift was ready for the big leagues. We’re likely to hear the same characters evangelising UIKit in 2030 (I haven’t met anyone who still does this with Storyboards, at least).
I’ll briefly look at what SwiftUI does well, what it does badly, and what might be stopping engineers from committing to SwiftUI fully.
SwiftUI
…the good
You don’t need me to evangelise SwiftUI, so I’ll be brief. It’s fast, it’s declarative, all that good stuff. It’s reactive; giving you the power of unidirectional data flow out of the box. It’s the future.
…the bad
SwiftUI isn’t perfect of course. Navigation has always been janky. There’s limited support for old-school UIKit-based frameworks like AV, Camera, and Maps (at least, prior to iOS 17). Since it’s not yet a mature framework, there’s often things missing that require dipping into UIKit. Finally, the rendering engine uses a clever mix of CoreAnimation, UIKit, and Metal under the hood, which is a little bit more ‘magic’ than with imperative frameworks - this makes down-to-the-bit performance optimisation more difficult.
…the ugly
Frankly, Apple is in denial that anything other than single-view or master-detail apps exist. As with all young frameworks, the OS version is a moving target, meaning an uncomfortable amount of if #available throughout your code when you want to use the latest kit. Finally, it can be tough to get SwiftUI playing well with a large amount of existing UIKit code - since state management behaves so differently.
SwiftUI is fantastic, but not perfect. Some of these imperfections are expected from a nascent 4-year-old framework, but just one creates the roadblock to wider adoption:
Let’s focus on navigation
Navigation is the #1 issue stopping people from fully committing to SwiftUI. There simply aren’t natural options available for large, complex apps. Allowing the state of your app’s data to define navigation works great for toy apps, but scaling this up is exhausting. You shouldn’t need to hold your app’s entire state in your brain to reason about which screen needs to be presented.
Really, the underlying issue is…