The end of Story Board? Welcome, SwiftUI!
When Apple introduced the new Swift language, it was a real breakthrough and a step beyond modern programming languages for the developers which excited them. It has been five years since the introduction (September 2014) while Apple has been upgrading the language to Swift 5 by providing good features like updates on Xcode IDE and other advancements in Storyboards. The SwiftUI language became popular soon after it was presented at WWDC in June 2019.
SwiftUI is a new way to approach and design user interfaces for iOS apps making it a brand new system to replace the conventional Auto Layout system. Keeping in mind that Auto Layout is perceptible, SwiftUI is declarative which provides developers with the ability of coding for UI, rather than visually generating it.
There are several differences between Story Board and SwiftUI and even if we do not have an expiration date for the legacy Auto Layout support, there are speculations and rumors that SwiftUI will be the future of UI/UX developing tools in iOS programming.
The Era of Auto Layout
The Auto Layout system was devised by Apple in 2011 and it was released for developers with support in iOS later.
Auto Layout sets its features on a system that is capable of adapting its rendering and appearance using constraints and rules defined by developers. These rules will specify whether or not views should appear larger, should shrink, should shift position coordinates and more thus by making all UI components responsive and capable of adapting to screen sizes, resolutions and different contexts.
Auto Layout became significant when Apple introduced iPhones with different screen sizes varying from 5.6 to 6.5 inches whereas the Auto Layout implementations are unavoidable. Auto Layout is neither patented by Apple nor unique as a UI system. It is simply the Apple way to create interfaces and to manage their responsiveness.
During these years, we’ve experienced a challenging complexity of UI compositions and Auto Layout, despite its simplicity. It has undergone several evolutions which requires good skills and integration of frameworks to make them work.
Sometimes, the need for coding interfaces using SwiftUI arises because of their conditional and context-dependent aspect behavior rather than using Xcode or Storyboards.
There are a number of other tools and frameworks to support Auto Layout features and probably 90% of modern iOS apps need them to build complex UIs.
SwiftUI: A plus for simple interface, a minus for complex designs
The new SwiftUI has been formulated to reorder ideas on UI composition and development.
If you look around, there are many frameworks, contexts, and technologies which make the user interface more “defined” in nature than “composed”. Declarative interfaces are popular in hybrid apps as most of them are developed using Flutter and Ionic.
Flutter uses declarative interfaces such as the old Sencha or modern React native whereas in IONIC, the UI is pure HTML/CSS and it is not much different.
SwiftUI is recommended as a good choice which is useful for simple interfaces however, it might be undesirable for complex designs.
Imagine having an interface like a social feed, a profile page like Facebook. Are we sure that it is satisfying to code using SwiftUI? We are not. It would lead to nested coding blocks and declarations that will look unpleasant and confusing. It has a simplified syntax and it is not unique to what Xcode builds using Storyboards. Writing XML could be a bit reckless to start using SwiftUI while predicting the use of complex animations and UIs for my applications.
Auto Layout Vs SwiftUI: Pros and Cons
Auto Layout is user-friendly while SwiftUI might leave a negative impact: Auto Layout is being used all these years which are well known for approaching any problem. SwiftUI uses a similar approach theoretically (SwiftUI is basically a different way to set Auto Layout-like constraints, it is not a separate tool or a separate technology) It is radical, recent and has a negative impact on the developers’ experience occasionally.
SwiftUI looks cool and fast to code for simple interfaces: Simple interfaces can be coded in very minimalistic time due to basic components that automatically integrate basic constraints and behaviors.
Storyboards and Segues enable us to see the flow, SwiftUI allows a single view: Storyboards and Segues enable us to view the UI and navigation flow while SwiftUI is basically designed for a single view.
Xcode Storyboards are supported by custom views extension, SwiftUI will evolve in the future: Xcode Storyboards are supported by custom views extension via @IBDesignable decorators whereas SwiftUI needs time to adapt and integrate by custom tools developed by the community.
SwiftUI is supported by iOS 13 only: This is probably the biggest negative impact as SwiftUI-based apps will not be released in enterprise environments for at least a year.
There is no official announcement on the ways to make this language work in earlier iOS versions till date. This might not impact B2B apps but it will definitely affect B2C and trending apps, regardless of iOS user’s habits on keeping the OS updated.
SwiftUI has real-time preview: Finally, we have a “reactive” way to code our views something we really want in Storyboards and UIKit where previews will be of low quality and sometimes not efficient enough while using custom views and dynamic content.
SwiftUI has simplified animations: There was a need to fight with UIView.animate() and many more in the old systems whereas in SwiftUI, the new easing and animation system looks much better than the predecessor.
What’s the best with respect to time and need? (Conclusion)
SwiftUI is undoubtedly the step to venture if we want to follow Apple’s modern interpretation of UI development but it is an all-new and unconventional path which could lead to unattended behaviors and prove expectations wrong.
If we still need something which will not affect time, say for the introduction of other languages or if a new project customer is waiting, the best option is to continue using Storyboards or Auto Layout.
Parallelly, if the approach is likely for a new fascinating technology followed by an ample amount of time to explore and experiment, SwiftUI could be opted for.
Are you looking to build a great product or service? Do you foresee technical challenges? If you answered yes to the above questions, then you must talk to us. We are a world-class Custom dot net development company. We take up projects that are in our area of expertise. We know what we are good at and more importantly what we are not. We carefully choose projects where we strongly believe that we can add value. And not just in engineering but also in terms of how well we understand the domain. Book a free consultation with us today. Let’s work together.