How do you design an offline-first Android app?

Direct answer

What a strong answer covers

How it works

The local database is the single source of truth: screens observe it, and the network only updates it. Writes go to the local store immediately together with a pending-operation record, so the UI reflects the change at once; a sync worker, typically WorkManager with network constraints, replays pending operations, applies server responses, and pulls remote changes. Conflicts need a documented rule per entity, such as last-writer-wins with a server timestamp or a merge of fields, and the UI needs to show what is pending, synced, or failed so users trust the app when the network is bad.

Example

A field-service app lets technicians complete job forms underground; each submission is saved to Room with status PENDING and a unique client ID, WorkManager uploads it when connectivity returns, and the server uses the client ID to make retries idempotent. If the office edited the same job meanwhile, the server returns both versions and the app asks the technician which fields to keep.

Common mistakes

• Treating the network response as the source of truth and rendering an empty screen offline.
• Retrying uploads without idempotency and creating duplicate records after a flaky connection.
• Silently dropping conflicting writes instead of surfacing them to the user.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.