iOS system design
iOS System Design Interview Guide
A repeatable framework for designing the client, not a backend diagram with an iPhone attached.
Short answer
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 are not looking for one perfect diagram. They are looking for a design whose tradeoffs match the product and for 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 favorite pattern.
- Primary user journey and response-time expectation
- Offline read and write behavior
- Consistency and conflict requirements
- Data sensitivity and local protection
- Background and notification behavior
- 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.
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.
