Mobile resilience guide
Building mobile apps for unreliable connectivity
Design for slow, intermittent and misleading network conditions, not only a simple online or offline switch. Preserve user intent, bound every wait and make uncertain outcomes visible.
The short answer
A mobile app handles unreliable connectivity by separating local intent from remote confirmation. It stores important permitted work before delivery, attempts communication with explicit timeouts, classifies failures, retries only suitable operations and shows the user whether the business has actually accepted the action.
Do not rely on a connectivity icon to decide whether work is safe. A device can be attached to Wi-Fi without reaching the internet, or a request can reach the server before the response is lost. Design each important journey so it remains recoverable in that uncertain middle.
01
Unreliable connectivity has more than two states
| Condition | What the app may observe | Design response |
|---|---|---|
| No network | No suitable transport is available | Keep allowed work locally and explain what remains unavailable |
| Captive network | Wi-Fi exists but internet access needs sign-in | Avoid claiming the service is reachable |
| Slow or lossy link | Requests exceed normal expectations or disconnect | Use bounded waits, resumable work and honest progress |
| Metered network | Connectivity exists but large transfers may be costly | Defer optional media and let policy or the user decide |
| Service unavailable | The internet works but the required API does not | Classify the service response and retry only when appropriate |
| Unknown outcome | The request left the device but no reliable response returned | Query or retry by a stable operation identifier |
Android's network guidance distinguishes network availability and capabilities, including metered and captive states. Those signals help the interface and scheduler, but the business service still decides whether an action succeeds.
02
Write a resilience contract for each critical journey
- Name the information that remains useful locally and how its freshness is shown.
- Decide which actions can be saved without immediate server validation.
- Define the point at which the user can safely leave the screen or close the app.
- Separate local save, delivery attempt and server confirmation.
- Set the retry, expiry, conflict and escalation rule.
- Define what happens after sign-out, token expiry, device loss or a long offline period.
- Choose the operational signal that proves the journey is healthy.
The broader offline-first product guide helps decide which journeys belong in this contract. This guide focuses on how the journey behaves across changing connection quality.
03
Make delivery safe when the outcome is unknown
- persist the minimum operation before scheduling delivery;
- reuse the same operation ID for retries of the same business action;
- use request and response timeouts suited to the journey;
- apply bounded exponential backoff with jitter for temporary failure;
- make the server idempotent for actions that may be repeated;
- stop retrying permanent validation, permission and business-rule failures; and
- store the confirmed server result back into local state.
For detailed identifiers, versions and outbox behaviour, use the offline mobile synchronisation guide.
04
Translate technical uncertainty into useful product language
Saved
On this device
The user's work is durable locally but has not reached the business.
Pending
Waiting to send
Delivery will be attempted when conditions and policy allow.
Confirmed
Accepted remotely
The service returned or later reported an authoritative outcome.
Attention
Needs a decision
Input, permission, conflict or expiry prevents automatic completion.
Keep navigation and existing work responsive while background delivery happens. For large uploads, show per-file state, preserve completed parts where the protocol supports it and let the user understand whether leaving the screen is safe.
05
Respect mobile lifecycle and background limits
Android recommends WorkManager for persistent work that should run after its constraints are met. Connectivity callbacks can update current application state, but they should not become an in-memory job queue. Apple provides background-task APIs for scheduled refresh and maintenance, while the system decides when execution opportunities are available.
- store work durably before asking a platform scheduler to run it;
- assume the operating system can suspend or terminate the process;
- resume from stored state rather than from a timer or screen callback;
- constrain large optional work to suitable network and power conditions;
- make foreground recovery work even if background scheduling is delayed; and
- test behaviour after upgrade and local-schema migration.
06
Test transitions, not only airplane mode
- start online, lose connectivity during a request and reconnect through another transport;
- accept an operation on the server but drop the response;
- move through slow, captive, metered and restricted networks;
- terminate and restart the process with pending and partially transferred work;
- expire identity or revoke permission while an action waits;
- deliver duplicate and out-of-order responses;
- keep the device offline beyond record freshness and retention limits; and
- recover a terminal failure without losing the original evidence.
Measure pending age, retry count, confirmation delay, terminal failures and unresolved conflicts. A connectivity metric alone does not show whether users completed their work.
07
Prepare a connectivity brief before implementation
Record the user environment, representative devices, expected transports, critical journeys, local data, freshness rules, permitted offline actions, server validations, operation identifiers, timeout policy, retry classes, conflict rules, large-file behaviour, background expectations, security controls, telemetry and support owner.
Pair the brief with the mobile business-system integration boundary so resilience behaviour is owned from the device through to the systems of record.
Sources
Primary references
Questions
Frequently asked questions
How should a mobile app handle unreliable connectivity?
A mobile app should treat connectivity as changing evidence rather than a guarantee. Preserve important user work locally, use bounded timeouts and retries, make delivery states visible and reconcile every uncertain server outcome safely.
Is a connected status enough to send a request?
No. A device may have a network without usable internet or may be behind a captive portal, on a slow link or unable to reach the service. The request and its response remain the authoritative evidence.
Should every failed request retry automatically?
No. Retry temporary transport and service failures with limits and backoff. Stop for invalid input, lost permission, expired business state or a conflict that requires a new decision.
What should users see when a mobile action is pending?
Show whether the action is saved on the device, waiting to send, being delivered, confirmed, failed or needs review. Do not describe a locally saved action as completed by the business.
How do you test an app for poor connectivity?
Test slow, intermittent, metered and captive networks, process termination, device restart, duplicate delivery, timeouts after server acceptance and long offline periods on representative devices.
Plan for real network conditions
Bring the critical journey, user environment, server action and consequence of delayed delivery.
LCR can define the resilience contract and build the smallest end-to-end slice that proves it.