UX Patterns Guide
UI + UX Cross-Device And Physical Interaction standard

Offline mobile retry

Provide an offline mobile retry surface that persists the original action locally, exposes queue and attempt status, retries automatically only when allowed, offers manual retry and cancel controls, guards duplicate side effects with stable request identity, and hands off to sign-in, conflict review, fallback, or support when retry can no longer proceed safely.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A mobile user action can be saved locally and retried after network or app lifecycle conditions improve.
  • Users need to leave the screen, background the app, or move through unreliable connectivity without losing work.
  • The action may create side effects and therefore needs duplicate-submit prevention and stable request identity.
  • Retry timing depends on mobile constraints such as Wi-Fi, metered data, battery, OS background support, or foreground return.

Avoid when

  • The app cannot persist the action locally or safely identify whether the first attempt reached the server.
  • The failure is a validation, permission, policy, or conflict issue that needs correction before retry.
  • The task is read-only cached content and a broad offline state is enough.
  • The operation is a simple in-place failed request with no mobile offline, background, queue, or lifecycle constraint.
  • Automatic retry would be unsafe, privacy-sensitive, payment-related, or destructive without explicit review.

Problem it prevents

Mobile users often lose connectivity, background the app, switch networks, enter captive portals, hit metered or low-battery constraints, or attach large files while trying to save, send, upload, submit, or check in, and they need to know whether the action is queued, retrying, safe to retry, blocked, or already accepted.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Offline mobile retry in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The action originates from a phone, tablet, PWA, mobile webview, or native shell where connectivity, app lifecycle, OS background limits, battery, and metered data can change mid-task.

Pattern promise

Provide an offline mobile retry surface that persists the original action locally, exposes queue and attempt status, retries automatically only when allowed, offers manual retry and cancel controls, guards duplicate side effects with stable request identity, and hands off to sign-in, conflict review, fallback, or support when retry can no longer proceed safely.

Required state

Online successful action state.

Recovery path

Queued mobile work disappears after the app is backgrounded or restarted.

Access contract

Use visible text and accessible names for queued, local, retrying, paused, failed, sign-in required, and sent states; do not rely on icons alone.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A mobile inspection form says Saved on this device, 2 photos queued, last attempt 10:42, next retry on Wi-Fi, Retry now, and request ID MOB-1842.
  • A failed offline message stays in an outbox row with Waiting for connection, manual Send now, cancel, and background retry paused by low battery.
  • A user submits a field report in a basement, sees it queued locally with photos and an idempotency reference, closes the app, and later sees background retry complete after reconnect.
  • A user regains network through a captive portal and the retry queue explains Sign in to network before retrying rather than looping silently.
Weak implementation

Vague, hidden, hard to recover from

  • A phone shows Sent while in airplane mode and gives no queue, request ID, or local-save explanation.
  • Retry keeps firing every few seconds on a metered connection with no pause or Wi-Fi-only choice.
  • The user repeatedly taps Submit because the app hides the offline queue and creates duplicate reports after reconnect.
  • The app clears a queued upload after OS background sync is unavailable instead of keeping it for foreground retry.
UI guidance
  • Render a mobile retry surface that names the queued action, local storage location, last attempt, next retry trigger, manual retry control, background retry eligibility, and duplicate-submit guard instead of using only a global offline banner.
  • Show mobile-specific constraints such as app backgrounded, OS background sync unavailable, Wi-Fi-only upload, metered data pause, low battery pause, captive portal, expired sign-in, attachment retry, and server conflict as distinct retry states.
UX guidance
  • Use offline mobile retry when users need confidence that a mobile save, send, upload, submit, check-in, or payment attempt is preserved locally and will retry safely when connection and policy conditions allow.
  • Keep queued work visible and recoverable until it succeeds, fails with a reason, is cancelled, expires, needs reauthentication, enters conflict review, or moves to a fallback path; never make users guess whether tapping again creates a duplicate.
Implementation contract

What the implementation must handle

States

  • Online successful action state.
  • No connection at submit state with local queue confirmation.
  • Queued mobile action state with request ID, timestamp, and stored payload summary.
  • Manual retry-ready state that preserves the original action and disables duplicate submit.

