iOS system design
iOS system design interview guide
A repeatable framework for designing the client, not a backend diagram with an iPhone attached.
Mobile System Design Blueprint (book, from $199)
iOS system design: what matters most
An iOS system design interview should begin with user journeys and device constraints, then move through state, data flow, networking, persistence, synchronization, performance, security and observability. Clarify whether the product must work offline, how fresh data needs to be, which actions are destructive, how multiple devices interact and what the operating system may suspend. Define a source of truth and the boundaries between presentation, domain logic and data access. Explain cache invalidation, conflict policy, retries, idempotency, background execution and release migration.
Finish with failure states and measurement. Interviewers look for a design whose tradeoffs match the product and an engineer who can identify what will fail first.
Start from mobile requirements
Ask about connectivity, device storage, battery, latency, accessibility, privacy, supported OS versions and the cost of stale data. These answers determine architecture more than a favourite pattern.
- Primary user journey and response-time expectation
- Offline read and write behaviour
- Consistency and conflict requirements
- Data sensitivity and local protection
- Background and notification behaviour
- Scale, migration and observability
Draw state before layers
Name server state, durable local state, pending mutations, derived view state and transient presentation state. Then show how each changes when a request succeeds, fails or completes after the screen disappears.
Once state ownership is clear, repositories, stores and view models have a reason to exist. Without it, the diagram is only boxes.
Rehearse one case: a download that outlives the window
A user starts downloading a document on an iPad, closes the window and opens the app later. Keep three owners apart. The scene owns the selected document and navigation. The account data layer owns the list of documents. An app-level transfer coordinator with a durable record owns the download. Closing a scene must not erase the operation.
Match the transfer to the promise. A background URLSession keeps transferring outside the app process and reconnects after the system terminates the app, but a user force-quit ends it, so do not promise the same thing for both. Recreate the session with the same identifier on relaunch. A Task owned by a view fits work that only matters to that screen.
Treat completion as a pair: the file is moved from its temporary location to permanent storage, and the local record says it is available. If the move fails, the UI must not show an offline copy. If the app stops between the move and the record update, a recovery pass reconciles them.
Last, sign-out. If account A signs out mid-transfer, the completion callback still arrives for A's file. Decide whether to cancel or keep it under A, and never let the next account see it.
Close with failure and rollout
Cover partial data, schema migration, duplicate writes, token expiry, clock drift and corrupted cache. Explain what the user sees and what telemetry tells the team the system is unhealthy.
A senior design also includes staged rollout, backwards compatibility and an exit plan if the migration underperforms.
