Travel Apps Offline: Keep Disruption Details Useful
When a journey changes and connectivity disappears, a travel app should distinguish saved plans from current service status. Here is a practical design checklist.
A travel app can lose its most important capability at exactly the wrong moment: a traveller needs to check a route, but the phone has no connection. Reports that Corsica Linea crossings remained suspended during a strike, covered by Corse Matin, are a timely reminder that service information can matter beyond the moment it is first published. They do not tell us what any specific app displayed, and this is not a recap of the dispute. The product question is durable: what should an app show when disruption information may have changed, but fresh data cannot be reached? The answer starts by separating useful saved details from claims of current status.
Separate the saved itinerary from live service status
Design the offline screen around two different user needs. The first is a stable reference: the traveller’s saved route, booking or crossing details, departure location, planned time, and any instructions the service provider has made available for offline use. The second is changing information: whether a departure is operating, delayed, cancelled or under review. Cache both where appropriate, but never present them as equally current. A stored itinerary can still help someone orient themselves; a stored operating status may be obsolete. Give each item its own status and timestamp, so users do not have to infer freshness from a single screen-level “offline” label.
A useful status model distinguishes at least three conditions: confirmed current information, previously retrieved information, and no information available. When the app cannot verify a cached service update, label it as saved or last retrieved, show when it was received, and state plainly that it may have changed. If no status was cached, say so instead of substituting an assumed “on time” state. Keep the planned journey visible, but visually separate it from service confirmation. A concise explanation such as “Last checked at 09:10; unable to refresh” is more honest than a green status badge that could be mistaken for a live assurance.
- For every cached status, define the source, last-updated time, validity rules and offline wording.
- Keep itinerary facts and operational status in separate fields and visual components.
Choose what to cache and how to show its age
Cache the minimum information that helps a traveller make sense of the planned journey: route legs, stop or terminal names, scheduled times with time-zone context, booking references if the product is authorised to store them, and relevant service instructions. Decide explicitly whether details are available offline by default, how long they remain on the device, and how a user can remove them. These choices affect storage, privacy, and delivery scope. They also prevent a common product mistake: treating “offline support” as a single feature when it is a set of content, data-retention and interface decisions.
Freshness should be visible at the level where it matters. An overall banner can explain that the device is offline, but each time-sensitive service item should retain its own retrieval time. Do not reset that time merely because the app reopened or copied cached data into a new screen. If the service feed supplies a publication time or revision identifier, preserve it separately from the time the app received it; if it does not, avoid implying that the app knows when the underlying event occurred. Consider a neutral age label and a clear warning once an agreed threshold is exceeded. The threshold is a product rule to validate with operations, not a universal constant.
- Define cache expiry by data type: a saved route and a departure status do not have the same useful lifetime.
- Include accessible text labels; do not rely on colour or a connectivity icon alone.
Make retry behaviour predictable, not reassuring
When a connection returns, retry status refreshes without making the traveller guess whether anything happened. Show a refresh action when appropriate, indicate that a request is in progress, and retain the last known information until a response arrives. If the request fails, keep the timestamp and explain that the app could not verify a newer update. A completed request is not proof that the service itself is operating; only an authoritative response can support that status. Avoid rapid repeated requests on weak networks, and ensure repeated attempts do not create duplicate bookings, payments or other actions. Status refresh and transactional actions need different safeguards.
A simple implementation contract helps product, mobile and backend teams agree on behaviour before development. Define which service is authoritative, what counts as a successful refresh, how errors are represented, and whether a newer response can replace an earlier one. Include tests for airplane mode, intermittent connectivity, expired cached data, device time changes and a service update arriving between screen visits. For a hypothetical ferry journey, the app could keep a previously saved departure and booking reference visible while marking an older crossing status “not verified offline.” After reconnection, it would replace that status only after receiving a valid response and recording its source and retrieval time.
- Test the offline, refresh-in-progress, refresh-failed and verified-update states as separate outcomes.
- Agree on source priority, timestamp semantics and retry limits before estimating implementation effort.
For a disrupted journey, offline usefulness is not the same as pretending to be live. Preserve the traveller’s saved plan, identify which operational details are cached, show their age, and make the limits of verification unmistakable. Then define refresh rules and test how the app behaves when connectivity drops, returns or remains unreliable. This gives product and engineering teams a bounded scope for an offline travel experience—and gives travellers information they can interpret without mistaking yesterday’s status for today’s confirmation.