Interaction

  • The UI never reports server success for a mobile action that is only saved locally or queued.
  • Retry repeats the preserved queued action rather than creating a new submission unless users explicitly duplicate or edit it.
  • A pending queued action suppresses duplicate Submit, Send, Upload, Pay, Check in, or Approve controls for the same scope.
  • Automatic background retry respects OS support, connectivity, battery, metered-data, authentication, idempotency, and retry-limit constraints.

Accessibility

  • Use visible text and accessible names for queued, local, retrying, paused, failed, sign-in required, and sent states; do not rely on icons alone.
  • Expose queue state changes through polite status messages when they affect the current task.
  • Keep Retry now, Cancel queued action, Edit before retry, Sign in, Send on Wi-Fi, and Export local copy controls reachable by keyboard and switch control.
  • Do not move focus unexpectedly when background retry updates; move focus only after user-initiated retry or when a persistent recovery region appears.

Review

  • What exact mobile action is queued, and where is it saved until retry?
  • What proves the server accepted the action, and what visible state exists before that proof?
  • What prevents duplicate records, messages, payments, uploads, approvals, or check-ins if users tap again?
  • Will retry happen in the background, only in foreground, only on Wi-Fi, or only after sign-in or user action?
Evidence trail

Source-backed claims behind this guidance

Workbox Background Sync

Chrome for Developers - checked

Supports queued failed requests, later replay, retry timing, fallback replay, and retention limits.

Full agent/debug reference

Problem Context

  • The action originates from a phone, tablet, PWA, mobile webview, or native shell where connectivity, app lifecycle, OS background limits, battery, and metered data can change mid-task.
  • Users may attach photos, scan codes, send messages, submit forms, save field records, check in, approve work, invite people, or perform payments while offline or intermittently connected.
  • The app can store local payloads, queue requests, identify retryable failures, and distinguish foreground retry from background replay.
  • Offline mobile retry sits near offline state, retry, sync state, pull to refresh, fallback path, error state, loading spinner, progress bar, draft state, and conflict resolution.

Selection Rules

  • Choose offline mobile retry when a mobile action should be preserved and retried after connection loss, flaky network, app backgrounding, or policy-limited connectivity.
  • Show whether the action is saved locally, queued, waiting for connection, retrying in foreground, eligible for background retry, paused, failed, expired, or accepted remotely.
  • Keep the original request identity, object, attachment list, timestamp, retry count, and idempotency reference visible or recoverable for side-effecting actions.
  • Offer manual Retry now when users need control, but disable duplicate submit while the same queued action is pending or retrying.
  • Pause or explain retry when the network is metered, battery saver is active, Wi-Fi-only upload is required, captive portal blocks requests, account sign-in expired, or OS background sync is unavailable.
  • Use offline state when the main question is what works while disconnected, not one queued mobile action's retry lifecycle.
  • Use retry when a single failed operation is retryable without mobile offline, background, or queue constraints.
  • Use sync state when several local and remote copies are reconciling and users need accepted, partial, failed, paused, or conflict status across a queue.
  • Use pull to refresh for user-requested content refresh, not for hidden retry of pending submissions.
  • Use fallback path when retry is exhausted, unsafe, non-retryable, or requires another channel such as export, manual entry, call support, or later return.

Required States

  • Online successful action state.
  • No connection at submit state with local queue confirmation.
  • Queued mobile action state with request ID, timestamp, and stored payload summary.
  • Manual retry-ready state that preserves the original action and disables duplicate submit.
  • Retry pending state with attempt count and duplicate guard.
  • Background retry eligible and background retry unavailable states.
  • App backgrounded or returned-to-foreground state with queue still visible.
  • Metered data, Wi-Fi-only, low battery, and battery saver paused states.
  • Captive portal or server unreachable state distinct from device offline.
  • Sign-in expired or permission changed state that routes to recovery before retry.
  • Attachment upload failed, partial upload, and retry attachment states.
  • Retry succeeded, failed again, retry exhausted, cancelled, expired, and conflict-needs-review states.

