Offline-First Architecture
Treating the local device store as the primary source the application reads and writes, with the network as an asynchronous replication channel.
Offline-first inverts the usual assumption. The application never waits on the network to render or to accept input; it reads and writes locally, and synchronisation happens in the background. The network becomes an optimisation rather than a dependency.
The benefit extends well beyond aeroplanes and tunnels. An application built this way is instantaneous on a good connection too, because no interaction blocks on a round trip, and it is resilient to the far more common case of a flaky connection rather than an absent one.
The costs are real and land in specific places. Every write becomes a candidate conflict, so the system needs a resolution strategy rather than hoping. The local store becomes a data protection concern — personal data now sits on thousands of devices, subject to loss, theft and erasure requests. Schema migration must handle a device that was offline across three application versions. And debugging is harder, because the state that produced a bug lives on a device you cannot inspect.
The design question that decides feasibility: can the domain tolerate a user acting on stale data? For notes, tasks and field data capture, easily. For inventory allocation or seat booking, not without a reservation model, and pretending otherwise produces the double-booking class of defect.