You are a Technology Manager at a medium or large company - when is the right time to embrace SwiftUI?
In June 2019, at Apple’s Worldwide Developer Conference (WWDC), Craig Federighi, Apple's senior vice president of Software Engineering introduced a new declarative method for building User Interfaces across all Apple’s platforms (iOS, macOS, tvOS and watchOS). This built on the announcement of a new programming language, Swift in 2014 at the same event.
SwiftUI is an incredibly ambitious project, almost as ambitious as the Swift language itself, it allows developers to create data structures that translate to user interface views with all the controls and features that an app may need. It can make prototyping incredibly fast and responsive particularly as you can see a live preview of the UI right next to your code in Xcode or on a real device connected to your machine. This will update in real time as the data structure is changed in the Xcode editor window. So, your developers have been champing at the bit to use this new coolness ever since they took a case of beer to a spare meeting room to watch the WWDC Keynote, hanging on Mr Federighi’s every word (to be fair - that is what I did!). Should you embrace this technology now? Will it save you significant time and effort in development? Perhaps unsurprisingly, the answer may be different depending on who your customers are and specifically what your product is.
Know Your User
Well, this is a overused and well-worn phrase and this is largely because it holds a lot of value in all aspects of product design, however in this situation you really need to know what proportion of your user base is running the latest version of iOS - iOS 13.
Apple’s stats show that (at the time of writing) almost 80% of devices introduced in the last four years are running iOS 13, this drops to around 70% for all devices. This is around about the historical norm for iOS releases, 6 months from release.
You can use the data that Apple provides on App Store Connect to check the stats for your own app, this may differ from the high level figures if your app user base has a niche or skewed demographic.
Why is this important?
Apps that use SwiftUI, even with only a single view will only install on devices that are running iOS 13 or above. This means that any users that are not currently running the latest OS will either be unable to install your app or will have to make do with the last version released that does not include SwiftUI views (assuming you have one).
If your user-base are tech-savvy iPhone users, there is a good chance they are on iOS 13 (the OS will prompt you to upgrade ceaselessly so many people will have taken the plunge to upgrade just to stop the nagging), however if a significant number of your users are on older devices (particularly iPads that tend to be held on to for much longer) or are more elderly, it is quite possible that you will lose a significant chunk of your users if you move to SwiftUI too soon.
It probably "ain't broke"
If you are starting a brand new app from scratch then SwiftUI may well be a good choice (although read on for caveats). However if you already have an app that was built using previous UI development processes then you will already have UI views built using Storyboards and Xibs. You probably have implemented Design Patterns across your app. It makes little to no sense to covert these existing views from Storyboards to SwiftUI - you will have invested many hours of development and more importantly testing in these views and they are presumably battle-tested in the real world. You will have fixes and workarounds that are important, but no-one will remember why, you need a really good reason to relearn all the mistakes you made first time around - worst of all, none of your users will know or care, Joel Spolsky’s 20-year-old article still explains this better than anyone.
This does not mean that new views should not be written using SwiftUI - Storyboards and SwiftUI views can coexist very happily. You just need to not to throw out the baby with the bathwater.
There is, perhaps one exception to this "don’t refactor" rule - if you have views that are extremely dynamic and need to change frequently based on changes in the underlying data then SwiftUI is incredibly powerful when used with Combine - another new Apple framework that automatically pushes changes to your views when the underlying data changes, whilst Combine can be used with ViewControllers and Storyboards, it works best with SwiftUI - again tread carefully so as to not unravel significant amounts of working code for very little end-user benefit.
The State of SwiftUI
Finally, we come to the SwiftUI framework itself.
SwiftUI is a huge investment from Apple, following hot on the heals of its equally huge investments in Swift and APFS. SwiftUI is clearly the way that Apple wants developers to work in the future, although Storyboards will be supported for a long time to come. It seems likely that as new features are introduced, they may at some point only be available for SwiftUI, this is in fact already the case for watchOS. Apple is already developing new frameworks only for Swift and not porting them back to Objective-C it seems likely that the same will be true for SwiftUI in a few years.
All that said, SwiftUI is showing its immaturity in some places - Xcode support is not as good as many developers would like and error reporting can often be cryptic, opaque and can reflect the building blocks underneath the framework, rather than the framework itself. Additionally, it is easy to forget that building UIs using a declarative structure rather than a drag-and-drop user interface requires a paradigm shift in the mind of a developer and so you will have to make a significant investment in allowing your developers to retrain themselves in both approach and syntax. Much like your codebase, they will have knowledge that has been built up over a decade or more that has given them a deep understanding of how to build apps and UIs. Throwing all this away (like throwing away your existing app code) requires a significant reset and whilst it may well bring benefits down the line, there will certainly be a cost right now.
Conclusion
So, to answer the question I posed at the beginning of this article - Is SwiftUI ready for the big time? As often is the case with complex tech questions the answer is probably “it depends” - however I think the general answer for most medium to large companies the answer is probably “not yet”. The immaturity of the tooling, the dependency on a 6-month old OS (that has had more than its share of bugs and instability) means that unless you are building a brand new app for release in Q3 2020 or beyond, I would caution against taking the plunge just yet.
WWDC 2020 is unlikely to go ahead in the normal manner - COVID-19 will almost certainly mean that it will have to become a “virtual” conference, I suspect the only reason Apple has not yet announced this, as I write, is that they are still planning whatever they are going to do in its place. However I think we can expect that Xcode 12 and iOS 14 will still be announced in June 2020. We must hope that they bring greater stability and tooling to the frameworks introduced in 2019. Come September 2020 when these new version exit beta, it is probable that this will be the point at which the time will be right to embrace SwiftUI.
TL;DR: Be patient for now.