Offline mode bugs every mobile tester should check

"Test offline mode" usually gets reduced to "turn on airplane mode, see if it shows an error." That misses where the real bugs live. Offline is rarely a clean state on mobile — it's a constant flicker: a lift, a tunnel, a train, a switch from wifi to cellular mid-request. The bugs hide in the transitions between connected and not, and in what the app does with the actions you took while it was down. This expands the network items from my mobile smoke test and the assumptions behind why mobile bugs escape web-first teams.

1. The honest offline state

Start with the basics, done properly. Go offline and use the app:

• Is there a clear offline indication, or an infinite spinner and a cryptic failure?
• Does cached content still display, or does the whole screen blank out?
• Are actions that need the network disabled with an explanation, or do they fail silently after you tap?

An app that simply hangs when offline is failing the most common real-world condition.

2. The reconnect — where the bugs actually are

This is the high-value part. Do something offline, then come back online:

• Queued actions: if you "sent" a message or "saved" a record offline, does it sync exactly once on reconnect — or double-submit, or get lost entirely? Double-submission on reconnect is the classic offline bug.
• In-flight requests: a request fired just as the network dropped — does it fail cleanly and retry, or leave the UI in a half-done state (spinner forever, optimistic update that never confirmed)?
• Optimistic UI: apps often show an action as done immediately. If the sync later fails, does the UI roll back and tell the user, or keep showing a success that never actually happened?

3. The wifi ↔ cellular switch

Not the same as fully offline — and often buggier. Walk out of wifi range mid-action so the device hands off to cellular:

• Does an in-flight upload/download survive the switch or silently die?
• Does the app re-authenticate or drop the session on network change?
• On metered cellular, does it respect "wifi-only" settings (big downloads, auto-sync) or blow through the user's data?

4. Conflict and staleness

• Edit conflicts: edit a record offline while it's also changed server-side, then sync. Last-write-wins silently overwriting someone else's change is a data-loss bug.
• Stale reads: how old is the cached data, and does the app indicate it's stale or pretend it's live?
• Auth expiry offline: the session expires while offline — on reconnect, does the app re-auth gracefully or dump the user with lost work?

5. Storage and recovery

• Kill while offline: force-quit the app with unsynced offline actions pending, relaunch (still offline), then reconnect — do the queued actions survive, or vanish?
• Storage limits: offline caches that grow unbounded, or fail ungracefully when the device is low on space.

Where this fits

Offline behaviour is a mobile-specific risk that web testing never trains you for. This is the focused pass; my mobile smoke test covers it alongside lifecycle, permissions, and the upgrade path, and why mobile bugs escape web-first QA teams explains the assumptions behind it. The common bugs library catalogues the data and sync defects.

Offline pass

• Clear offline indication; cached content shows; network actions disabled with a reason (no silent fail)
• Queued offline actions sync exactly once on reconnect — no double-submit, no loss
• In-flight requests at the moment of disconnect fail cleanly and recover
• Optimistic UI rolls back and informs the user when a later sync fails
• Wifi↔cellular handoff survives in-flight work; "wifi-only" settings respected
• Offline edit conflicts don't silently overwrite; stale data is indicated
• Force-quit while offline with pending actions, relaunch, reconnect — actions survive