SwiftUI vs. Auto Layout: Pros and Cons of Each Approach
Join the new SwiftUI language or keep using the affordable Storyboards system?
I still remember when Apple released the Swift language, a real breakthrough and a step beyond modern programming languages. It made developers very excited.
It’s been five years from its release date (September 2014) and Apple kept upgrading the language up to Swift 5, sometimes providing good features, sometimes just updating the Xcode IDE and Storyboards improvements.
Then, the SwiftUI language was presented at WWDC 2019 in June and it started becoming popular soon after. To me, it looks like everybody loves SwiftUI.
The SwiftUI language/technology is a new way to approach and design user interfaces for iOS app and it’s basically a brand new system which will probably replace the Auto Layout system.
Auto Layout was visual, while SwiftUI is declarative and provides developers with the ability of coding a UI, rather than composing it visually.
There are many differences between the two, and even if we don’t have an expiration date for the legacy Auto Layout support, speculations and rumors whisper that SwiftUI will be the future of the UI/UX developing tools in iOS programming.
Auto Layout: From Scratch to Frameworks
The Auto Layout system was conceived by Apple in 2011 and as released to developers and supported in iOS a bit later.
Auto Layout bases its features on a system that is capable of adapting its rendering and appearance using constraints and rules defined by developers.
These rules specify whether or not views should appear larger, should shrink, should shift position coordinates, and more, making all UI components responsive and capable of adapting to screen sizes, resolutions, and different contexts.
Auto Layout started becoming important when Apple introduced iPhones with different screen sizes — the first case was with iPhone 5, which showed a longer screen than before.
Today, with standard iPhones, Plus iPhones, the X model, and so on, all Auto Layout implementations are something you can’t avoid, they are simply mandatory and as soon as you create a new Xcode project, Auto Layout support is simply built-it and ready to go.
Auto Layout is not patented by Apple and is not unique as a UI system. It’s simply the Apple way to create interfaces and manage their responsiveness — if you take a look at Microsoft tools to build Windows interfaces in .NET they’re quite similar.
During these years, we’ve experienced a challenging complexity of UI compositions and Auto Layout, despite its simplicity, has evolved a lot and sometimes requires good skills and integration of frameworks to make them work.
In some cases, I’ve experienced the need for coding interfaces using Swift rather than Xcode or Storyboards because of their conditional and context-dependent aspect behavior.
I’ve been forced many times to set up constraints and rules in Swift rather than visually and I struggled with native Apple support for it.
That’s why I used Snapkit in most cases to support my UI coding and I really think is a great tool, simple and effective. There are many other tools and frameworks to support Auto Layout features and probably 90% of modern iOS apps need them to build complex UIs.
I still remember the early apps on iPhone 3G and they all looked the same. But come on… today every popular app looks good and has complex UI behaviors, often using parallax, Lottie animations, relative positioning, gradients, and more.
SwiftUI: The New, Good, and Bad
The new SwiftUI has been conceived to reorder ideas on UI composition and developing.
If you look around, there are many frameworks, contexts, and technologies where the user interface is more “defined” than “composed”. Think about old XML based UI compositions, or even the HTML/CSS approach — it’s basically declarative more than composed by using visual tools.
Flutter uses declarative interfaces such as the old Sencha or the modern React native. In IONIC, the UI is pure HTML/CSS and it’s not much different.
My first impression of SwiftUI is that it could be useful and a good choice for simple interfaces, but a bit inappropriate for complex ones.
The idea of composing UIs by coding everything using a language like Swift but specific to UI compositions sounds a bit weird to me, even if assisted by drag and drop Xcode features.
Imagine having an interface like a social feed, a profile page like Facebook… are we sure it would be a pleasure to code it with SwiftUI? I’m not sure.
It would lead to nested coding blocks and declarations that look really bad and confusing, you have to admit it.
Yes, we have a simplified syntax and it’s not much different to what Xcode builds using Storyboards and writing XML, but it could be a bit reckless to start using SwiftUI while predicting the use of complex animations and UIs for my applications.
At all workshops I’ve been to, in every tutorial I’ve seen, in every demonstration I’ve read, SwiftUI interfaces was quite basic and I know modern apps require way more.
Pros and Cons of Auto Layout and SwiftUI
Auto Layout and Storyboards are well-supported and well-known by developers.
We used Auto Layout so much during the year and we know how to approach the problem.
SwiftUI uses the same approach theoretically (SwiftUI is basically a different way to set Auto Layout-like constraints, it’s not a separate tool or a separate technology), but it’s fresh, new, and sometimes this has a negative impact on the developers’ experience.
SwiftUI looks cool and looks fast to code
Simple interfaces can be coded in zero to little time due to basic components that automatically integrate basic constraints and behaviors.
Storyboards and segues give you an idea of what you’re doing
SwiftUI is basically conceived to design a single view.
Xcode Storyboards is supported by custom views extensions
Xcode Storyboards is supported by custom views extensions via @IBDesignable decorators, SwiftUI needs time to become supported and integrated by custom tools developed by the community.
SwiftUI is supported in iOS 13 only
This is probably the most influential negative aspect, because SwiftUI-based apps won’t be released in enterprise environments for at least one year.
Today, there’s no official announcement about how to eventually make it work on earlier iOS versions. This might not impact B2B apps, but definitively does in B2C and trending apps, regardless of iOS user’s habits on keeping the OS updated.
SwiftUI has real-time preview
Finally, we have a “responsive” way to code our views, something we really wanted in Storyboards and UIKit, where previews were low quality and sometimes not efficient when using custom views and dynamic content.
SwiftUI has simplified animations
Something we really missed in old systems, where you have to fight with
UIView.animate() and more. The new easing and animation system looks way better.
SwiftUI is for sure the step to take if you want to follow Apple’s modern interpretation of UI developing, but it’s an all-new and unexplored path which could lead to unattended behaviors and make your expectations wrong.
If you still need something which will not affect your timing provisioning for a new release or a new project your customer is waiting for, I’d suggest continuing to use Storyboards or Auto Layout.
If you want to approach this new, fascinating technology and you have time to spend to study and experiment, go for SwiftUI.