Mobile architecture
How to review a mobile architecture proposal
A practical review framework for mobile architecture decisions: constraints, reversibility, ownership, migration and production proof.
By Mike Salari. Staff mobile engineer · 500+ technical interviews from the hiring side.
4 min read
Start with the decision
A mobile architecture proposal often arrives as a diagram, a folder structure or a list of patterns. That is usually too late in the conversation. Before reviewing the design, name the decision.
Are we choosing a persistence model, a navigation approach, a modularisation boundary, a networking layer, a sync strategy, a design-system ownership model, or a migration path? Each decision has different risks.
If nobody can state the decision in one sentence, the review will drift. People will comment on taste, pattern preference and diagram aesthetics instead of the tradeoff that matters.
Ask what constraint is doing the work
Architecture is constraint management. A proposal should say what constraint is forcing the design. Team scale, offline behaviour, build time, release risk, performance, security, testability, platform consistency and migration cost are all valid constraints. They are not interchangeable.
If the constraint is team scale, the review should focus on ownership boundaries and dependency direction. If the constraint is offline behaviour, the review should focus on source of truth, conflict policy and durable operations. If the constraint is performance, the review should focus on measurement and hot paths.
A proposal without constraints is just preference with formatting.
Reversibility changes the standard
Some decisions are easy to reverse. A small view model boundary, a local helper, a feature-level folder structure. Other decisions become load-bearing: database schema, module graph, navigation framework, sync engine, design system primitives.
The review standard should change based on reversibility. For reversible choices, optimise for learning and speed. For hard-to-reverse choices, demand more evidence, a migration plan, a rollback strategy and explicit ownership.
This prevents two common failures: over-reviewing small decisions and under-reviewing decisions that will define the app for years.
Mobile proposals need mobile questions
A mobile review should ask questions that backend templates miss. What happens after app restart? What state is persisted? What work survives backgrounding? How are migrations handled? What happens on low storage? Does this affect launch time? What runs on the main thread? Can this be rolled out by feature flag? What metrics will prove it works?
These are the operating environment, not edge cases. The app will be killed. The user will lose network. The schema will change. The release will reach old devices. The proposal should be honest about that world.
Ownership is part of the design
Many architecture proposals describe components but not owners. That is dangerous. A module without an owner becomes a shared dumping ground. A design system without governance becomes a pile of components. A sync engine without operational ownership becomes nobody's incident.
Ask who owns the decision after merge. Who reviews changes? Who handles migrations? Who watches metrics? Who decides when exceptions are allowed? Good architecture includes a maintenance agreement as well as code shape.
One draft, read as a reviewer
Here is a proposal in the shape I see most often:
Move inspection editing into a shared data module. Screens will read local data and a background worker will synchronize changes. This gives us a single source of truth and lets iOS and Android behave consistently. We will switch the feature over behind a flag.
The direction is plausible, and five terms are undefined. These are the comments I would leave:
| Proposal text | Review question | Evidence that closes it |
|---|---|---|
| Shared data module | Shared between which consumers, and who owns its contract? | Consumer map, dependency direction, a named owner |
| Read local data | What shows before the server accepts the change? | A state model: local, pending, accepted, conflicted |
| Background worker | What recovers after an interruption? | A durable-operation contract and restart tests |
| Behave consistently | Which behaviours must match across platforms? | Shared protocol cases plus platform checks |
| Behind a flag | Does it stop writes, change reads or hide the screen? | The control path and recovery instructions |
None of those needs a favourite pattern. Each exposes a contract that decides whether the design meets the requirement. Last, review how old and new coexist before the destination. Can both paths write the same local record? Can a user return to the old flow after a new write? A flag that only changes routing will not reverse a schema change.
The review output should be boring
A useful architecture review should end with a small set of clear outcomes: approved, rejected, needs more evidence, or approved with conditions. The conditions should be concrete: add migration tests, measure launch time, document conflict policy, split ownership, prototype the risky path.
The worst outcome is vague approval. Everybody nods, the implementation starts, and the unresolved risk silently becomes production cost.
Write the decision down. Future engineers should know why the system exists, what alternatives were rejected and what would make the team reconsider.
Give that last part a name and a number: a revisit trigger, the condition agreed in advance under which the team reopens the decision. A second platform adopting the module, conflict reports above an agreed rate, a build time past its budget. A decision record without one becomes a monument, and the next engineer tears it down just before it would have paid off.
I wrote a book around decisions like this one. Controlled Change has a chapter on decisions, ADRs and revisit triggers, another on architecture reviews that work, and a review rubric in the appendix.
