Connectivity assumptions written in an office in a city are not true in a depot, a basement warehouse, or on a road between two towns. If your users work in those places, offline is the normal state and online is the exception.
Decide the conflict rules with the client
The technical part of offline sync is well understood. The part that goes wrong is deciding what happens when two people edited the same record while both were offline.
That is not an engineering decision. It is a business rule, and the client has an opinion once you ask in concrete terms: "the driver recorded 142,300 km at 08:14, dispatch recorded 142,000 km at 08:20 — which one is the truth?"
Make the queue visible
Users trust an offline app when they can see the queue. A small, honest indicator showing what has not yet synced, and a way to retry, removes almost all of the support load.
- Show pending items, with timestamps
- Never silently drop a failed write
- Make retry manual as well as automatic
- Timestamp on the device, reconcile on the server
Test with the network off
It sounds obvious. Most teams test offline behaviour by toggling airplane mode once, at the end. We put an offline pass into the definition of done for every sprint that touches data entry.