Career path
Design systems
Reason about mobile systems at architect altitude.
Offline-first sync, caching, modularisation, persistence, performance, platform strategy and architecture governance.
Senior, staff and architect-level mobile engineers responsible for systems that need to last.
Are you on this path?
Signs you are here
- You reach for a familiar architecture before you have the constraints.
- You can describe the happy path, but not the failure modes.
- Cross-team designs stall because the mobile constraints are not legible.
- You own systems that need to last, but lack a way to reason about them.
Mobile architecture starts with constraints.
This path is for engineers who need to reason about offline state, sync, performance, modularisation and platform boundaries with staff-level clarity.
- 1
Start with constraints before choosing patterns.
- 2
Map state ownership across app, cache, persistence and backend.
- 3
Name failure modes, rollout risks and observability points.
- 4
Turn decisions into RFCs other teams can understand.
Books for this path
Senior, staff and architect-level mobile engineers responsible for systems that need to last. Offline-first sync, caching, modularisation, persistence, performance, platform strategy and architecture governance. Every book here is written from the hiring side, from 500+ technical interviews, and each book page shows what is inside and who it is for.
Free resources
Free checklists, cards and templates for the design systems path. Each one is short enough to use on the problem you have this week, and each works on its own, before or without a book.
Writing for this path
Mobile system design
iOS system design interview: a worked answer from the hiring side
The round is scored on the decisions, not the diagram. A worked answer for an offline-capable messaging app on iOS, minute by minute, with the follow-ups interviewers use and how the Android answer differs.
11 min read
Mobile system design
Android system design interview: a worked answer from the hiring side
On Android the round is decided by one question: what does the green check promise when the process dies a second later? A worked answer for an offline field inspection app, minute by minute, with the follow-ups interviewers use.
12 min read
Mobile system design
Design Uber on iOS: a system design interview answer from the hiring side
"Design Uber" is scored on one question: what does the driver's pin mean when it is 21 seconds old? A worked iOS answer, minute by minute, with the follow-ups interviewers use.
10 min read
Mobile system design
Offline sync system design interview: what happens when two devices disagree
"Design offline sync for a notes app" is decided by one question: two devices edited the same thing while apart, and both synced. Which one wins, and who decided? A worked answer from the hiring side, for iOS and Android alike.
9 min read
SwiftUI
SwiftUI state management best practices, from production
Most SwiftUI state bugs come from ownership, not from wrappers: a value with two owners, a binding nobody needed, a store everything reads. The wrappers, the Observation framework and the environment, explained by who owns what.
12 min read
Mobile system design
Short video feed system design interview: a vertical video feed, from the hiring side
"Design a short video feed" sounds like a ranking question. On mobile it is a resource question: how many videos you prepare, how many players exist, what the cache throws away, and what the phone does when it gets hot. A worked answer from the hiring side.
13 min read
Mobile system design
Image loading system design interview: a scrolling feed, answered from the hiring side
"Design the image loading for a scrolling feed" sounds like a library question. It is a memory question: what an image costs once it is decoded, who still wants it, and what you give back when the system asks. A worked answer from the hiring side, for iOS and Android.
12 min read
Mobile system design
Eventual consistency in mobile apps, per field
"The app is eventually consistent" describes no app. Each field gets its own choice: strong, provisional, eventual or human. Then come the parts users notice: what the screen shows while data converges, how an optimistic change rolls back, and which edit wins. Last write wins, hybrid logical clocks and CRDTs, with what each costs, for iOS and Android.
15 min read
SwiftUI
TCA vs MVVM in SwiftUI: who owns the state
A team decision, not a style preference. Since Observation, both sides render efficiently; what still separates TCA and MVVM is who may mutate state, how effects are represented, what a test has to prove, and what the team pays to learn, upgrade and one day leave the library.
14 min read
Mobile system design
ADR examples for mobile teams, with a template
Most ADR templates were written for servers, where a bad decision can be redeployed away. Mobile decisions live on in installed builds. A copyable ADR template with a versions-in-the-wild section, three complete mobile examples, revisit triggers that name evidence, where the records live, and how they keep a decision closed.
14 min read
Mobile system design
Kotlin Multiplatform in an existing app
In an app that already has two good native codebases, Kotlin Multiplatform is a boundary: which rules become one implementation, who owns them on iOS, and what evidence stops the expansion.
14 min read
Mobile system design
Best mobile architecture books for senior engineers
Most lists of the best software architecture books are written for backend systems. A mobile app adds clients you cannot recall, versions that stay installed for years and releases that wait for review. A reading list grouped by the problem you have, with what each book is for, where it stops on mobile, and which ones are mine.
11 min read
Mobile system design
Background sync on iOS and Android: what you can promise
A product manager asks for sync every fifteen minutes in the background. Neither platform will give it to you. Promise something else: work the user did is never lost, data is current when the app opens, and the screen says how old it is. What iOS and Android guarantee, checked against their documentation, and a design that survives process death and deferral.
14 min read
Mobile system design
Do you need a BFF for your mobile app?
A BFF is usually sold as a way to turn many calls per screen into one. The harder half is organisational: someone has to own and run it, and every app version you shipped pins its contract. When a backend for frontend pays off, who owns it, how to change it safely, and when not to build one.
15 min read
Mobile system design
Server-driven UI on mobile: when it pays off
Server-driven UI does not remove the release problem. It moves it into a schema that every supported app version has to keep rendering. What it buys, what it costs, where it fits, and the rules that keep it from turning into a language.
15 min read
SwiftUI
UIKit to SwiftUI migration strategy for a large app
Most SwiftUI migrations measure progress in screens converted. The ones that hold measure it in boundaries: a stable entry contract, one owner for state, one authority for navigation, a rollback that is a flag and not a revert. A strategy for a large UIKit app that keeps shipping.
12 min read
Mobile system design
Mobile release train: cut-off, hotfix and go/no-go
A mobile release train is a schedule plus a set of decision rights: who cuts, who may board late, who calls go or no-go, who can stop it at night. How to set the cadence, run the cut-off, ship a hotfix while a train is in flight, and measure the train itself.
13 min read
Mobile system design
How to choose a sync solution for a mobile app
Most sync decisions start with a comparison table of products. The table is the last step. Before it come three decisions no product makes for you: what the app promises offline, who owns the truth for each kind of data, and which conflicts a machine may settle. A vendor-neutral guide for iOS and Android teams, with a build-or-adopt rule.
13 min read
Mobile system design
Rewrite or refactor a mobile app? Write the kill criteria first
"We should rewrite the app" is usually said in a planning meeting by someone who is tired of the old code, and decided by someone who cannot see it. How to make the case either way: what a rewrite hides, which unit you are really changing, the evidence to gather first, the conditions that stop the work, and how to put it to a manager who wants a clean slate.
13 min read
Mobile system design
Phased release vs staged rollout: what halting does
Apple's phased release and Google Play's staged rollout both stop the spread of a build, and neither takes it back. What each store documents, what pausing and halting reach, why a crash-free number at 1 percent proves little, and how to write the halt rule before day one.
14 min read
Mobile system design
How long to support old mobile app versions
The support window for old app versions is read off the tail of your own adoption curve, written down as two floors, and owned by a named person. Plus what a forced update cannot fix.
14 min read
Architecture
Mobile feature flag cleanup: the flag outlives the release that removed it
On a server, cleaning up a feature flag is one motion. On a phone it is three, on three clocks, and the last one belongs to the installed fleet. Expiry by job, the order that survives old binaries, and how to price the flags you already have.
11 min read
Mobile system design
When to modularise a mobile app (and when not to)
Modularisation is usually sold as the cure for a slow build. A module is a rule the team pays for every week, in build configuration, review, navigation and onboarding. When a boundary earns that cost, when it does not, and how to tell you have gone too far, for iOS and Android.
10 min read
Mobile system design
Mobile app kill switch: how to design one
A remote kill switch is the one control you still hold after a binary is installed. How to design it so it works on the day you need it: what off means, safe defaults, caching, independence, reach, audit and drills.
12 min read
Mobile system design
MVVM, MVI, TCA, Redux or VIPER? The senior answer names the pressure first
"Which architecture would you choose?" sounds like a pattern quiz. It is scored on whether you name the pressure before the pattern, and whether you know what each pattern costs to leave. A worked answer from the hiring side, for iOS and Android.
10 min read
Mobile system design
Mobile architecture migration interview: change the app without stopping the release train
"How would you migrate this app's architecture without stopping the release train?" is a question about the months between two diagrams, not about the destination. A worked answer from the hiring side, for iOS and Android alike.
12 min read
Swift concurrency
Swift 6 rejected the race. ARC stayed atomic.
Swift 6 can prove that some code is safe from data races. That does not mean reference counting suddenly becomes non-atomic.
9 min read
Swift concurrency
You cancelled the caller. Why is the shared Task still running?
Swift cancellation is cooperative. Cancelling the task that is waiting does not automatically cancel the separate task it is waiting on.
5 min read
Swift concurrency
An actor protects state. It does not own every retain and release.
Actor isolation is a concurrency guarantee. ARC is a lifetime mechanism. Treating one as a complete proof about the other is where the mental model starts to drift.
6 min read
SwiftUI
Your SwiftUI app works. Production is where it starts lying to you.
Three failures that appear after the happy path: stale results, slow "lazy" lists, and state ownership that no longer scales.
10 min read
SwiftUI
What minimumScaleFactor trades away in SwiftUI
I ran into a typography inconsistency in a production SwiftUI interface, then reduced it to a reproducible case to understand what minimumScaleFactor was trading away.
10 min read
Architecture
Mobile system design is not backend system design
Why offline, device constraints, sync, app lifecycle and platform boundaries change the interview and the architecture.
5 min read
Performance
Why iOS apps feel slow even when the API is fast
A practical look at the client-side bottlenecks that make mobile apps feel slow after the backend has already done its job.
9 min read
SwiftUI
SwiftUI vs UIKit: architecture is state ownership
Why production SwiftUI architecture is less about folder names and more about ownership, identity, effects and boundaries.
5 min read
Architecture
Security requirements that cannot be tested are not finished
A security requirement becomes useful when a team can observe the behaviour, test the boundary and know who owns failure.
3 min read
