Designing for the connection you actually have

Most mobile applications are written as though the network is a given and its absence is an error state. On this continent that assumption is backwards: connectivity is the exception, and the application should treat a live connection as a bonus rather than a precondition.

The practical consequence is that the local database becomes the source of truth for the session. A user's action writes locally and returns immediately. Synchronisation is a separate, asynchronous concern that reconciles with the server whenever it can, and which must be able to fail repeatedly without the user noticing.

That reframing forces three design decisions early. First, every record needs an identity the client can generate, because you cannot wait for a server to assign one. Second, you need an explicit conflict policy — last-write-wins is a decision, not a default. Third, the sync queue itself needs to be durable and inspectable, because when something does go wrong in the field you will be debugging from a log, not a debugger.

None of this is exotic. It is simply what happens when you take the operating conditions seriously at design time instead of patching around them at the end.