How do inspection apps work at remote sites?

An inspection turns a visit into a record: a checklist of answers, meter readings, photos of what the inspector saw, notes, a signature, and the time and place it all happened. At a remote site, such as a substation, a pipeline route, a tower or a pump station, that record may be made where the phone has no usable connection.

An app built for the office assumes every tap reaches a server. At a site with no signal it fails in one of two ways: it refuses to save, or it appears to save while holding data only in memory, which a restart or a flat battery then wipes. A field app has to be designed so neither happens.

Android’s offline-first guidance describes an app that can perform all, or a critical subset, of its core functionality without internet access. Its central idea is that the local data source is the canonical source of truth for the app, and the network copy catches up later.

For writes, the guidance offers lazy writes: write to the local data source first, then queue the change to send at the earliest opportunity. It names this the correct choice when data is critical to the app, which describes every inspection answer. The queue is a durable outbox on the device, so a record survives a restart before it uploads.

Uploading should not depend on the inspector keeping the app open. Each platform has a way to hand the job to the system:

• Android. WorkManager runs persistent work that survives app restarts and device reboots. A work request can carry a network constraint, such as waiting for an unmetered network like Wi-Fi, which suits large photo uploads.
• Apple platforms. A URLSession configured with waitsForConnectivity waits for a connection instead of failing at once. Background sessions always wait for connectivity.
• Web. A service worker sits between the page and the network, so a web app can serve its pages and cached data offline. Upload in the background is less settled: the Web Background Synchronization specification is a community group draft, not a W3C standard.

Photos deserve their own queue. A checklist answer is small and should go first; a set of high-resolution images can wait for a better connection without holding up the rest of the record.

Late upload creates three questions an inspection app has to answer in advance.

1. Was this already received? Give every inspection and every change an ID created on the device. If an upload is retried because its confirmation was lost, the server uses the ID to apply it once.
2. What if two people changed the same thing? Android’s guidance describes last write wins, where the newest timestamp is kept. That suits a note field, but not a pass or fail result. How are sync conflicts resolved? covers the alternatives.
3. When is the work done? An inspection saved on a phone, an inspection received by the server, and an inspection accepted into the asset system are three different states, and the app should show which one each record is in.

Some remote jobs involve more than one person. One technician takes readings, another finishes the checklist, and a supervisor signs off before the crew leaves. If none of them has signal, uploading cannot coordinate them.

Device-to-device software fills this gap by sending records directly between nearby phones over a local link. Offline Protocol’s local handoff guide treats a handoff as complete only when the receiving app has accepted responsibility for the work, and keeps delivery, local acceptance and backend commit as separate states. The asset or inspection system remains the system of record; the handoff only moves the record, and its custody, between the people on site until one of them can upload.