Clients frequently ask whether offline support can be added to an existing mobile application. It can, but the cost is usually closer to a rewrite than to a feature, because offline capability is a property of the data model rather than a layer on top of it.
The assumption that gets baked in
A connected application treats the server as the source of truth and the device as a view. Every action is a request; the result of that request is the new state. This assumption spreads through the codebase silently: identifiers come from the server, validation happens server-side, sequences depend on server ordering.
An offline-capable application treats the device as a source of truth that reconciles later. That is a different model, and the difference shows up in almost every layer.
Identifiers must be generated locally
If the server assigns identifiers, a record created offline has no identity until it syncs, and anything referencing it cannot be created either. Client-generated identifiers, typically UUIDs, remove the dependency entirely. Retrofitting this means changing every foreign key and every reference in the application.
Conflicts need a defined policy per entity
Two devices edit the same record while offline. Something must decide the outcome, and the right answer differs by entity. Scheduling data set by the office should be server-authoritative. Work recorded by the engineer on site should be client-authoritative. Genuine conflicts on financial data should go to a human review queue rather than being resolved automatically.
There is no general-purpose answer, which is why this cannot be delegated to a sync library without thought.
Validation happens twice
Offline actions must be validated on the device, since the server is not reachable. They are validated again on sync, since the device cannot be trusted and the world may have changed. Both paths must reach the same conclusion, or users will complete work that is silently rejected hours later.
Sync must be resumable
Devices reconnect briefly and disconnect again mid-transfer. Sync needs to be chunked, resumable and idempotent, so a partial upload followed by a retry does not duplicate anything.
Decide at the start
If there is any realistic prospect the application will need to work without a connection, design for it from the first sprint. The cost at that point is modest. The cost later is most of the application.