On iOS applications architecture
A short opinion piece
--
I’ve seen countless tweets and stories lately about iOS app architecture. I’ve been a huge fan of trying new architecture on iOS, and 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 decision between the frontend, iOS & Android clients), and I’ve built 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 realisations:
- SwiftUI allow you to make very powerful self-contained system with very little amount of code.
- SwiftUI offer a very clean data flow, it’s built in & simple to understand.
- I don’t really want to add boilerplate above SwiftUI anymore because it’s tedious and most of the time uncessary. And it creates unnecessary friction when onboarding new engineers on the team.
- I can achieve very clean architecture, both testable and maintenable with clean & barebone MVVM.
SwiftUI allow far simpler architecture because you can write very litle code to achieve a very good result.
So the next time you start a SwiftUI application and ask yourself which architecture you should use? Try a simple MVVM architecture, make small views, small view model, everything private, use State, Published, Observed and Observable object. If you need something available to your whole app, make an EnvironmentObject and inject it at the app level. This is just a few examples
Did you saw the great data flow documentation from Apple?
Here is the 3 absolute best WWDC videos you need to watch about the SwiftUI data flow and underlying mechanisms:
Believe me, once you’re done with those videos, you’ll literally have this 💡above your head.
