Design an offline-first travel plans app (Android and iOS)

Build it. The database schema, API, code and platform limits for an offline-first travel plans app are on a separate page: Build it: an offline-first travel plans app on Android and iOS (16 min read).

How to read this. This page is a 45-minute round (the length I assume), in the order I would spend it. Schema, API, code and platform tables are in the build guide. The follow-up questions are my reconstruction of the challenges that public prep material reports. They are not transcripts of real rounds.

TL;DR. The hard part is not the sync. It is deciding what a companion may lose. My answer: nothing a person typed is lost without a sign. The server decides, one field at a time. A time keeps the clock of its place.

1. Scope and constraints (minutes 0 to 4)

In short: Promise that nothing typed is lost silently. Keep photos and roles. Park live cursors, expenses and public links.

A prompt I would expect: "Design an app where friends plan a trip together, even on a plane with no signal."

I ask five questions and give a default for each:

• How many people, and how long offline? Two to six, and weeks.
• What do people edit? Items with a title, time, place, note and photos.
• What must a companion see? My change after their next sync.
• Which phones and roles? Android and iPhone. Owner, editor, viewer.

The phone does four things to this design.

Your decision. Someone wants the trip to work like a shared document. Do you promise that every offline edit merges, or that nothing typed is lost and real conflicts are shown?

First idea, and why it fails. Promise a shared document. This fails when two phones are away for days and both change the same field. An automatic merge then makes text that nobody wrote.

What I would say. The promise is no silent loss. A conflict (two changes to the same field) is shown, and one tap keeps my version.

Say this. "Nothing a person typed disappears without a sign. Different fields merge by themselves. If two people change the same field, the server keeps one value, and the other person sees a conflict with a keep-mine button. Live cursors, expenses and public links wait."

The follow-up question I expect: "Users will expect live cursors."

They are parked. Live cursors need a connection, and this product is defined by not having one. Follow-ups 2 to 4 return the other parked items.

45-minute plan

2. Data and contracts (minutes 4 to 14)

In short: The local database is the truth. Each change is one field with a base revision. The server decides.

Your decision. Who decides which edit wins? The device clock and the whole item, or the server, one field at a time?

First idea, and why it fails. Keep a modified time on each item, and let the newest save win. This fails when one phone has a wrong clock. It fails again when two people change different fields of one item. The older field disappears.

What I would say. A waiting change is one field. It carries the base revision, the revision the person was looking at. A revision is a number the server raises with each accepted change. The server applies the change only if that field has not changed since. Otherwise it keeps its value and reports a conflict.

I reject last-writer-wins on the whole item. I also reject a CRDT (a data type that merges edits by itself).

The follow-up question I expect: "Why not a CRDT?"

A CRDT merges without a central decision. But its history grows, and both platforms must follow its rules exactly. Only long text needs it. A trip note is short, so a visible conflict is enough.

The follow-up question I expect: "Two people add an item at position 3 at the same time."

Each item has a position key, a text value that sorts between its neighbours. If both phones pick the same key, the item ID breaks the tie.

The contract has four calls:

