What is offline-first architecture and why does your app need it?
Your app shouldn't stop working because the user entered the subway. What offline-first is, how it syncs and when it pays off, with two real cases.
Offline-first architecture is a way of designing apps where everything works on the device first: data is stored on the phone and synced with the server whenever there is a connection. For the user, the app never gets stuck "loading": it opens, responds and saves even on the subway, on a plane or out in the countryside.
It is the opposite of the traditional approach, where every action travels to the server and, without signal, the app freezes or loses what you entered. I use it in my apps, like Sudoku Play, and in the EQUIBOX quoting tool. Here is how it works, when it pays off and what I learned building it.
What is offline-first architecture?
In an offline-first app, the immediate source of data is the device: what the user sees and enters is read and written there, instantly. The server still exists, but plays a different role: it is where everything ends up consolidated, backed up and shared with other devices.
The key is that syncing becomes a background process. The user does not wait for the server to keep using the app: they keep going, and the app catches up on its own when it can.
Online-first vs offline-first in practice
| Online-first (traditional) | Offline-first | |
|---|---|---|
| No signal | The app freezes or shows an error | The app works normally |
| Speed | Every action waits for the server | Instant response: reads and writes on the device |
| Data entered offline | Lost, or has to be entered again | Saved and synced automatically |
| Development complexity | Lower | Higher: syncing has to be designed |
| Best for | Information that must always be live | Daily-use apps, field work, areas with poor signal |
How does syncing work?
Instead of sending each action to the server in real time, the app records every action as an immutable "event" with a unique ID (UUID). These events are stored locally in a queue. When there is internet, the queue is sent to the server in batches. The server processes the events in order and returns the updated state.
If an event was already processed (same ID), the server ignores it. This guarantees idempotency: no matter how many times the same event is retried, the result is the same. This pattern is known as event sourcing.
Where does the state live while you use the app?
In Sudoku Play, during a game the full state lives in memory (a Zustand store): zero disk or network operations while you play, which keeps the app smooth. Autosave runs every few seconds, at moments when it does not block the screen. When you close the app, the state is saved to the phone's storage (AsyncStorage) and restored from there when you open it again.
When is it worth syncing?
Syncing right away is not always the best idea. My implementation checks whether there is WiFi or mobile data, the battery level (no sync in power-saving mode), the number of pending events and the time since the last sync (so it doesn't sync constantly).
If a sync fails, it retries with increasingly longer waits. After a few failed attempts, it waits until the user opens the app again.
How are conflicts resolved?
In my case, the server always wins. When it receives events, it processes them in chronological order and computes the final state, which is sent back to the device to replace its local state. It works because events are immutable and carry a timestamp plus a unique ID: even if the user played on two devices offline, when both sync the server reconciles the events chronologically and the result is consistent.
When does an app need to be offline-first?
Not every app needs it. It pays off when any of these apply:
- It is used in places with poor signal: the countryside, expos, warehouses, the subway or while traveling.
- People work in the field or at the customer's location, entering orders, forms or quotes.
- The data entered cannot be lost (an order, a sale, a quote).
- It is a daily-use app where speed is noticeable, like a game or a work tool.
And when is it not needed?
If the information must always be live (for example, the availability of an appointment that can be booked from many places at once) or the app only shows content that changes constantly, the traditional approach is usually enough, and it is simpler and cheaper. The important thing is to decide while designing the app: if you are planning one, tell me how it will be used and I will tell you which approach fits. Here you can see how I work and the kind of projects I do.
Real example 1: how does Sudoku Play work without internet?
Sudoku Play is a Sudoku app I published on the stores, with an adventure mode and 1v1 duels. It works fully offline: every puzzle ships stored on the phone (in a local database), the game state lives in memory and everything you do is written to an event queue. When there is a connection, that queue syncs with the server using the mechanism described above.
Real example 2: how does EQUIBOX quote at a rural expo with no signal?
EQUIBOX is a horse stable manufacturer. I built them a web quoting tool with a 3D render that installs like an app and works offline, because it is used at rural expos where the signal is poor.
Quotes are saved on the device first and synced when the connection comes back. Each one carries an ID generated on the device itself, and the database rejects duplicates, so even if sending is retried several times, a contact is never duplicated. It is the same idempotency principle as Sudoku Play, applied to a website.
What else do you gain by recording every action as an event?
An unexpected benefit: since every action is recorded, the server can analyze patterns. If someone completes a hard Sudoku in 5 seconds, the events show they only made 3 moves, which is clearly impossible. The server computes a suspicion score and can take action without the cheater noticing. All that logic lives on the server, so it cannot be bypassed by tampering with the app.
Frequently asked questions
What does "offline-first" mean?
It is a design approach where the app works with the data stored on the device and only uses the internet to sync. Connectivity becomes a bonus, not a requirement to use it.
Is offline-first the same as an app that "works without internet"?
Not quite. Many apps show something offline but won't let you do anything, or lose what you entered. An offline-first app is designed from day one so everything you do without signal is saved and synced automatically when the connection comes back, without duplicating or losing data.
Can a website be offline-first?
Yes. An installable web app (PWA) can store the whole app on the device and queue what the user enters until there is a connection. That is what the EQUIBOX quoting tool does: it is used at rural expos where the signal is poor.
What happens if I use the app on two devices while offline?
Each device stores its actions as events with a timestamp and a unique ID. When both sync, the server orders the events chronologically and computes a single final state, which both devices then receive. The result is the same regardless of which one connects first.
Does an offline-first app cost more to build?
It adds work on the sync side, but planning it from the start is far cheaper than retrofitting it once the app is built. In my guide on how much a mobile app costs I explain what drives a project's cost up or down.
If you want an app or website that works flawlessly offline, I can build it with this architecture. Check out my published apps and tell me about your project.