Field Operations App

Building an app for the worst signal the job will ever see

Coverage disappears exactly where the work is: a basement, a plant room, a site an hour past the last mast. Anything that assumes a live connection stops being useful at the one moment it was needed.

So the device holds the truth first, and the server hears about it later.

React Native gives one codebase across iOS and Android, and underneath it a local database is the real store. Jobs, forms, photos and signatures are written there and read from there whether or not there is a network, and a sync engine moves the queue to a Node service the moment a connection appears.

Everything difficult about an offline app is in the reconciliation, not the UI:

• a write queue that survives a force quit

• conflict rules written per field, not globally

• photos uploaded apart from the record itself

• a job that can be finished twice without harm

Conflicts are a data decision taken before any code is written. For every field there is a rule about which side wins and what happens to the version that loses, and the rule that discards information quietly is never the one chosen.

The server side matters as much. Sync endpoints are idempotent, every write arrives with an identifier the device generated, and a phone that retries the same batch four times on a bad connection produces one record rather than four duplicates to unpick.

Testing happens on the network the job actually has: flight mode, one bar, and the worst case of all, a connection that answers slowly instead of failing, which is the one that leaves half a request behind it.

What ships is an app that behaves the same in a basement as it does in the office, and a back office that can see, device by device, what has synced and what has not.