Software built on the assumption of reliable connectivity fails quietly in most of the places it gets deployed. A shop where the line drops for an hour. A field with one bar. A clinic whose router restarts twice a day.
Retry logic is not offline support
Wrapping requests in a retry does not make an application usable offline. It makes it hang. Genuine offline capability means the application writes locally first and treats the server as something it reconciles with later.
- A local store that is the application's source of truth while disconnected
- A queue of pending writes that survives the app being closed
- Conflict resolution decided in advance, per data type
- Interface states that tell the user what is synced and what is not
Conflicts are a product decision
When two people edit the same record offline, something has to give. Last-write-wins is fine for a draft and unacceptable for a stock count. That is not a technical detail to settle in code review — it is a question for whoever owns the process.
Test it by pulling the cable
Throttled network profiles in a browser are a weak proxy. We test on real devices with the connection genuinely cut, mid-transaction, and again while a sync is in flight. That is where the defects are.