Two years after the launch of SwiftUI, are we now at the point where you will benefit from switching to SwiftUI for interface building on Apple platforms?
It's never a simple task weighing up a shift in app architecture. Is SwiftUI ready to take the strain?
Our Apple development expert Chris explores the ins and outs of adopting SwiftUI for commercial iOS application development and deployment.
The change from UIKit to SwiftUI is at least as disruptive to a development team as the change from Objective-C to Swift, and it has taken a similar amount of time for SwiftUI to be ready for use on real world projects. Just over two years after it was launched, we have reached a point where your team really should be looking to benefit from switching to SwiftUI for interface building on Apple platforms.
When Apple first announced SwiftUI in the summer of 2019, only the foolhardy would have thought of building production apps in it. It only covered the features needed in the simplest of apps, the error messages were incomprehensible, and all sorts of edge cases did not work correctly.
Even then, the potential advantages of the technology were evident, and two years of updates have brought it to the point where it is ready for commercial deployment - so you should be planning for the right time to switch toolkits.
What are the benefits of moving to SwiftUI?
There are many positives to using SwiftUI for your new mobile app development projects...
Simpler adoption of Apple good practices Apple encourages developers to handle dynamic type flexibly, to space items properly on the screen, and to work correctly for light and dark screens. All of those things happen effortlessly when you start using SwiftUI (although you can break them if put your mind to it).
Easier cross-platform / cross-size adaptation SwiftUI encourages better ways to package controls than UIKit does, and this leads to more adaptive interfaces. That helps both with targeting different device types and different screen sizes.
Great for table-based apps The declarative nature of SwiftUI results in much less code for table based apps than is needed in UIKit. The use of custom cells is also greatly simplified. Flexible, expressive tables are my favourite improvement of SwiftUI over UIKit, and the multi-column tables introduced in iOS15 for large devices are going to encourage some great new apps.
Fantastic for Form-based input The app that pushed me into using SwiftUI was a questionnaire app which had a form with 30 inputs, many of them dependent on previous answers. It would have been a bit of a nightmare to build in UIKit, and was significantly easier with the Form feature of SwiftUI.
Better handling of state Declarative systems like SwiftUI make you think through what your interface will look like in all states, and encourage you to have a more explicit model of state that is the default in many UIKit based interfaces. This means your app is less likely to get into some strange state.
On average, less code does more Table-based apps take a lot less boilerplate to build in SwiftUI than they do in UIKit.
Avoid the storyboard team development blockage One of the perennial complaints from teams working in GIT using Storyboards was that the storyboard was a significant bottleneck that was hard to use collaboratively. The distributed, code-based nature of SwiftUI interfaces mean that bottleneck has gone away.
What are the challenges of SwiftUI?
The changeover to SwiftUI can present some impediments for a development team - you may well encounter some of these issues:
Trusting the declarative nature of SwiftUI Developers accustomed to coding changes to an interface as functions often try to continue that practice when using SwiftUI. This leads to ugly, inelegant code. They need to learn a declarative mindset.
Understanding the specialised syntax The Swift language has been extended carefully to enable the reactive nature of SwiftUI views. Understanding and applying that extended syntax is a vital skill for a SwiftUI developer.
Replacing over-large view controllers with over-large views One common experience of new SwiftUI users is that their views get very big. Learning how and when to use subviews and modifiers are crucial to using SwiftUI.
Choosing an appropriate architecture Some development teams had already adopted MVVM rather than MVC as a paradigm for their app building. That move is exacerbated by the reactive nature of SwiftUI and the way it uses state in views.
Debugging The error messages are still not as clear as they might be, but there are coping mechanisms that can help you deal with any problems you find.
Dive into SwiftUI feet first?
If your team is hesitant about moving to SwiftUI, the changeover does not all need to be done in one jump. It is possible to mix and match UIKit and SwiftUI - either with SwiftUI screens within a UIKit app or vice versa. So your first step into SwiftUI might be to add a new feature to your app via a screen implemented in SwiftUI.
For myself, having built some apps in SwiftUI, any new apps I build will certainly be in SwiftUI, and it will look better, be more maintainable and work better cross-platform.