Implementing SwiftUI at scale

At last month’s Swiftable event, one talk that caught my attention was one by Alexis Santos, tech lead at Bumble. He spoke about how they migrated the app’s UI from UIKit to completely using SwiftUI and how they implemented it at scale.

Alexis mentioned the philosophy behind Bumble is to try to use the latest technologies and frameworks when available. Also, in their research about how mature the framework was and what problems it came to solve, they were able to draw certain conclusions. It seems the sweet-spot of SwiftUI is version 2.0 that came with iOS 14 (or at least using 13.1), which fixes some bugs and includes features like @StateObject among others.

The future is declarative

In computer science, declarative programming is a programming paradigm — a style of building the structure and elements of computer programs — that expresses the logic of a computation without describing its control flow.

– Wikipedia

SwiftUI uses a programming paradigm known as declarative programming. Unlike imperative programming, declarative programming allows us to tell our applications what to do and what they should look like in different states, and move between those states by itself.

(Source)

With SwiftUI, we don’t have to worry about how our app will transition between all these different states. We just need to write the code to describe how each state should look like, and the system takes care of the rest.

This solves the problem of animating updates based on state changes. Our State is the only one responsible for updating our Views. In turn, Actions are the only ones responsible for updating our State.

So what are the limitations of SwiftUI?

Despite these advantages, there remain some limitations. SwiftUI lacks backwards compatibility. Since it is not backwards compatible with previous versions of iOS, developers must choose between supporting older devices or using SwiftUI. This can be a significant limitation for developers who need to support a variety of devices or want to use the latest features of SwiftUI.

Another limitation is its API coverage. Some features and functionality are not yet available in SwiftUI, so developers are forced to use workarounds or implement UIKit under the hood.

Conclusion

There remains a range of opinions in the industry- some say it’s ready for production, some that it’s not. Personally, I think it’s a really promising framework that works as an efficient clean solution for many scenarios that do not require excessive complexity.

We’re looking forward to seeing how the framework evolves over time and what new features it will incorporate in the future.