No — and the catch is that it looks as though it does: the delivered app installs to a phone's home screen like a native application, yet it needs the network on every screen. It does not hide that from you: with no connection, a list says “Server unreachable” instead of showing up empty, and a form you were filling in stays open with your values in it. What it does not do is store your data on the device or queue your entries for later sending. If you work from an office, a workshop or a shop counter, you will never meet this limit; if you work in a dead zone, you will meet it on day one — and this page tells you how to factor that in before you buy.
“Installs on your phone” is not “works offline”
The delivered archive contains a web manifest (`manifest.webmanifest`, `standalone` display), so your application can be added to a phone's home screen with its own icon and colours, and opens full-screen with no address bar. Visually, nothing separates it from an app downloaded from a store — which is exactly what misleads people.
The piece that makes offline possible is missing: the service worker, the small program that lives in the browser and serves pages and data when the network is away. There is none in the generated code — you can check by searching the archive for the term. An installed app without a service worker is still an app that queries the server on every screen.
What it actually does when the network is gone
It says so. A list that cannot be loaded shows “Server unreachable. Check your connection.” — not an empty list. That distinction is anything but cosmetic: an empty screen reads as “there is nothing here”, and you drive away from the site convinced no job was ever recorded there, when in fact they all are.
On writing, the form does not close: it stays open, still holding what you just typed, and shows “Could not save — check your connection and try again.” So you retype nothing; the moment the network is back, a second click saves. But it has to be said plainly: until you have clicked with a connection, nothing is saved, and closing the tab before that loses what you typed — it is kept nowhere on the device.
What it does not do, and the trouble it avoids
None of your business data is stored on the phone or the computer: no embedded database, no queue of deferred uploads. There is therefore no synchronisation when the network returns either. This is not an option switched off somewhere in the settings — the capability does not exist in the product, and it is better to know that before than after.
It is a limitation, and it has a flip side it would be dishonest to leave out: on tools that do work offline, the most frequently reported failure is synchronisation itself — entries lost on the way back up, duplicates created on a second pass. A tool that queues nothing cannot lose its queue. That is no substitute for offline capability when you genuinely need it; it only means the absence here is a clean absence, not a half-working feature you would half rely on.
Deciding based on where you enter data
The right question is not “do I have a signal?” but “where do I type things in?”. At a desk, in a workshop, behind a counter, in a covered warehouse or at home in the evening, coverage is steady and this limit never comes up. On a remote site, in a cellar, a basement, a dead zone or on a rural round, you will meet it on the first day, and no setting will make it go away.
In that second case there are two honest routes. Keep the tool that handles offline for field entry, and reserve the generated app for everything done on return — job tracking, scheduling, stock, indicators; or accept deferred entry, noting things down on the spot and typing them in once connected, which suits someone logging a handful of lines a day and does not suit someone logging fifty. What you should not do is buy on the assumption that it will be sorted out later: there is no setting to find.