Mobile System Design Interview: 6 Real Questions

A mobile system design interview demands a different way of thinking than a backend system design question: where server-side questions revolve around horizontal scaling and database schemas, mobile is dominated by battery, intermittent network connectivity, OS-imposed background constraints, and the limited resources of a single device. In this piece we'll cover the five core differences between mobile and backend system design, six real question types (news feed, offline sync, chat, real-time updates, file upload, background jobs), and a skeleton for structuring your answer — grounded in Android's official architecture guide and Apple's BackgroundTasks documentation.

💡 Pro Tip: In the interview, draw the direction of data flow first — state down, events up. Jumping straight to class names without putting this flow into words is a common trap; the evaluator is listening for exactly that.

Table of Contents

• Five Differences Between Mobile and Backend System Design
• 1. Separation of concerns cuts deeper than in backend
• 2. Network connectivity is a rule, not a guarantee
• 3. UI is fed from a persisted data model
• 4. The unidirectional data flow (UDF) requirement
• 5. Background work is constrained by the system
• Answer Skeleton: Requirements, Constraints, Data Flow, Trade-offs
• Question 1-2: News Feed and Offline Sync
• Question 1: How do you design a news feed?
• Question 2: How do you solve offline sync?
• Question 3-4: Chat and Real-time Updates
• Question 3: Chat app architecture
• Question 4: Real-time updates — refresh or push?
• Question 5-6: File Upload and Background Jobs
• Question 5: How do you upload a large file?
• Question 6: Background maintenance jobs (cleanup, sync, indexing)
• The Technique of Thinking Trade-offs Out Loud
• 5 Common Mistakes and Recovery Lines
• FAQ
• What gets asked in a mobile system design interview?
• What's the difference from backend system design?
• How should I structure my answer?
• Do background tasks always run?
• Which sources should I look at?
• Update (September 2026)
• Conclusion
• Sources

Five Differences Between Mobile and Backend System Design

In backend system design questions, scaling and consistency are central; in mobile, a single user's device, its constraints, and its connectivity state are central. Android's official architecture guide clearly defines a few principles that form the basis of this difference.

1. Separation of concerns cuts deeper than in backend

The Android architecture guide defines "separation of concerns" as the most fundamental principle: dividing the app into methods, classes, files, packages, modules, and layers with clearly defined responsibilities and boundaries. In mobile, this separation isn't just for code readability — it's also mandatory because of a single process's lifecycle (being backgrounded, terminated, restarted).

2. Network connectivity is a rule, not a guarantee

In backend, one service failing to reach another is an error scenario; in mobile, network dropouts are part of the normal flow. The Android guide states that in offline-first apps, "the source of truth is typically a database" — the network isn't a pipe carrying data straight to the UI, it's a source that feeds the local database. Saying this out loud (the network is a data source, not the SSOT) preemptively answers most follow-up "what if the internet drops?" questions. To go deeper, see Network Layer Optimization.

3. UI is fed from a persisted data model

"Another important principle is to drive UI from data models, preferably persistent ones," says the Android guide. In backend this is usually a matter of an API contract; in mobile, the UI layer itself is a state machine that must stay consistent even after the app is backgrounded and returns.

4. The unidirectional data flow (UDF) requirement

The Android guide describes UDF like this: state flows in only one direction, events flow in the opposite direction. In mobile interviews, the root cause of the "two screens show the same data differently" bug is usually this unidirectional flow being violated — state getting duplicated in more than one place. Explaining how you preserve this flow while splitting the architecture into layers lines up directly with the layer boundaries in Clean Architecture (iOS).

5. Background work is constrained by the system

In backend, you decide when a cron job runs; in mobile, the operating system decides. Apple's BackgroundTasks documentation puts it plainly: "Support background processing by wrapping your app's most critical work in framework-provided tasks." In other words, saying "I'll sync X in the background" isn't enough in an interview — you need to know which framework task type to use, and when and how the system will constrain that task. Once the candidate has placed these five differences into the body of the answer, they've shown they're thinking with mobile-specific constraints rather than backend reflexes.

Answer Skeleton: Requirements, Constraints, Data Flow, Trade-offs

A good mobile system design answer is built on a fixed four-step skeleton. This skeleton stays the same regardless of the question's content (news feed, chat, file upload) — the evaluator is looking for exactly this consistency.

