The following article uses Apple’s sample project which can be downloaded here.
Up until 2019 all of Apple’s development platforms had only one native UI Framework: UIKit. Although this framework is great at many things, such as building UIs through visual interaction, it also has major drawbacks.
First of all, it’s a pain to use for building interfaces through code. Its syntax lacks the structure and visual hierarchy of markup languages such as XML or HTML, which can make building complex layouts a bit messy. Moreover, it doesn’t provide you a preview of the layout you are building, so you are required to run the entire app in order to see your layout. Secondly, layouts that are created visually through the interface builder are usually a hassle to alter through code due to their limited accessibility.
Fortunately, Apple has released SwiftUI, a new framework that puts these problems to rest while making interface building, in general, quite a bit easier. It brings many improvements over UIKit, namely, a new declarative markup language, hybrid visual/programmatic interface building, and live previews. Not to mention, it also significantly reduces code! In this article, we are going to explore SwiftUI and see it in action!
With Xcode’s new preview feature, engineers will be able to build the interface by both coding and visually interacting with SwiftUI, instead of using visual Storyboards. SwiftUI is a markup language so its syntax has a structure and hierarchy that helps create complex layouts. Interface building through code is represented in the preview window to the right, as shown in Figure 1. Any subviews created visually through the preview window will also show up as code.
The preview window refreshes automatically whenever the code is altered. Furthermore, each preview window features a “Live Preview” option which, when enabled, will act as a simulator. This greatly reduces the need for using the Xcode simulator to test views.
You can add new subviews without manually writing the corresponding code. Clicking on subviews presents options for embedding them in other views, which will generate the corresponding code automatically. You can do this by clicking on the subview’s code or the corresponding subview in the preview window, as shown in Figures 2 and 3. This new way of interface building combines the best of both worlds: visuals and programming without sacrificing the convenience of either.
SwiftUI introduces a fundamental UI programming change to all Apple platforms (iOS, macOS, tvOS and watchOS). Traditionally, UIs were built with UIKit, which consists of imperative programming: a paradigm based on making statements that change the application’s state. However, SwiftUI shifts the paradigm to declarative programming, which is based on expressing the logic of the application without describing its control flow. Put simply, UIKit imperative programming consists of giving explicit commands to change the state of the UI, while SwiftUI’s declarative programming consists of describing how you want the UI to behave, letting it do that on its own.
For example, when building a simple list of items with UIKit, the programmer needs to specify the number of rows the list should have. If the content changes, the programmer would need to programmatically refresh the list to keep it up-to-date. With SwiftUI the list will keep its content up-to-date and show the corresponding number of rows automatically. The programmer only needs to declare what he wants and let the framework take care of the control flow. This is because SwiftUI works with states. Any property can be managed as a state by declaring them with a @State prefix. This way, when the property’s value changes, the view will automatically proceed to reconstruct itself and keep its content up to date. This provides a simpler way to manage view data.
The declarative nature of SwiftUI can save developers a lot of time compared to UIKit, as it takes significantly less code to implement the UI. Let’s take creating lists as an example, where UIKit requires many steps. With the old framework, developers need to visually design the layout through a Storyboard, as shown in Figure 4, and then implement its complementary code, as shown in Figure 5.
This includes creating a custom subclass of UITableViewCell and implementing the custom subviews each item requires. Then, they need to implement the UITableViewDelegate and UITableViewDataSource protocols, assign the corresponding delegates and implement the numberOfRowsInSection and cellForRowAt methods to define the number of rows the list should have and build the list of items.
Furthermore, as mentioned before, the list has to be manually refreshed with reloadData in order to keep its content up to date. This can be quite a hassle in comparison to SwiftUI, which enables developers to create a List object that defines the properties each item should have. The rest is taken care of automatically. This is achieved with very few lines of code, as shown in Figure 6.
I have explored some of the advantages of using SwiftUI compared to the traditional way of building user interfaces. Hopefully, you now have a better idea of what this framework is about and how it could help you. The shift to a declarative programming paradigm will not only save you time but also reduce the number of parameters you need to control.
Additionally, the new visual/programmatic hybrid interface builder, markup language and live preview feature further help this framework provide an enhanced experience over its UIKit counterpart.
That being said, because SwiftUI is so new, it’s adoption has been limited and it lacks the extensive support UIKit has. It‘s worth mentioning that this new framework isn’t meant to completely replace and bury UIKit. As a matter of fact, it can work together with UIKit by including some of its features, which is necessary at times, since SwiftUI lacks certain controls. Therefore it’s important to be well versed in UIKit as well.
· Apple Inc. (2019) SwiftUI.
· Apple Inc. (2019) SwiftUI Tutorials.
· Apple Inc. (2019) SwiftUI Essentials: Creating and Combining Views.
· Ian Mundy (2017) Codeburst. Declarative vs Imperative Programming.
July 08 / 2020
April 23 / 2020
As we gradually get used to our new COVID-19 reality, daily life from just a few weeks ago now feels like a lifetime away. For businesses this has created,...Read post