SwiftUI vs. Auto Layout: Pros and Cons of Each Approach

Join the new SwiftUI language or keep using the affordable Storyboards system?

Ivano Di Gese
Aug 18, 2019 · 6 min read
Image for post
Image for post
Photo by Yura Fresh on Unsplash

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.

Image for post
Image for post

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.

Declarative interfaces are popular in hybrid apps as almost all of them are developed using Flutter and Ionic.

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

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.

Simple interfaces can be coded in zero to little time due to basic components that automatically integrate basic constraints and behaviors.

SwiftUI is basically conceived to design a single view.

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.

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.

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.

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.

Advice for programmers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store