Offline is a promise about the worst day.
Offline first means four things, and every one of them has to be true. Capture works with no connection. Reading works with no connection. The queue survives the app closing and the battery dying. And sync can be retried without creating a duplicate or losing a record the server refused.
Almost every product in this category says it works offline. What that usually means in practice is that the app does not crash when the bars go, which is a much smaller claim, and it is not the one anybody is buying.
Why this is not a niche requirement
The deck, the wharf, the cold store and the inside of a steel building are all dead spots, and that is not an accident of geography. It is where the work is. A landing is born in exactly the place with no signal, and every record downstream of it, the grading run, the purchase slip, the settlement, the freezer count, inherits whatever got written down there.
Which is why the failure is expensive out of proportion to its size. A lost landing is not one missing row. It is a harvester paid wrong, a lot that cannot be traced, and an argument that nobody can settle because the only copy of the truth blew off the dock.
The half nobody demos: the refusal
Here is the case that separates software built for this from software adapted to it. A landing is captured on a phone with no signal. The phone says saved, because it genuinely is saved, on the phone. Forty minutes later it comes back into range and sends. The server refuses it, because in those forty minutes the office closed that trip.
What happens next is the whole question. In most systems, nothing visible: the record sits in a failed queue, or a log line, or a support inbox. The person who captured it was told saved and has moved on. Nobody finds out until the numbers do not add up.
What should happen is that the refusal finds its way back to the person who was told saved, in words, on the screen they are already looking at, with the thing they can do about it. That is a design decision made before the first line of code, and it is the one we would ask a vendor about first.
Idempotency, in one paragraph
A phone with a bad connection will send the same thing more than once. It has to be safe for it to do that. The way this works is that the device mints its own identifier for the landing before it sends anything, and the server treats a second arrival of that identifier as the same landing rather than a new one. The human readable landing number is assigned by the server on first success, so two phones can never mint the same one.
It costs almost nothing to build in at the start and it is close to impossible to retrofit honestly, because by then there is a year of data that may or may not contain duplicates nobody has found.
Five things to try before you buy anything
Do these on the vendor’s demo, on a phone, in front of them. All five take about ten minutes and they are considerably more informative than a feature list.
- 01Turn the radio off and record five landings, then force quit the appReopen it. All five should still be there, and it should be able to tell you they have not left the device yet. If it lost them, the queue is in memory rather than on disk and the app is offline tolerant rather than offline first.
- 02Still offline, go and look at this morning's landingsA capture app that cannot show you what it already holds is half an offline app. It should serve the list from the device and tell you how old it is, in plain words, rather than showing a spinner or an empty screen.
- 03Come back into range with the phone locked in a pocketThe queue should drain on its own. If it only syncs when somebody opens the app and presses something, then somebody will forget, and the day it matters will be the day of the argument about a weight.
- 04Ask what happens when the server says noNot if. When. The office closed the trip, the licence expired, the vessel is not on the buyer's list. The record must come back to the person who took it with the reason in words they can act on, not disappear into a log.
- 05Sync the same landing twice on purposeThere should be one landing at the end of it. If a flaky connection can produce two, then a bad afternoon on the wharf produces a purchase slip that pays a harvester twice, and somebody finds that out in a month.
The thing that will bite you anyway
Storage on a phone is not permanent. A browser based app can have its local data evicted when the device runs low on space, and installing it to the home screen and asking the operating system for persistent storage changes the odds rather than the rules. Anything that has to survive a week of no signal needs to be tested that way on the actual phones the actual crew carry, in October, not on a developer’s desk in June.
We say this because it is the part everybody, including us, has to keep being honest about. Offline first is not a feature you switch on. It is a set of decisions that show up as ordinary looking screens and then hold on a bad day.