Question 5
Offline support and syncing
How would you design a system that works offline and syncs with a backend when connectivity returns?
Follow-ups
- How do you handle conflicts when two devices edit the same record?
Answer outline
Treat local state as authoritative for the UI while offline: reads come from DB/cache; writes go to an outbox (queue of operations with payloads and client-generated IDs.
On connectivity or equivalent), drain the outbox with retries and ordering guarantees per entity.
A real world example of this is when using CloudKit to store audio files as CKAssets, referenced from Swift Data. Uploads may fail and require retries when connectivity returns.
Conflict strategy must match product: last-write-wins, server wins, merge fields, or user picks.
Version fields etag(entity tags), updatedAt help detect conflicts.
Principles
- Optimistic UI only where rollback is acceptable; otherwise show pending.
- Idempotent server APIs simplify retries: if the connection drops after the server handled the request but before your client gets a response, you can replay safely without double side effects.
- Client request IDs (one stable ID per logical operation, reused across transport retries of that same operation) let the server detect duplicates and return the same outcome instead of applying the mutation twice.
- Scope offline — not every feature must sync.