As long as the candidate voices these four steps out loud, they've shown "how they think" even without knowing every detail of the question — and that's exactly what the interview is really measuring.

Question 1-2: News Feed and Offline Sync

Question 1: How do you design a news feed?

This question usually comes as "design an infinite-scroll news feed." Applying the skeleton: requirements (is it readable offline, how many sources merge), constraints (battery/data saving), data flow (repository → local DB → UI), trade-off (rendering directly from network vs. writing to DB first then reading from DB). The Android guide defines the data layer like this: "The data layer is made of repository classes that can each contain zero to many data sources, and resolve conflicts between the data sources." For a news feed, this means multiple sources — network source + local cache + user preferences — merging behind a single repository.

1// Simplified repository — SSOT is the local database, the network is just one source
2class NewsFeedRepository(
3    private val local: FeedDao,
4    private val remote: FeedApi,
5) {
6    // UI always reads from local; the network only updates local
7    fun observeFeed(): Flow<List<FeedItem>> = local.observeAll()
8 
9    suspend fun refresh() {
10        val items = remote.fetchLatest()
11        local.upsertAll(items) // conflicts are resolved right here, at the repository level
12    }
13}

Question 2: How do you solve offline sync?

This question usually comes as a follow-up to Question 1: "what if the user likes/comments while offline?" You apply the same answer skeleton, but the data-flow step expands: the user's action is written to the local database first (SSOT), then sent to the network through a queue (outbox), and once the server confirms, the local record is updated. The Android guide's principle that "in offline-first apps the source of truth is typically a database" applies directly here — the user's action is never written straight to the network and assumed "successful" in the UI; it's written to local truth first.

The trade-off here is clear: a synchronous network call (simple, but blocks the user and breaks offline) vs. an outbox plus background sync (durable, but requires conflict resolution and idempotency). A candidate who voices this trade-off should also point to the repository boundaries in Clean Architecture (iOS) to explain which layer handles conflict resolution.

Question 3-4: Chat and Real-time Updates

Question 3: Chat app architecture

For a chat question, the evaluator usually wants to see how you separate a message appearing instantly on the local device (optimistic UI) from it being sent reliably in the background. The skeleton is the same here too: SSOT is the local message table, send status (sending/sent/failed) is modeled as a separate field, events flow up (user hits send), state flows down (the message list updates).

In practice: the moment the user taps send, the message is written to the local table with a "sending" status and the UI updates instantly — the user never feels network latency. In the background, a separate handler reads that row, sends it over the network, and writes the result back to the same row; since the UI already observes that row, it updates automatically, with no separate "send completed" event needed. The benefit: even if the app is backgrounded and killed, "sending" messages aren't lost — they resume on next launch, because state lives in persisted data, not in an event. This gives you a ready answer to "why a data model and not an event": an event is transient and dies with the process; a data model persists.

Question 4: Real-time updates — refresh or push?

Here candidates often run into "is periodic refresh enough, or do we need push/sockets?" Apple's BackgroundTasks documentation clarifies one side of this trade-off: "Use app refresh tasks to refresh your app's content in the background with small updates of information, such as current stock prices." In other words, periodic background refresh (BGAppRefreshTask) is designed for low-frequency, small data updates — it isn't suitable for high-frequency, low-latency scenarios like chat; for those, push notifications plus sockets/long-polling are preferred. Running these tasks also requires setting the fetch UIBackgroundModes capability in Info.plist.

1// Registering BGAppRefreshTask — for low-frequency refresh (NOT for chat)
2func registerRefreshTask() {
3    BGTaskScheduler.shared.register(
4        forTaskWithIdentifier: "com.example.app.refresh",
5        using: nil
6    ) { task in
7        handleAppRefresh(task: task as! BGAppRefreshTask)
8    }
9}
10 
11func scheduleAppRefresh() {
12    let request = BGAppRefreshTaskRequest(identifier: "com.example.app.refresh")
13    request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60)
14    try? BGTaskScheduler.shared.submit(request)
15}

Voicing this distinction in the interview (refresh task = small/periodic, socket/push = instant) is a point that's frequently missed in system design questions.

Question 5-6: File Upload and Background Jobs

Question 5: How do you upload a large file?

