What should a mobile app do when the connection drops?

By Noe Guerrero III

A mobile app should preserve the work it can safely save, explain what hasn't reached the server, and give the user a clear way to finish later. Some actions can continue offline. Others need a live response before the app can honestly call them complete.

That distinction belongs in the project scope, before anyone approves the screens.

Imagine a service crew in the Rio Grande Valley using an app to record job notes and photos. A worker loses the connection halfway through an update. Should they keep typing? Can they close the app? Will the office see the update twice when the connection returns? These are planning questions for a hypothetical app, but the answers make a useful acceptance checklist for a real one.

Decide which actions can wait

Start with the tasks people actually need to finish. “Works offline” is too broad to serve as a requirement.

Android's offline-first architecture guidance distinguishes reading local data from writing changes, and describes different strategies for changes that require a connection or can be stored for later synchronization. Supporting offline reading doesn't automatically mean every action can happen offline.

For our example crew app, I'd start with this plan:

Those are proposed behaviors, not features every app already has. Agree on them with the developer, including what happens when the phone can't save another file. If local storage fails, the app must not display a reassuring “Saved” message.

Give “saved” a precise meaning

There are at least two places an update might exist: on the device and on the server. The office can't rely on a note that's still only on a worker's phone.

Use wording that tells people which state they're in. For example:

• Saved on this device — waiting to send. The app has preserved the work locally, but the team hasn't received it.

• Received by the server. The transfer completed; any separate approval or processing step still needs its own status.

• Needs your attention. Explain the obstacle and the next action, such as signing in again or correcting a rejected field.

Keep pending items easy to find after the user leaves the screen. A temporary popup isn't much help when someone checks the app an hour later.

For a web-based app, W3C's guidance on status messages explains how status changes should be available to assistive technology without requiring focus. Include that behavior in the review; a visible sync message alone doesn't tell you what a screen reader announces.

Make retries safe before adding a Retry button

A missing response doesn't prove that nothing happened. The server might accept a job note just before the connection fails, leaving the phone unsure of the result. Sending the same action again as a brand-new request could create a duplicate.

Ask the developer how the server recognizes another attempt at the same action. The technical term is idempotency: repeating an operation should not repeat its intended effect. A stable identifier for the original operation can help the server recognize a retry, provided the server actually implements that behavior.

Stripe's API documentation gives a concrete example of idempotency keys used to retry requests safely. That's an example of a server contract, not a feature that automatically transfers to your custom app. Your developer needs to define which actions support it and how long duplicate protection lasts.

For the crew app, a useful acceptance requirement is: repeated attempts to send one note produce one office record. Test a lost response as well as a complete outage. Disabling the button after one tap doesn't resolve a request whose outcome is unknown.

Decide what happens when two people change the same job

Suppose a worker edits a job description offline while the office changes that description online. When the phone reconnects, which version should remain?

There isn't one answer that fits every field. My preference for this example would be to keep separately added notes as separate entries, while flagging conflicting edits to an existing description for review. Replacing the whole job record without showing the conflict would make the result hard to trust.

Write that decision into the scope in plain language: preserve both versions, choose an agreed authority, or ask a person to resolve the difference. The developer can then select a synchronization design that supports the rule. Don't let a default setting quietly decide whose work disappears.

Also decide how people recognize older information. A downloaded job sheet should have a visible “last updated” time. If a particular decision requires current information, the app should explain why the saved copy isn't enough.

Test the return to a connection, too

An airplane-mode demo is a start. It doesn't show whether the office eventually gets the right result.

Use test accounts and disposable test records, then walk through this sequence on the devices your team will use:

1. Download a job while connected. Disconnect, reopen it, and check what remains available.

2. Add a note and photo. Close and reopen the app to check whether the promised local save survives.

3. Reconnect. Compare the phone's status with the record the office actually receives.

4. Have the developer simulate a lost server response and repeat the action. Check for duplicates.

5. Disconnect the first device again. Edit the same field there and on a connected second device, then reconnect the first. Verify the agreed conflict rule.

6. Test an expired sign-in and a failed upload. The app should explain the next step and handle saved work according to the agreed policy.

If the product runs in a browser, check its specific recovery behavior there. MDN currently lists the Background Synchronization API as having limited browser availability. Don't promise that every phone will send pending work after the browser closes. Define and test the fallback, such as reopening the app to resume a transfer.

Record the expected result beside the observed result. A screenshot of a success message isn't enough if the server has two notes or no photo.

Put the offline rules in the estimate

Before approving development, ask for the supported offline tasks, the meaning of each save status, the retry and conflict rules, and the devices included in testing. Include a policy for locally stored work when someone signs out or changes accounts. That gives the team something concrete to build and you something concrete to review.

You don't need every feature to work without a connection. You need the important tasks to behave predictably, and the app to be honest when it can't finish.

Our business app launch checklist covers the broader release review. If you're scoping a new internal tool or customer app, our software development services are a place to start that conversation.