Offline web apps for field teams: what a PWA can and cannot do in 2026

Yes, a progressive web app (PWA) can work without internet, if it was built for it. As of October 2026, Chrome on Android and Safari on iOS both support service workers, the Cache API and IndexedDB, so a web app can open with no signal, show the data it loaded earlier and queue edits until the connection returns. What a PWA still cannot do on an iPhone: upload queued data in the background after the app is closed, track location while the screen is off, or talk to Bluetooth devices.

Below: the three levels of offline and what each costs, a browser support table, storage limits, design and testing advice for field teams, and when a native app is still the right call.

What are the three levels of offline?

"Works offline" can mean three very different things. Each level includes the one before it, and each costs a lot more to build and maintain than the last.

Level 1 is usually days of work in an existing web app, and it removes the worst field experience: a white screen in a basement. Level 2 is where most field apps should aim, usually weeks of work: IDs generated on the device (UUIDs) so a double replay does not create a duplicate, replay in the original order, and rejected edits (the record was deleted, a permission changed) kept visible with the reason.

Level 3 is a different kind of project, measured in months. You are building a sync engine: the server tracks what changed since each device last synced, the device runs a real local database, and you need a conflict policy such as last write wins, merging field by field, or asking a person. Unless field users truly need to browse thousands of records they have never opened, level 2 plus a preloaded working set covers most field work.

PWA offline support on iPhone and Android in 2026

The building blocks for levels 1 and 2 work on both platforms. The differences are in what happens while the app is closed, and in hardware access. The table below was checked against MDN's compatibility data, web.dev and WebKit's own announcements in October 2026.

Two rows matter most for field teams. Without Background Sync on iOS, edits queued on an iPhone only upload while the app is open, so replay on launch and whenever connectivity returns, and let the sync status remind people to open the app before they head home. The location row is not a bug: the W3C Geolocation specification says a hidden page waits until it is visible again before it gets a position.

Chrome and Firefox on an iPhone generally match the Safari column. Apple requires iOS browsers to use its WebKit engine, apart from alternative-engine entitlements it grants in the EU and Japan.

How much can a PWA store offline, and when does Safari delete it?

Quota is rarely the problem. MDN lists Chrome at up to 60% of total disk per origin, and since Safari 17 (2023) WebKit allows a site up to 60% of total disk in the browser, with the same quota when it runs as a Home Screen web app. A field app holding a week of jobs and a few thousand records uses megabytes, not gigabytes.

Eviction is the real risk. When a device runs low on space, browsers delete whole origins, least recently used first, unless the site has persistent storage. You can ask for it with navigator.storage.persist(). Chrome and Safari decide without prompting the user, and WebKit says one of its signals is whether the site is opened as a Home Screen web app.

Safari also has a time rule. Since iOS 13.4 (March 2020), with tracking prevention on, Safari deletes a site's script-writable storage, IndexedDB and service worker registrations included, after seven days of Safari use without the user interacting with that site. WebKit's post on the change says Home Screen web apps keep their own day counter, matching actual use of the app. The practical rule: get field users to install the app, and treat anything on the device as a cache that must sync within days, never as the only copy.

How do I install a PWA on iPhone and Android?

On Android, Chrome offers an install prompt or an Install app (or Add to Home screen) menu item once a site meets its installability criteria: HTTPS, and a web app manifest with a name, a start URL, a standalone-style display mode and 192 px and 512 px icons. On phones with Google services it installs as a WebAPK, which looks like any other app.

On iPhone and iPad, installing is manual: Share, then Add to Home Screen. Since iOS 16.4, other browsers on iOS can offer the same menu item, and since iOS 26 every site added to the Home Screen opens as a web app by default, with an Open as Web App toggle for people who want a plain bookmark. iOS never prompts, so put these two steps on your app's first screen for iPhone users.

How to design a field app that works offline

1. Decide what must work offline, per screen. A technician usually needs today's jobs, each site's address and notes, and the forms to fill in. Write the list down: it is your offline scope.
2. Load the working set while there is signal. If the offline copy is whatever the user happened to open, ask people to open today's list at the depot, or preload it on launch.
3. Show sync status all the time. A small header chip that says Offline, 3 changes waiting, or All synced beats any error toast. Nobody should have to guess whether a form was saved.
4. Make failures and conflicts visible. A replayed edit can be rejected. Keep it in a list with the server's reason and offer Retry and Discard. Never drop an edit silently.
5. Generate IDs on the device. A record created offline needs its ID before the server sees it, so related records can point to it.
6. Do not trust navigator.onLine. MDN calls it inherently unreliable: a LAN connection counts as online even with no internet behind it. Treat any failed request as offline and probe the server until it answers.
7. Keep photos small and separate. Compress images on the device and send them after the text fields, so one large photo on one bar of signal does not hold up the whole queue.
8. Wipe offline data on log out. Field devices get shared. Signing out should clear the local copy and the queue, after warning about unsent edits.

