Exploring SwiftUI — A Broad Overview 3/4: Architectures in SwiftUI
This article is the 3rd of a series of 4 aimed at exploring the capabilities of SwiftUI. Happy reading!
Intro
As SwiftUI is becoming the framework of choice for building user interfaces for iOS apps, developers are tasked to rethink the architectures they use in order to leverage SwiftUI’s capabilities. But sometimes it can be hard to transition from e.g. a one-way-data-flow type of architecture to a two-way-data-flow using states and observers. And with a handful of available architectures to chose from, developers must carefully consider all factors before making the decision.
Next, let’s have a look on some of the most popular architectures that fit well with SwiftUI. Disclaimer: this list is not exhaustive.
MVVM
Acronym for Model-View-ViewModel, MVVM is one of the most popular architectures for building iOS apps. In this pattern, the ViewModel acts as a bridge between the View and the Model, responds to changes happening in the view and updates the Model. MVVM facilitates separation of concerns and testability, but can also promote a reactive approach based on states and events. When using SwiftUI, the ViewModel becomes an ObservableObject that will be observed by the View, which will update itself based on the emitted changes.
Let’s see it in action:
Some developers may argue that using MVVM with SwiftUI is over-engineering, and that there’s no benefit of introducing another component because the View itself is a ViewModel. I think it’s better to weight in more arguments such as coupling or testability before making a decision.
Full code is available on my Github.
VIPER
Acronym for View-Interactor-Presenter-Entity-Router, VIPER is a newer software architecture aimed to solve problems related to segregation of concerns that other architectures have, by introducting specific single-responsibility components. In short, in a VIPER architecture the View communicates with the Presenter, which in turn asks the Interactor for data in the form of Entities. When the business is done, the Presenter asks the Router to navigate to another VIPER component. In order to have VIPER working with SwiftUI and not breaking the VIPER concepts, a few changes need to be applied to the pattern.
Here’s an example:
It’s true that VIPER introduces a lot of boilerplate, and some even say this architecture is not suited for SwiftUI’s declarative approach.
Full code is available on my Github.
TCA
Acronym for The Composable Architecture, TCA is a fairly new architecture that grew a lot of traction recently (at the time of writing, it has 8.5k stars on Github). It came as a solution for the issues that some other architectures had, and addresses the state management, testability or composition, allowing to break down large features(or screens) into smaller independent components while providing many useful tools. TCA is based on State and Actions — which are self explanatory, a Reducer which dictates how the state is modified based on each performed action, and a Store that manages all this logic.
This is how it works:
TCA framework is similar to Redux — a React library, and is close to a State Machine — a model that changes states based on inputs or actions.
Full code is available on my Github.
Conclusion
While there is no such thing as a “correct” architecture to choose for a SwiftUI project, choosing the closest to that can be tricky and depends on various factors such as the complexity of the app, the developers’ experience and the project’s requirements. Every architecture has pros and cons that need to be considered before making the decision. Ultimately, the decision depends on the project’s specific needs and the team’s experience.
Thank you for reading! Got a suggestion? Please leave it in the comments section, feedback is always appreciated!
Let’s connect on LinkedIn!
If you’re interested in learning more about Xapo Bank — Bitcoin Bank providing simple and safe usability to retail customers, explore the resources at xapobank.com.
