What Works Offline
Offline caching stores files. It does not store your data, and the difference decides what actually works.
Where to find it
Architect Panel → Configuration:
- Site Settings — the Progressive Web App and Service Workers option groups
Architect Panel → Layout & Pages:
- Dependencies — the files the site loads, and what the offline cache is built from
What survives offline
- Cached pages and assets — the interface loads.
- Images already cached.
- Scripts and styles, so the application looks and behaves normally.
What does not
- Anything read from the database. Lists, records, search results — all of it needs the server.
- Saving anything. A submission with no connection does not queue itself.
- Signing in.
- Anything from another service.
So an offline web app shows its shell and very little else. Understanding that prevents promising something the technology does not do.
Say so to users
The dangerous outcome is a user who believes the app works offline, does an hour of work in a tunnel, and loses it. That is worse than an app that plainly refuses.
Where a connection is genuinely lost, the honest thing is to say so on screen.
It is mostly about speed
Which is the real benefit and is undersold. Cached assets mean the app loads immediately on repeat visits and survives a brief connection drop without a browser error page.
For most organisations that is the whole value, and it is worth having.
Staleness is the cost
Cached files are served ahead of the network, so a user can be running yesterday’s interface. Usually harmless; occasionally the reason one person sees a bug nobody else can reproduce.
"Have they still got an old cache" belongs early in your support script.
If you need real offline working
Records available and changes queued while disconnected, then synchronised — that is the native mobile app builder, which has an explicit offline mode and a retry window for queued operations.
A progressive web app is the right tool for a fast, installable interface. It is not the right tool for genuinely disconnected working.
Test what a user actually sees
Open the app offline from cold and look. Whatever appears is what your users will see in a lift, on a train or in a basement, and it is usually less than expected.
Worked example
An organisation enabled caching for speed rather than offline working, tested the app from cold in flight mode, and added a banner shown when the connection is lost. Support scripts now begin by asking whether the app has been closed and reopened.
Recommendations
- Treat it as a speed feature, not an offline one.
- Tell users when the connection is lost.
- Ask about stale caches early in support.
- Use the mobile app if you need real disconnected working.