// navigator.onLine is a hint, not a fact. Treat any request that never
// reached the server as "offline", then probe until the server answers.
let online = navigator.onLine;
let probe = null;

async function api(url, options = {}) {
  try {
    // fetch resolves for any HTTP status. It rejects only when no answer
    // came back: no route, DNS failure, captive portal, timeout.
    return await fetch(url, { ...options, signal: AbortSignal.timeout(15000) });
  } catch (err) {
    goOffline();
    throw err;
  }
}

function goOffline() {
  online = false;
  showSyncStatus("Offline: changes are saved on this phone");
  if (probe) return;
  probe = setInterval(async () => {
    try {
      const res = await fetch("/healthz", { method: "HEAD", cache: "no-store" });
      if (!res.ok) return;
    } catch {
      return; // still offline
    }
    clearInterval(probe);
    probe = null;
    await replayOutbox(); // queued edits first, oldest first
    online = true;
    showSyncStatus("All changes synced");
  }, 10000);
}

How to test offline mode (devtools is not enough)

The Offline switch in browser devtools simulates a clean, total loss of network. Field failures are messier: one bar of signal where requests hang for a minute, hotel Wi-Fi that wants a login page, a connection that drops halfway through an upload. Test on real phones, with the app installed:

• Airplane mode on an iPhone and an Android phone: create, edit and delete records, close the app, reopen it, then turn the network back on.
• A basement, a lift or a metal-clad warehouse, where signal comes and goes while you work.
• Wi-Fi with no internet behind it (unplug the router's uplink). The phone reports a connection, which is exactly where navigator.onLine misleads.
• Edits queued, then the phone left offline overnight. Check that nothing was evicted and the queue replays in order in the morning.
• Two people editing the same record offline, so you know exactly what your app does with it.

When is a native app still the right call?

A PWA handles forms, checklists, photos, signatures, lookups and scanning. Choose native (or a native shell around your web app) when the job depends on something the web cannot do on the phones your team carries:

• Continuous background location. Mileage logs, live driver tracking and geofenced check-ins need positions while the screen is off. Browsers only deliver positions to a visible page.
• Bluetooth peripherals on iPhones. Label printers, scales and sensors need Web Bluetooth, which Safari does not support. Barcode scanners are the exception: in keyboard mode they work with any web app, as covered in barcode scanning in the browser.
• Very large offline datasets. Hundreds of thousands of catalog rows, offline maps or months of history. The quota allows it, but that is level 3 sync plus eviction risk, and native gives you a durable on-device database.
• Guaranteed uploads while closed on iOS. If data must leave the phone without anyone opening the app, iOS has no web API for that today.

How Emberblocks handles offline

Emberblocks builds level 2 into every published app. Here is what we built, including the part that is not done yet.

• App shell. A service worker caches the app's pages and assets, network first with the cache as fallback. It never caches API calls, so a user with signal always gets live data.
• Data last viewed. What each user last opened is kept in IndexedDB, per app and per signed-in user, for up to 7 days, which lines up with Safari's seven-day rule. Records nobody opened on that phone need a connection.
• Offline edits. Edits made without a connection go into an outbox and replay in order when the connection is back.
• What does not queue. File uploads, buttons that run a workflow or set values on other records, bulk actions and CSV imports need a connection, because the server has to compute something. New records queue on tables keyed by UUID, which includes the built-in database; a Postgres table keyed by a sequence number needs a connection to create rows.
• Sync chip. A chip in the app header shows pending edits, with Retry and Discard.
• Log out. Signing out purges the offline data on that device.

There is no conflict detection yet. If two people change the same record while offline, the last replay wins and the earlier change is overwritten without a warning. With one technician per job that rarely comes up, but if two people update the same record in a dead zone, know this before you rely on it.

One lesson we learned building it: navigator.onLine is not reliable. It stays true behind captive portals and some proxies, so the app treats any failed fetch as offline and probes the server every 10 seconds to come back online.

Published apps install to the home screen with your app's icon and name (see publish and share), and workflow notifications arrive as web push for users who opted in. Any text field can also scan barcodes with the camera; the field service app builder page lists the rest of the field toolkit.

Where Emberblocks is not the right fit: there are no App Store or Play Store apps, no background location, no conflict detection, uploads and workflow buttons need a connection (they say so instead of queueing), and so does data a user never opened on the phone. If you need those, build native or choose a platform built around full offline sync. Builders are free and plans are priced by app users; see pricing.