UI architectures are like fashion. They go in and out of style, and they can bring fresh perspectives, but they aren’t as important as you might think.
“Our codebase should use RxSwift. Reactive programming is going to be the future!”
If I had €1 every time someone said this to me in the past, I could almost afford an Apple USB-C charging cable.
Not that long ago, reactive programming — such as RxSwift — became the next big thing. “Obviously”, reactive programming would solve all of our problems.
Job listings starting to require reactive knowledge. There was hype around it. And at my work — being a platform member at ING at the time with a considerably sized codebase and team — I received monthly proposals to introduce a new pattern to the codebase, whether that was RxSwift, MVVP, MVVM, or whatever the next big thing was during that time.
Our team often had to disappoint people because we couldn’t adopt everything on a whim. And our work was proof that simple viewmodels with some coordinators were more than enough for most, if not all, our features.
That didn’t mean we said no all the time to any trend. Some of these trends came with — in my eyes — great ideas, such as coordinators. Experimentation was an important part to figure out what would work for us as a team.
But the art was the ability to judge whether an architecture solves an actual problem or if it’s just trendy. On top of that, people want to grow and learn from adopting new technologies and ideas, and there needs to be space for that, too.
Most UI architectures are valid and do a great job, yet they’re often based on preferences.
Some people want a more functional style, others prefer a more reactive style over imperative, others prefer routers over coordinators, and so on. They all have their pros and cons.
There is a myriad of patterns and architectures out there to choose from; MVC, MVVM, MVVMP, TCA, SwiftUI, UIKit, Kotlin Multiplatform, Jetpack Compose, hybrid, imperative, reactive, declarative, or a mobile clone of the Elm architecture, you name it.
Unfortunately, it isn’t possible to please everyone. Setting aside your own preferences, it’s healthy to view them as alignment tools that come and go in different flavors.
Instead of worrying which architecture to pick, try to move forward with the simplest solution possible. Consider adopting a fancy architecture only when a simple solution doesn’t suffice.
Keep in mind that you don’t have to follow the latest trends. SwiftUI is popular today, but I don’t see UIKit leaving soon, either. In contrast, I wouldn’t value “5 reasons SwiftUI isn’t production ready” pop articles, because people are making great apps with it. Try to use what works for you and your team, long term it doesn’t matter too much. It’s more important your team is aligned.
Maybe your team might feel the need to implement a new architecture, especially if you’re experiencing problems, such as having to write UI Tests to test business logic. But in that case, I’m willing to bet that the "wrong” UI architecture isn’t the source of these problems.
Maybe the problem you’re dealing with is unrelated to UI architectures at all; Such as missing documentation, missing proper examples, lack of training, a bad onboarding experience, disagreements not being resolved, a poor code-review culture, or multiple issues combined.
Your team may come up with rules such as “A viewmodel may never have a import UI statement”. But that import UI is only a single pull request away once a team member wants to decorate some strings. Which uncovers an alignment or code-review problem, and less a “we need a new UI architecture”-problem.
Chances are, the UI architecture you picked is fine for the foreseeable future. Note that plenty of apps in production today are powered by good old Objective-C and Java.
Despite sticking to fewer architectures, it can motivate people to try out new technologies or architectures.
But instead of overhauling an entire codebase — such as replacing all UIViewControllers with SwiftUI views or XML views with Jetpack Compose “because it’s new” — try starting with an experiment.
Grab a smallish feature, and build it using a different technology, and relay the lessons back to the team. Now your team has controlled experiments and everyone can learn from the experience.
Nowadays, I think it’s safe to say that RxSwift had to make way for Combine and SwiftUI, thanks to first party solutions. And some might say that Combine is losing part of its share to Async/Await.
The discussions about MVC vs MVVM turned into discussions about UIKit vs SwiftUI or XML vs Jetpack Compose, and whether a View is a viewmodel or not.
And there will always be the next best thing for developers to squabble about.
It’s already a challenge to get a large team to align on one way of working, and sticking to a few select architectures can help create some sense of predictability to a codebase. This helps, because once a coworker swaps teams, or a new person joins and reads docs, they already have a general idea of where to find things and how things work.
The Mobile System Design book
If you want to boost your career and become an even better mobile engineer, then check out the Mobile System Design book.
I am the author of this book, but you may also know me from the highly-rated Swift in Depth book.
Even if you're a senior or staff-level engineer, I am confident you'll get a lot out of it.
It covers topics in depth such as:
... and much more!
Get the Mobile System Design bookWritten by
Tjeerd in 't Veen has a background in product development inside startups, agencies, and enterprises. His roles included being a staff engineer at Twitter 1.0 and iOS Tech Lead at ING Bank.
He is the author of the Mobile System Design and Swift in Depth books.
