I’m a bit of a Facebook skeptic, but it’s really amazing that they had the guts to actually completely rewrite their Messenger app for iOS. That is such a gigantic effort that it basically doesn’t ever happen with popular apps at big companies. So kudos to Facebook for actually making that happen. 👉 Yay, Facebook! 🤷🏻♂️
This post explains some of the design and architecture decisions they made. It’s interesting that Facebook, the company that invented the cross-platform React Native framework, went full native when rewriting their own app. In fact, one of their key principals in the rewrite was “Use the OS”.
While UI frameworks can be powerful and increase developer productivity, they require constant upkeep and maintenance to keep up with the ever-changing mobile OS landscape. Rather than reinventing the wheel, we used the UI framework available on the device’s native OS to support a wider variety of application feature needs.
They also use SQLite to create a sort of table-driven local business logic layer a custom platform “to orchestrate all access to the database, including queued changes, deferred or retriable tasks, and for data sync support.”
This is an example that all of us mobile engineers can take to our managers and demand a rewrite now! (Kidding / not kidding 🤓)
Another counterpoint in the iOS architecture wars, saying basically that MVC is actually pretty sound as long as you use it wisely.
This post breaks controllers down into a few types: Containers, Generic controllers, View controllers, Flow controllers to help reframe things.
One of my favorite points here is that not everything has to be a model, a view, or a controller. You can — and should — create other kinds of code! No wonder your controllers are messy if you limit yourself like that. 🤷🏻♂️
This issue happens when the developer thinks they must fit everything into either M, V or C, forgetting that they are allowed to create other types of constructs.
An app view that changes its state in complicated ways is difficult to do right. We developers have even been trying to avoid state when possible. But if you really just have to deal with a complex state-driven app view, then embrace it with a state machine.
This is great! This is what I’ve been wanting to do for comparison… They make a sample iOS app in five different architectures, including MVC, MVVM, RxSwift, View State-Driven MVC and Elm Architecture.