Your app lost its connection. What should happen next?

Picture someone filling out a form on a train. They’ve typed several paragraphs, attached a note, and pressed Save just as the signal disappears.

What would you want the app to do?

That small question opens a much bigger design discussion. Should the entry stay on the device? Is it waiting to upload? Can the person close the app safely? And what should the word “saved” mean?

I think those are the right questions to ask before adding an offline badge to a feature list.

Start with what the person needs to trust

For a reading app, being able to open previously downloaded content may be enough. For a field-work app, people may need to record new information without a connection. A booking workflow may need fresh server confirmation before it can promise availability.

Those are different requirements. “Works offline” is too broad to distinguish them.

Write down which actions remain available, which must wait, and which should be disabled with an explanation. That gives the team a product contract to build against.

Local data and remote data have different jobs

Android’s offline-first guidance describes a local data source as the source from which higher layers read, with network updates flowing into that local source. It also discusses queued work and synchronization. Android offline-first architecture

That is a useful technical foundation, but a product still needs rules for freshness. A locally available value may be old. A newly entered value may not have reached the server.

I’d make that distinction visible where it affects a decision. “Saved on this device” and “Synced” tell the user different things. Use wording that reflects the behavior your implementation actually guarantees.

Give a saved note an honest status

For a hypothetical note-taking feature, I would discuss these states with the product team:

• Editing: The person is changing the note. Do not imply durable storage unless it has actually happened.
• Saved on this device: Local persistence succeeded, but server synchronization is still pending.
• Syncing: An upload is in progress. Keep the local copy available.
• Synced: The server acknowledged the version being shown.
• Needs attention: Upload failed or a conflict needs a decision. Explain the next action without discarding the local work.

To check this flow, create a new note offline, close and reopen the app, then restore connectivity. The content should survive, and the status should only change to Synced after the expected acknowledgment.

The same labels would need reconsideration for bookings or other actions that require server confirmation. Saving an intention locally does not reserve a slot.

Decide what happens when two edits disagree

Imagine a shared task edited on a phone without connectivity and on another device while online. When the phone reconnects, which version should remain?

There isn’t one correct answer for every product. Android’s guidance discusses conflict resolution, including versioning approaches such as last-write-wins. The appropriate policy depends on the data and the application. Synchronization and conflict handling

For a proposed feature, I’d ask whether overwriting an older edit is acceptable, whether changes can be merged, or whether the user needs to choose. Decide this before a conflict becomes a support ticket.

A retry should not surprise the user

“Try again” sounds simple until the person cannot tell whether the first attempt succeeded.

For important actions, ask the team to explain how repeated requests are handled. Does the backend recognize the same operation? Can the app show a pending result? When should a person be allowed to cancel?

These are questions to resolve with the API owner, not assumptions to hide inside a loading spinner. The answer may differ between saving a note and confirming a booking.

Test with the network changing mid-action

A useful review goes beyond opening the app in airplane mode. Try losing the connection during a save, closing and reopening the app before synchronization, and reconnecting after another device has changed the same record.

For each scenario, check both the stored data and the message on screen. The user should not have to understand the synchronization system to know whether their work is safe.

I’d also make offline scope explicit in the delivery brief. Name the supported actions and the recovery behavior, then use those examples as acceptance checks.

Good offline behavior is a collection of clear decisions. Start with the moment the person loses connectivity, and work backward from what they need to know and do next.

For more questions to settle before development, see planning a mobile MVP.