On iOS applications, architecture
A short opinion piece
I’ve seen countless tweets and stories lately about iOS app architecture. I’ve been a massive fan of trying new architecture on iOS. In the past, I have worked with Redux / TCA-like architecture because I believe unidirectional data flow is the only way to have a good & robust codebase.
Glose on iOS is built using Redux (so we can share architecture decisions between the frontend, iOS & Android clients), and I’ve made various open source applications like MovieSwiftUI using a Redux like (& lite) architecture for SwiftUI:
But with my recent SwiftUI work on the Medium app and some other open source projects, I’ve come to some realizations:
- SwiftUI allows you to make a very powerful self-contained system with a minimal amount of code.
- SwiftUI offers a very clean data flow; it’s built in & simple to understand.
- I don’t want to add a boilerplate above SwiftUI anymore because it’s tedious and, most of the time, unnecessary. And it creates superfluous friction when onboarding new engineers on the team.
- I can achieve very clean, testable, and maintainable architecture with clean & barebone MVVM.
SwiftUI allows far simpler architecture because you can write very little code to achieve a good result.
So, the next time you start a SwiftUI application, ask yourself which architecture you should use. Try a simple MVVM architecture, make small views, small view model, everything private, and use State, Published, Observed, and Observable objects. If you need something available to your whole app, make an EnvironmentObject and inject it at the app level. These are just a few examples.
Did you see the excellent data flow documentation from Apple?
Here are the three absolute best WWDC videos you need to watch about the SwiftUI data flow and underlying mechanisms:
Once you’re done with those videos, you’ll have this 💡above your head.
