An app that works without a connection

In a stockroom, a delivery van or a building whose walls are still going up, there is no signal, and an app that stops at a spinner is not an app. Offline first means one specific thing: the record is written on the phone and accepted there, and the server hears about it later. Everything difficult follows from that second half — what happens when the phone's copy and the server's copy have both changed, and who finds out.

What does offline first mean in practice?

The write lands on the device and succeeds there, before any network call is attempted. A cache serves reads when the network is missing; a local store accepts writes and is accountable for them.

The record needs an identity created on the phone, not one handed back by the server on arrival. If the number comes from the server, two devices working without signal generate records under the same temporary number, and one erases the other on sync.

Then decide who owns the truth in each field. What the driver did on the road belongs to the phone; a price, a permission or a balance belongs to the server. Put that in one table and have the person who owns the process sign it.

What must every screen show?

One of three states, always visible: saved here and waiting, sent and confirmed, or refused with a reason. A screen that shows none of them is lying by omission.

State	What the user sees	What it means
Held	A waiting mark and a count	Written on the phone, not yet sent
Sent	The server's reference and time	Accepted on the server
Refused	The reason, in words	Rejected; the record stays for correction

The third state is the one teams skip. A refusal is not an error window that disappears: the record stays on the device, marked, and someone corrects it the same day. Otherwise the field team learns that paper is more honest.

Put the count on the supervisor's first screen — twelve waiting. That number says whether the day's work has left the phones.

Colour is not a message. A screen-reader user gets nothing from a green dot, so the change has to be announced as text, which is what WCAG 2.2 requires for status messages.

Which conflicts only appear later?

The ones two devices created while both were right. Two staff edit the same stock line, and one works from yesterday's copy because that phone has not synced since Tuesday. Both saves succeed locally; both reach the server an hour later.

• Send the movement, not the total. "Plus three" and "minus one" reconcile on the server; "the balance is forty" overwrites whatever came before it.
• Do not trust the phone's clock. Device clocks run hours or years wrong; order by server receipt and keep the device time as evidence.
• Make the conflict loud. One resolved in silence is worse than a refusal, because the field looks right and is wrong.

Where two edits cannot both stand, keep both and show the difference to a person.

Let the phone be honest about the age of its data: "as of Tuesday 14:20" makes a person suspicious before they save.

What must never work offline?

Three things: a price the server decides, a payment, and a permission check.

A price carries a discount, a customer rate or a promotion that lives on the server. If the phone cached it, the app quotes a price the business will not honour. Either the server confirms the price before an invoice is printed, or no price appears offline.

A payment without a connection is a promise the app cannot keep; the provider's answer is the only evidence. Queue the intent and mark the sale unpaid until it arrives.

A permission decided on the device is authority handed to whoever holds the phone: a stolen handset with a stale staff list can approve a refund. Check on the server, and keep the answer for the current session only.

None of that means those screens must be dead. It means they say "needs a connection" instead of pretending.

What does the business side have to accept?

A queue that is visible, and a sync someone watches — an operating rule, not a feature of the app.

• A named person opens the count before the day starts and again at closing.
• The queue has an age. A record older than a day is an incident, not a normal number.
• The team is trained on the words. Waiting is ordinary; refused needs an action today.
• Someone may call the paper fallback. A supervisor must be able to say "write it on paper", and the paper must reconcile back afterwards.
• The last successful sync is on screen. Otherwise nobody knows whether twelve waiting records are an hour old or a week old.

How do you set this up?

1. List the records the field creates, and mark which ones the server must confirm before the work continues.
2. Choose the identity: numbers generated on the device, never requested from the server afterwards.
3. Decide the owner of each field — device, server, or mergeable — and write it down for signature.
4. Build the three states into the screen where the record is created, then into every list that shows it.
5. Put the queue count and the last sync time on the supervisor's home screen.
6. Test it the way it fails: airplane mode for a day, two phones on one record, a wrong clock, a refusal in the middle of a batch.
7. Write the paper fallback and rehearse it once with the people who will use it.

Where this goes wrong

• Offline is a cache, not a store. The app shows yesterday's list and accepts no edit; the team finds out on the first morning without signal.
• Last write wins. Stock drifts, nobody can reconstruct which delivery was lost, and the app is blamed for the count.
• Nobody reads the queue. Phones sit in a drawer for a week with forty records, and the month's stock is wrong.
• Refusals vanish automatically. A price list changed, every order is refused in silence, and the field learns the app cannot be trusted.

What this does not cover

It does not choose a framework, a local database or a sync product, and it quotes no figures for any. It assumes records are small and the conflict window is hours, not seconds: two people needing the same stock number in real time is a different problem. It says nothing about a store's rules for background work; the store publishes those. And it does not settle whether an app is the right format — a browser tab with a local store answers part of this.

We build apps that keep working in a stockroom with no signal, and show the queue honestly enough for someone to act on it.