Offline-first
An offline-first app is designed on the assumption that the connection may be missing. It keeps a local copy of the data it needs, reads and writes that copy, and queues changes to send to a server when it can. The person using it is not blocked by the network.
The server, though, stays in charge. It holds the authoritative copy, applies the business rules, and can reject a change that was made offline. The local copy is a well-managed cache plus a list of pending work. Most offline-capable business apps work this way: field service, inspections, delivery, and point-of-sale apps that must keep working through an outage and report back afterwards.
Local-first
Local-first is a stronger idea. The term comes from a 2019 essay by Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan at the research lab Ink and Switch, titled Local-first software: You own your data, in spite of the cloud. It sets out seven ideals:
- No spinners: your work at your fingertips.
- Your work is not trapped on one device.
- The network is optional.
- Seamless collaboration with your colleagues.
- The Long Now.
- Security and privacy by default.
- You retain ultimate ownership and control.
In a local-first app, the copies on people’s devices are the primary data. Devices sync with each other, directly or through a server, but a server is a helper, not the owner. If the company behind the app shut its servers down, the data and the app would still work.
The essay points to conflict-free replicated data types (CRDTs) as a promising foundation for these ideals. CRDTs, formalised by Shapiro, Preguiça, Baquero, and Zawirski in 2011, are data structures that let copies edited independently merge into the same result without a central coordinator.
Side by side
| Offline-first | Local-first | |
|---|---|---|
| Source of truth | The server | The data on people’s devices |
| Role of the server | Owner of the data and its rules | Optional helper for relay, backup, or sign-in |
| Offline edits | Queued and confirmed or rejected later | Final on the device, merged with other copies |
| Conflicts | Usually settled by the server | Usually merged automatically, often with CRDTs |
| If the server goes away for good | The app stops working fully | The app and its data keep working |
| Common fit | Business apps with a system of record | Personal and collaborative tools, documents, notes |
Where they overlap
In practice the line is blurry. Both keep a local copy, both sync, and both need a plan for edits that happened apart. Many systems are offline-first for some data and local-first for other data. A delivery app might treat orders as offline-first, because the backend decides what was delivered and billed, while treating a shared checklist on the vehicle as local-first, because the crew needs it to merge cleanly whatever the connection does.
How to choose
Ask where the final decision has to be made.
- If a central system must approve or reject each change, such as an order, a payment, or a booking, design offline-first. Let people work locally, but keep the server as the judge and show what is still pending.
- If people own the data and need to work on it together across devices, such as notes, drafts, plans, or checklists, local-first gives a better result. Edits merge instead of waiting for permission.
Device-to-device sync fits both. It matters most when several people are offline together and need the same current state before anyone can reach a server.