Offline-first apps that work without signal

What "works offline" should actually mean

Many apps claim to work offline and only show the last screen you opened. For an offline mobile app for field workers, the question is what people can do without signal, screen by screen. There are four levels, and each one adds work:

Offline sync and conflicts: decided with you, not by the app

Everything done without signal goes into a queue on the phone and is sent when the connection returns, with retries if it drops halfway. Each record shows whether it is saved on the phone or sent, so nobody wonders whether their work arrived. Photos upload in the background, after the text, so a weak signal does not hold up the important data.

Conflicts are a business decision, not a technical one. If an engineer edits a job offline while the office changes the same job, what should win? The rules are agreed field by field:

• Last change wins for low-risk fields such as notes or contact details.
• Both are kept for things that add up, such as checklist answers or parts used.
• Flagged for review for anything that affects money or stock, such as prices, quantities or job status.
• Data on the phone is encrypted, limited to what that user needs, and removed when they sign out.

Offline PWA or native app

A web app (PWA) can work offline, but on iPhone the browser decides how long it keeps the data. WebKit's own documentation says that by default sites use a best-effort storage mode in which persistence is not guaranteed; a site can ask for persistent storage, and WebKit grants it based on factors such as whether it has been added to the home screen. WebKit has also described deleting a site's stored data after seven days of Safari use without the user interacting with it, with home screen web apps keeping their own counter.

For light use, such as looking things up or filling in the odd form, an installed PWA can be enough. When people work for days without signal or the unsent data is valuable, a native app gives more predictable storage and background sync. That is why most field apps we would recommend are native, built once for iOS and Android.

Where offline-first matters most

The pattern is the same wherever signal is unreliable: plant rooms, basements, rural sites, inside large metal buildings. The most common cases are field service app development, where engineers complete job sheets and capture signatures on site, and a custom inspection app for checklists in places the network does not reach. Meter reading, deliveries and surveys follow the same rules.

Offline on its own is rarely a reason to build. Many off-the-shelf field service and inspection tools already have an offline mode, so if one fits your process, test it in your worst-signal location before anything else. We will tell you if it does the job. Building makes sense when the offline workflow you need, or the data it has to carry, is specific to your business.

Testing without signal before go-live

Offline behaviour is only proven by trying to break it. Before go-live we test with the phone in flight mode for a full day's work, on a weak and intermittent connection, with the battery dying mid-job, and with two devices editing the same record. What weighs most on the price is the offline level you need on each screen, the conflict rules, the volume of photos and the number of record types.

Your own staff test every working demo, one every two weeks, in the places where signal actually fails, under one fixed price per project. The method is on our page about fixed price software development.