Shared Architecture Across Several Mobile Apps
If your company builds several apps, they will all start with different architecture. Different teams will be building each of the apps, moving fast in the early days. However, the idea of having a more “unified” architecture will come up, over time. The sooner there are mobile platform teams owning shared components such as experimentation, feature flags, performance, and others, the sooner this idea is likely to surface.
While a unified architecture will no doubt have clear benefits at this point, it will mean a lot of work such as possibly rewriting a good part of the app. This is a classic paradox: in order to prove the benefits of a shared architecture, we need to be on a shared architecture.
A sensible middle ground is to start making steps towards a unified architecture, but without a rewrite. Here are the benefits in unifying the architecture between the iOS and Android apps:
- Shared language. Can we start to “unify” how iOS and Android talks about architecture as a first step? Can we agree on how to name concepts such as screens, navigations, modals, flows?
- Shared planning. Can we start to do formal, but lightweight planning with design documents? Can we plan the same feature for iOS and Android in the same document?
- **Breaking down silos//. Are mobile teams in the organization talking to each other, even when working on different apps? If not, how can they start to have conversations? For example, could we start cross-team planning reviews or other collaboration?
- **One shared component at a time//. What is a good candidate in terms of functionality or library that can be shared across apps? If this is built in-house, can it start to use a more “unified” architecture approach between iOS and Android?
- Introduce new architecture concepts in new parts of the app. Who said you need to rewrite the app for a new architecture? Can you not start to build new screens with a new approach? This is similar to taking a pragmatic approach to moving languages. For example, when introducing Swift in an Objective C codebase, without rewriting the existing code.
Migrating to a new mobile architecture is expensive. After weighing the cost versus the upside, most teams will decide against going all-in on a new architecture, and they are usually right to do so. The only time I recommend a rewrite is when major changes are to be made for the app, when much of the codebase needs to be touched. Even then, rewrites will usually take longer, and will be more painful than you originally budget for.
The behind-the-scenes story of Uber’s rewrite to Swift and the pain points along the way, has had a fair bit of discussion online. This was my first project at Uber, and also the largest rewrite I have been part of. The rewrite made sense, as the UX changes were cross-cutting and impacted almost all workflows and app parts. Still, if it was not for the major design and UX change, I am not convinced Uber would have done the rewrite and architecture change.
While Uber rewrote the Rider app using RIBs in 2016 and later did a full rewrite with the Driver App in 2018, the Eats app still remains on the “existing” architecture. During my time, there wasn’t a strong enough business case to justify stopping work and making under-the-hood-changes that don’t impact the user experience, and I agreed with this assessment. Following a pragmatic approach, many of the new components were being built with RIBs. A RIBs adapter was also built, so components using RIBs can be shared across multiple Uber apps, regardless of what architecture they are on.
You are reading an early draft from the book Building Mobile Apps at Scale. For the final, expanded and improved content, grab the book now - it's free to download as a PDF until 31 May.
Building Mobile Apps at Scale
"An essential read for anyone working with mobile apps. Not just for mobile engineers - but also on the backend or web teams. The book is full of insights coming from someone who has done engineering at scale."
- Ruj Sabya, formerly Sr Engineering Manager @ Flipkart