Mobile App Architecture

Definition

The structure of a mobile application and its relationship with backend services — dominated by three constraints that web clients do not share.

The three constraints

1. You do not control the release. App store review adds latency, users choose whether to update, and some never do. A bug shipped in a mobile release cannot be hot-fixed, which changes the risk calculus for every change and is the strongest argument for server-driven configuration.

2. Old versions persist indefinitely. A meaningful proportion of users run releases from a year or more ago. Every API change must be compatible with every version still in use, and "we will deprecate it in six months" means six months after the last user upgrades.

3. The network is unreliable and expensive. Intermittent connectivity, high latency, metered data, and battery cost per transmission.

The architectural responses

Server-driven behaviour where possible. Configuration, feature flags, and even some layout decided server-side, so behaviour can change without a release. This is the main mitigation for constraint one, and it is worth designing in from the start.

Offline-first for anything the user must be able to do without a connection. Local storage as the source of truth for the interface, with synchronisation in the background. This is a substantially larger undertaking than caching — it introduces conflict resolution — and it should be entered deliberately rather than drifted into.

Aggressive API versioning discipline. Additive changes only; never remove a field an old client reads; instrument per-version usage so you know what is actually in use before changing anything.

Batched and coalesced network activity, because each radio wake-up costs battery disproportionately to the bytes transferred.

A screen-shaped API — a backend for frontend or equivalent — so one screen is one round trip rather than six.

Failure scenarios

• A breaking API change that strands old clients with no route to recovery.
• No server-driven configuration, so every behaviour change needs a release.
• Offline treated as an error state rather than a normal one.
• Chatty APIs, so screens are slow on real networks and expensive in battery.
• No per-version telemetry, so nobody knows what is safe to change.

Interview question

"What changes about API design when your clients cannot be upgraded?"