• Snapshot: the whole trip and a cursor (a saved position in the server's list of changes).
• Changes: everything after a cursor, or "too old".
• Submit: a request ID and field changes. Each gets a result: applied, conflict or rejected.
• Photo: a place to upload one photo.

The request ID is the idempotency key (the chat case calls it clientId). It makes a retry safe: doing it twice has the same result as doing it once.

These are my own assumptions, not measurements:

3. Client structure (minutes 14 to 22)

In short: Sending sits below the screen. A repository owns the outbox, and the platform decides how it is drained.

Your decision. Who owns the sending? The screen's ViewModel, a foreground service, scheduled background work, or the app's own outbox?

First idea, and why it fails. The ViewModel (the class that holds a screen's state). It starts each send in viewModelScope. But Android clears a ViewModel when its screen leaves the back stack (ViewModel). The app process can also stop at any time. Then a send in progress is lost or repeated.

What I would say. One local transaction writes the edit and one outbox row (a table of changes not yet sent). A repository owns the draining.

• On Android, WorkManager runs it, as one unique chain per trip. Android documents it for work that must run even if the app exits or the device restarts (task scheduling).
• On iOS, the app drains the outbox itself: after an edit, in the foreground, and when the network returns.

I reject a foreground service. An app that targets Android 12 or later cannot start one from the background, except in a few special cases (restrictions).

The follow-up question I expect: "On iOS, what if the person force-quits?"

The edits are already in the database, and the server ignores a repeated request ID. The photo goes back to queued at the next launch. I do not claim that iOS relaunches the app after a force-quit.

 UI (Compose / SwiftUI)
    │ observes
 ViewModel
    │
 TripRepository ──────────────┐
    │ reads, writes           │ drains
 Local database (truth)    Outbox and sender
  trips, items, outbox      Android: WorkManager
    ▲                       iOS: own drain
    └───── writes ───── REST: changes, submit, photo upload

The screen and ViewModel are the UI layer, and the repository is the data layer (recommendations). Three rules:

• The UI never talks to the network. It reads the database.
• One writer drains the outbox.
• The screen shows the server value with the waiting changes applied on top.

4. Make the hard part work (minutes 22 to 40)

In short: Times keep their place's clock. A long gap needs a snapshot. A photo uploads alone.

4.1 What "10:00" means, and the order of a day (minutes 22 to 31)

Your decision. What does "10:00" mean? Do you store the moment, the wall clock, or both? And what orders a day?

First idea, and why it fails. Take the phone's zone, convert to UTC, and store the instant. This fails when the person plans from home, because the phone is in the wrong place. It fails again for a future event. If a government changes a zone rule, the instant then means a different local time. RFC 9557 says it does not address this case (RFC 9557).

Phones get rule updates at different times (Android).

What I would say.

Say this. "I store what the person meant: a local date and time, plus an IANA zone ID, a place name such as Europe/Lisbon. The exact moment is derived and cached for sorting and flight length. I never store a fixed offset. A day belongs to the item's own date. Inside a day, I sort by time, then by a position key for items with no time."

I reject fixed offsets, and UTC alone. An optional offset only picks between the two copies of a repeated hour. By default, Java takes the earlier one, and moves a skipped time forward (ZonedDateTime).

The follow-up question I expect: "Lisbon 10:00 to New York 13:00. How long is the flight?"

Eight hours, on 10 June 2027 with today's rules. Duration is arithmetic on instants. Lisbon is UTC+1 in June and New York is UTC-4. Subtracting the wall clocks gives three hours, which is wrong.

4.2 Coming back after three weeks, and a photo that dies (minutes 31 to 40)

Your decision. A phone comes back after three weeks. Do you replay the changes, take a fresh snapshot, or do something else?

First idea, and why it fails. Ask for everything since the last sync time. This fails when the phone clock is wrong. Deletes never appear in that list. A pull can also overwrite an unsent edit, so the text jumps back.

What I would say.

Say this. "The server gives an opaque cursor, a position the app never reads. The app asks for changes after it. If the server says too old, the app takes a snapshot, keeps its waiting changes, and sends them again. A waiting value always sits on top of the server value, so nothing jumps back. A photo is its own upload, with an offset that the server confirms."

I reject a cursor made from device time. An old standard has the same shape: a server may reject an old token, and the client starts again (RFC 6578).

The follow-up question I expect: "A companion deleted an item that you edited."

The delete wins. Your edit comes back as a conflict with a Restore button. Deleting someone's work silently is the worse failure.

• A delete is a tombstone, a row that says "deleted", kept for a while.
• A phone that was offline learns about the delete from it.

The follow-up question I expect: "The upload died at 70 percent" (example).

The app asks the server for its offset and continues from there. It does not start again.

4.3 Where iOS and newer Android change the design

• A background upload on iOS must come from a file. Apple describes a growing delay for new background download tasks. I assume uploads are the same, so I use one session (Apple).
• For a transfer the person starts, Android 14 (Android) and iOS 26 (Apple) have newer paths. The Android page shows a download example, so I do not claim uploads. The system can stop both, so I save the offset.

5. Break it, ship it, roll it back (minutes 40 to 45)

In short: Each failure ends in saved data, a clear message, or a late update, never a silent loss.

Releases:

• The stores let me pause a rollout, not recall it. On Play, a halt leaves users who have the build on it (Play Console). On Apple, a phased release can pause for up to 30 days (Apple). That page does not mention reverting installed copies.
• The kill switch is a remote flag (a setting the server can change). It turns the new merge path off and falls back to snapshot pulls. It is the only rollback that reaches installed apps.
• A local schema change cannot be flagged off. It ships with a migration, one release before the code that needs it.

Say this. "I cannot recall a bad build, so my rollback is the flag plus a fixed build. I would watch the conflict rate and the too-old rate. I left out expenses, live cursors and link sharing."

6. Follow-ups that change a constraint (no minutes)

In short: Each follow-up changes one constraint. A strong answer says what breaks.

Practice prompts, not a claim about what any interviewer asks.

1. A phone was away for six weeks, and the trip has 900 changes. Strong: the server says too old. The app takes a snapshot, keeps its waiting changes, sends them again and shows the conflicts. Weak: "Sync everything again and overwrite."
2. Add shared expenses. Strong: each expense is an append-only entry, so two additions never conflict. The balance is computed. Weak: one editable total, which two phones overwrite.
3. Two people type in the same note. Strong: per-field merge is not enough for one long text. Use a text merge for that one field, or show both versions. Weak: a CRDT for the whole trip.
4. A read-only link for family, and a companion is removed. Strong: the server checks every request. The link is a token with an expiry. Removal arrives as a change, and the phone deletes the trip after a warning. Weak: hide the buttons on the client.
5. After release, people report deleted items coming back. Strong: pause the rollout and switch the flag to snapshot pulls. Compare tombstone retention with how long phones stay away. Weak: "We ship a fix next week."
6. The time model changes to wall clock plus zone, and many users run old builds. Strong: send both fields for a while. Old clients read the instant, and new clients read the wall clock. Retire the old field with a minimum version. Weak: force an update.

7. What changes by level

In short: As I read it, levels differ in who raises the problem, and in whether a rollout plan comes with it.

These levels are my own reading of the bar, drawn from vendor and prep material, not any company's rubric.

• Mid-level: the local database as truth, edits sent with a retry, photos in the background. They say how two edits are handled. I want to hear: "I never lose what the person typed."
• Senior: field changes with a base revision, request IDs, position keys, wall clock plus zone, an opaque cursor. I want to hear: "When two phones disagree, here is what the user sees."
• Staff: the merge decision and its cost, one protocol tested on both platforms, tombstone retention tied to the offline gap, and a kill switch. I want to hear: "Here is the guardrail that halts the rollout."

Common weak answers. These repeat across public prep material.

• Last write wins on the whole item.
• Naming a CRDT with no reason.
• Device time as the order or the cursor.

Staff answer: the decision and the rollout

• Decision: keep per-field merge with the server as arbiter, in one sync engine with a small contract: add a change, watch the waiting state, resolve a conflict. Test both platforms against shared test cases.
• Alternative: a CRDT or an operation-log library for the whole trip. It costs history growth and a protocol that is hard to change in the field.
• Revisit trigger: a need that per-field merge cannot express, such as two people typing in one long text.
• What to measure: conflicts per 1,000 changes, the share resolved with keep-mine, age of waiting changes, the too-old rate.
• Rollout: the server keeps the old change format. The new merge path sits behind a flag, with the old path kept in the app. See the staff mobile loop guide.
• Guardrail: no rise in reports of lost edits or of deleted items coming back.

Opinion vs verified: I read the offline-first, WorkManager, background session, zone and rollout facts in official docs. The per-field choice, the wall-clock model, the numbers, the metrics and the rollout plan are my opinion.

Further reading (official docs)

• Build it: an offline-first travel plans app on Android and iOS: schema, REST, code and platform limits for this case
• Build an offline-first app (Android): lazy writes, queues, pull, push and hybrid sync, last write wins
• Task scheduling and WorkManager (Android)
• User-initiated data transfer jobs (Android)
• Time zone rules (Android)
• Verify Android App Links
• Downloading files in the background (Apple)
• BGContinuedProcessingTask (Apple)
• TimeZone (Apple)
• RFC 9557: timestamps with zone names
• RFC 6578: collection synchronization
• Related case studies: Chat app, Photo and file sync, Booking app

Keep reading

• Build it: an offline-first travel plans app on Android and iOS
  The schema, API, code and platform limits behind this answer.
• Design a public transport app
  A timetable that works offline, live delays on top, and careful use of location and battery.
• Design a chat app
  Outbox, safe retries (idempotent sends), and sync with WebSocket and push.
• Design a news feed
  Paging, optimistic writes (show a change first), and keeping the cache fresh.
• Guide: Staff-level mobile system design: what the round tests
  How staff answers differ from senior answers, what interviewers can see, and a four-week practice plan.
• Guide: Native vs cross-platform: write the decision record
  A staff-level decision record (ADR) for choosing a framework. It covers criteria, the assumption that would change the choice, migration, parity tests, libraries with no owner, rollback, and a free template.