This question usually comes as "the user picked a large video; the upload should keep going even if they leave the app." Apple's documentation points here to BGProcessingTask: "Use processing tasks for long data updates, data processing, and app maintenance... the system may interrupt the operation." So a file upload isn't a short refresh task — it's a processing task that can take minutes and that the system can cut off; not knowing this leads to an unrealistic answer like "I'll just keep it running in the background."

Two fields of BGProcessingTaskRequest make the trade-off concrete: requiresNetworkConnectivity (does it need network) and requiresExternalPower (does it need external power).

1// Large file upload — processing task, network required, power optional
2func scheduleUpload(fileSizeIsLarge: Bool) {
3    let request = BGProcessingTaskRequest(identifier: "com.example.app.upload")
4    request.requiresNetworkConnectivity = true
5    request.requiresExternalPower = fileSizeIsLarge // preferred for very large files
6    try? BGTaskScheduler.shared.submit(request)
7}

If asked in the interview "why processing, why not refresh," the answer is clear: refresh tasks are designed for small data, processing tasks for work that can run for minutes.

Question 6: Background maintenance jobs (cleanup, sync, indexing)

This question covers periodic work that shouldn't block the user, like "clear the old cache" or "update the search index." Apple's documentation states the operating condition for processing tasks plainly: "Processing tasks run only while the device is idle. If the user starts using the device, the system terminates any running processing tasks; refresh tasks are unaffected." This one sentence also explains a trap that's easy to fall into during interviews: the assumption "my background maintenance job always completes" is wrong — the job can be cut off mid-way, so it must be designed to be idempotent and resumable.

1Task type decision tree (per Apple BackgroundTasks)
2  Small, periodic data update?        -> BGAppRefreshTask
3  Operation/maintenance taking minutes? -> BGProcessingTask
4     requiresNetworkConnectivity = is network required?
5     requiresExternalPower       = is it large/power-intensive work?
6  If device isn't idle, processing gets cut off -> the job must be idempotent

A candidate who clearly distinguishes these two task types (refresh/processing) and the two flags (network/power) has shown they know when the system does and doesn't grant permission — that's exactly the point that's easy to overlook in the interview.

The Technique of Thinking Trade-offs Out Loud

One behavior that makes a real difference through the interview is not deciding silently, but thinking the trade-off out loud: "I have two options, here's the criterion I'm deciding by." The Android guide's definition of UDF points the way here too — it lists, together, "unidirectional data flow across all layers of the app, with state holders to manage complexity, the UI layer, coroutines and flows, and dependency-injection best practices." In other words, your architecture answer isn't judged only on "layer names" — it's judged on the direction of flow between layers and which tool (coroutine/flow, state holder) you use to manage that flow.

The point isn't to memorize this table, but to grasp its logic (small/large, periodic/instant, single-source/multi-source) — that's the transferable skill. When a new question comes up, identifying which of these three axes (data size, timing frequency, number of sources) is in play beats searching the table for a matching row — the interview measures whether you can rebuild the same logic for a new variation, not rote memorization. For example, "queue a large file offline periodically and upload it once connectivity returns" combines the three rows above: a local queue as the SSOT, a processing task for scheduling, a network-connectivity flag as the condition. Combining these three axes sends a far stronger signal than memorizing the table row by row.

5 Common Mistakes and Recovery Lines

• Mistake 1 — Treating the network as the SSOT: The candidate describes rendering data straight from the network. Recovery line: "Actually, the network here is just a data source — the real source of truth should be the local database; the repository merges the two."
• Mistake 2 — Duplicating state in more than one place: Two screens show the same data differently. Recovery: "I'd solve this with unidirectional data flow; state comes from a single place, events flow back to it."
• Mistake 3 — Assuming a processing task is guaranteed to complete: The candidate says "it finishes in the background" but doesn't account for interruption. Recovery: "A processing task can be cut off while the device isn't idle, so I design the job to be idempotent and resumable."
• Mistake 4 — Confusing refresh and processing tasks: Tying a large file upload to a refresh task. Recovery: "Refresh is for small/periodic data, processing is for work that can take minutes — I'd use processing here."
• Mistake 5 — Never voicing the trade-off: Presenting a single solution without justification. Recovery: adding the line "I had two options, and I chose this one for this reason" to the end of every answer makes visible the exact skill the interview is evaluating.

