The Advantages of SwiftUI

Almost a year ago Apple introduced SwiftUI at WWDC 2019. It’s still a very young technology but it’s quite clear that it’s the future not only of iOS development, but of macOS, watchOS, and tvOS development as well. What are the advantages of using SwiftUI?

Development is faster

Let’s face it: time matters. We love our craft but we also want to be fast in order to satisfy customer demands and to be more productive. One essential part of SwiftUI is preview. It enables you to see the graphical result of your UI code at development time.

To a certain degree that holds true for developing with UIKit by using the interface builder as well. However, with SwiftUI you can define test data for preview. Consider a tableview: you don’t see just a single prototype cell, but the whole table view with realistic data. Additionally, you can see different screen sizes at the same time. Also other states as localisation and dark mode can be observed.

You can also use live preview. After starting it, you can interact with your UI. It’s like using the simulator with the big difference that you don’t have to recompile after applying changes.

This safes a lot of build time. When projects becomes huge, long build times can decrease productivity massively.

Development is less error prone

There is one thing though, that’s even more important than time: quality. The complexity of building an UI with a lot of interaction possibilities is huge. Handling all these different states (i.e. logged in / not logged in) is very difficult and can be compared to handling multithreading code.

With SwiftUI, this complexity decreases dramatically. UIKit is imperative programming, whereas SwiftUI is declarative programming. So what’s the difference? As the names imply, by using an imperative approach, you tell the framework what should happen and also how. On the other hand, by using a declarative approach, you just describe the desired result.

An example: Imagine a screen with a login form. When the users has successfully logged in, you update the UI in the network callback according to the ‘logged in’  state. For example, you change the text of the button (‘log in’ -> ‘log out’), display the user’s name and show other menu options. When the user ever gets logged out, it’s your responsibility to react and change the UI state. On the other hand, if you are using a declarative approach, you just describe the whole UI dependent on the login state. If the variable with the login state ever changes, the UI will be updated automatically without any manual action.

And that’s just one state. The screen can have many others states and depending on the order of the user actions there can be unpredictable outcomes. Of course there are also good practices to handle this with an imperative approach. However, SwiftUI makes it automatically and easy.

Swift UI is exciting

For me as a long term iOS developer, it’s very exciting to use a completely new technolgy for developing apps. And it’s not like using a different framework. It’s a different approach of programming. As explained in the last paragraph, switching from imperative to declarative programming is a huge deal. 

For us developers technology is not just a tool for creating an app. Instead, the technology as such matters. And learning a new technology is like unboxing the shiny new iPhone. 

SwiftUI is the future anyway

In my opinion, the previous reasons are sufficient to justify the switch to SwiftUI. But even if you are not convinced yet that developing with SwiftUI is faster and less error prone, it’s still necessary for every iOS developer to learn SwiftUI.

Apple is pushing SwiftUI heavily and the developer community is also impressed by SwiftUI. So SwiftUI will go the same way as Swift did: Yes, Objective-C is still a great programming language and alive, but Swift is THE language for iOS development. And the same will happen to SwiftUI as well. 

The doesn’t mean that you don’t need UIKit anymore! There are millions of apps in the App Store using UIKit and it doesn’t make sense to migrate existing code to SwiftUI. And sometimes it’s not even possible because the deployment target is lower than iOS 13.

Also, there are UIKit features, that are not yet available for SwiftUI, like collection views.

So if you wanna be a serious iOS developer, you have to be both an UIKit and SwiftUI expert.

References 

Title image: @  Vadym Sh / Shutterstock.com