Offline and sync

Phones lose signal. Basements, lifts, aeroplanes, rural roads, bad venues. If your app is used anywhere like that, say so when you describe it:

Drivers often lose signal, so it has to keep working offline

What you get

• Local storage on the device, so data the person already has stays readable
• A queue of changes made while offline, replayed automatically when the network returns

The queue is not a naive retry loop. It guarantees the things that matter:

• Changes replay in the order they were made. Out of order, a rename can land before the thing it renames exists
• Transient failures back off and retry instead of hammering
• Every request carries a key that makes a repeat safe, so a change sent during a flaky connection cannot be applied twice
• A change the server genuinely rejects is set aside rather than retried forever, so one bad change cannot block everything behind it

Show people what is happening

An app that silently queues changes looks identical to one that saved them. That is how people lose work: they close the app believing it saved.

Ask for the state to be visible:

Show "syncing 3 changes" while there are unsent changes

Saved-on-this-phone and saved-for-real are different states, and people need to be able to tell them apart.

The rule you have to decide

When two people edit the same thing offline, the last change the server receives wins. The earlier one is overwritten.

For most apps that is fine, because two people rarely edit the same record at the same minute. For some apps it is not: shared checklists, inventory counts, collaborative notes.

If it matters for your app, decide the behaviour and say so:

Two drivers can't both mark the same stop delivered. The second one
should see that it's already done.

Left unstated, you get last-write-wins.

Testing offline

The only real test is a real one:

1. Open the app on a phone with data loaded
2. Turn on airplane mode
3. Use the app. Create something, edit something, delete something
4. Confirm what you see makes sense, no spinners forever, no fake success
5. Turn the network back on
6. Confirm the changes land, once each

Step 6 is the one people skip and the one that catches duplicates.

Limits

• Offline covers your app's own data, not files being uploaded mid-flight
• The first load needs a network. A brand-new install cannot start offline
• Very large local datasets are not the target. This is for an app's working set, not a full mirror of your database