FAQ

What gets asked in a mobile system design interview?

Usually one of six question types: news-feed-like list screens, offline sync, chat apps, real-time updates, large file uploads, and periodic background maintenance jobs. The surface of the question changes, but what's being evaluated stays the same: whether you think through data flow (SSOT, UDF) and mobile-specific constraints (battery, network, background permissions) in the right order.

What's the difference from backend system design?

Backend questions revolve around scaling and distributed consistency; mobile questions revolve around a single device's constraints (battery, intermittent network, the OS's background limits). Android's official architecture guide makes this difference concrete with the principles "drive UI from persistent data models" and "unidirectional data flow" — in backend, the equivalents of these concepts are usually caching and message queues; in mobile, they're the local database and state holders.

How should I structure my answer?

Apply the four-step skeleton in order: first clarify requirements, then list the constraints, then draw the data flow (from SSOT to UI, and back from event), and finally state a trade-off sentence for each path you chose. This order stays the same regardless of the question's topic (news feed, chat, file upload).

Do background tasks always run?

No. Per Apple's BackgroundTasks documentation, processing tasks run only while the device is idle and can be terminated by the system once the user starts using the device — so these tasks must be designed to be idempotent and resumable.

Which sources should I look at?

On Android, the official "Guide to app architecture" page; on Apple's side, the BackgroundTasks framework documentation (BGTaskScheduler, BGAppRefreshTask, BGProcessingTask) are the most solid starting points — both are written and kept current by the platforms' own engineering teams.

Update (September 2026)

This article was written on 2024-10-22, with the Android and Apple tools of that time. Since then, some of the facts behind interview questions have shifted; knowing the following four developments adds extra depth to your answer:

A constraint that took effect right around this article's publication and still holds today: with Android 15 (October 2024), apps targeting API 35+ got a 6-hour-per-24-hour runtime cap for dataSync and mediaProcessing foreground services, plus restrictions on starting them from BOOT_COMPLETED — so "I keep syncing continuously in the background" now needs a system-managed tool like WorkManager, not a foreground service.

With Android 16 (2025), apps targeting API 36 on an Android 16+ device get predictive back system animations (back-to-home, cross-task, cross-activity) enabled by default; onBackPressed() is no longer called and KeyEvent.KEYCODE_BACK is no longer dispatched — a new constraint on "where is navigation state kept."

Google Play made API 36 the mandatory target API level for new apps and updates as of August 31, 2026 (extension to November 1, 2026); WorkManager (2.12.0) remains Android's primary offline background tool.

Apple also introduced the Foundation Models framework at WWDC 2025, giving Swift API access to the on-device LLM — nonexistent on 2024-10-22; today it can add an extra interview question layer, like "how does on-device AI fit into system design?"

Conclusion

A mobile system design interview isn't a scaled-down backend interview — it's a separate discipline with its own constraints. A candidate who applies the four-step skeleton (requirements, constraints, data flow, trade-off) to every question, and clearly explains the common thread across the six question types (news feed, offline sync, chat, real-time updates, file upload, background maintenance) — SSOT and unidirectional data flow — sends a strong signal. To go deeper on splitting architecture into layers, see Clean Architecture (iOS) and Modular Architecture SPM; for network-layer optimization, Network Layer Optimization; to connect launch performance to architecture, iOS App Launch Optimization; and for memory management tied to state design, iOS Memory Management is a good next stop.

Sources

• Guide to app architecture — Android's official architecture guide; the primary source for SSOT, UDF, and layer definitions.
• BackgroundTasks framework — Apple's background task framework, overview and task types.
• BGTaskScheduler — the primary class reference for task registration and submission.
• BGProcessingTaskRequest — the source for the requiresNetworkConnectivity and requiresExternalPower fields.
• BGAppRefreshTask — the app refresh task class reference.
• BGProcessingTask — the processing task class reference.
• Android 15 behavior changes — foreground service runtime limits for apps targeting API 35.
• Android 16 behavior changes — default predictive back system animations for apps targeting API 36 on Android 16+ devices.
• WorkManager: Getting started — the current primary tool for offline background work.
• WorkManager releases — WorkManager 2.12.0 release notes.
• Google Play target API requirements — the Play Store's target API requirement schedule.
• Apple Foundation Models — Swift API access to the on-device LLM.