Interaction Contract

  • The UI never reports server success for a mobile action that is only saved locally or queued.
  • Retry repeats the preserved queued action rather than creating a new submission unless users explicitly duplicate or edit it.
  • A pending queued action suppresses duplicate Submit, Send, Upload, Pay, Check in, or Approve controls for the same scope.
  • Automatic background retry respects OS support, connectivity, battery, metered-data, authentication, idempotency, and retry-limit constraints.
  • Manual retry reports pending, succeeded, failed again, paused, sign-in required, conflict, exhausted, or fallback outcome.
  • Queued work remains visible after app restart, background return, network change, and page refresh until users resolve or cancel it.
  • Side-effecting operations expose enough identity for deduplication, support, and user trust without leaking sensitive payload details.

Implementation Checklist

  • Classify mobile actions by retry safety, side effects, idempotency needs, attachment size, credential requirements, and allowed network conditions.
  • Persist queued payloads in native storage, IndexedDB, Cache API, service-worker queue, upload manager, or another durable local store with stable IDs.
  • Store request ID, retry count, last attempt, next retry time, backoff rule, payload summary, attachment status, and user-visible object name.
  • Distinguish device offline, server unreachable, captive portal, timeout, sign-in expired, validation failure, conflict, and policy pause.
  • Use background sync or native background transfer only when the UI can show eligibility, retention, retry limits, and foreground fallback.
  • Disable duplicate submit while a matching queued action exists, and provide cancel, edit, export, retry now, retry on Wi-Fi, and fallback actions as appropriate.
  • Announce meaningful queue transitions such as queued, retrying, sent, failed, paused, sign-in required, and conflict needs review.
  • Test airplane mode, tunnel or basement loss, flaky connection, captive portal, low battery, metered data, app kill/restart, background return, duplicate tap, attachment failure, auth expiry, and server conflict.

Common Generated-UI Mistakes

  • Showing a success toast for an offline submission that is only queued.
  • Hiding the queue after users leave the screen or background the app.
  • Letting Submit create a second request while a matching queued request is pending.
  • Retrying every few seconds on unstable mobile networks with no backoff or pause.
  • Treating captive portal, expired auth, validation failure, and offline as the same retryable state.
  • Uploading large attachments on metered data without user control.
  • Clearing attachments after a background retry fails.
  • Using pull to refresh as the only way to recover queued saves or uploads.

Critique Questions

  • What exact mobile action is queued, and where is it saved until retry?
  • What proves the server accepted the action, and what visible state exists before that proof?
  • What prevents duplicate records, messages, payments, uploads, approvals, or check-ins if users tap again?
  • Will retry happen in the background, only in foreground, only on Wi-Fi, or only after sign-in or user action?
  • How are metered data, low battery, captive portal, auth expiry, partial attachments, and conflicts represented?
  • What is the fallback when retry is exhausted, unsafe, expired, or unsupported by the OS?
Accessibility
  • Use visible text and accessible names for queued, local, retrying, paused, failed, sign-in required, and sent states; do not rely on icons alone.
  • Expose queue state changes through polite status messages when they affect the current task.
  • Keep Retry now, Cancel queued action, Edit before retry, Sign in, Send on Wi-Fi, and Export local copy controls reachable by keyboard and switch control.
  • Do not move focus unexpectedly when background retry updates; move focus only after user-initiated retry or when a persistent recovery region appears.
  • Associate paused and failed retry messages with the exact queued item and action.
  • Make retry timing, last attempt, and server-accepted versus local-only state available to screen readers.
Keyboard Behavior
  • Focus remains stable when connectivity changes or background retry starts.
  • Tab reaches the queued item summary, retry action, cancel action, fallback action, and detail disclosure in logical order.
  • Enter or Space activates Retry now once, then the pending state suppresses repeated activation.
  • If retry requires sign-in, focus moves to the sign-in recovery flow and returns to the queued item after authentication.
  • When a queued item succeeds after user-initiated retry, focus lands on a persistent success or sent status; background success uses a polite status update.
  • If the app adapts between mobile and desktop views, focus stays with the same queued item or its equivalent list row.
Variants
  • Mobile outbox retry
  • Queued form submission
  • Queued photo upload
  • Foreground retry
  • Background sync retry
  • Retry on Wi-Fi
  • Metered data paused retry
  • Battery-saver paused retry
  • Captive portal blocked retry
  • Sign-in-required retry
  • Idempotent payment retry
  • Conflict after retry

Verification

Source trail checked:

Saved items