Offline Support
Lets the Android app open and show the web app without an internet connection, with no changes to the web app. It is off by default and switched on per build.
Pages, scripts, styles, images and API data (
GET) the user has already seen are kept on the device and shown when the network is unavailable.When the connection drops on a page that can't be shown, the app displays its "Connection Problem" screen and reloads by itself once the connection is back.
Optional for the web team: an API to save changes made offline and send them later. See Offline Support and Write Queue (Android).
iOS: not available yet. See Technical Design for the options.
Before you turn it on
Offline mode works best when the web app:
Serves its API from the same domain as the pages. API data from another domain is not kept offline; only the app's look and layout are.
Doesn't mark API responses
Cache-Control: no-store. Those are never stored (some frameworks add it to every logged-in response by default). The start page is the one exception and is stored anyway.Logs out through
AndroidCookie.clearCookies(...)or the configured logout redirect URL. That also wipes the offline data, so the next user of the device can't see the previous user's data.Has no service worker of its own. If it has one, MobiWeb steps aside and only basic browser caching applies.
Send the web team the web-developer guide; it lists these in detail.
Turn it on
In android/app/build.gradle, set the flag for the build you want (for example only debug, or a dedicated variant):
Make sure INITIAL_URL is the web app's final address. Open it in a browser and copy the address bar after any redirects, including the path (e.g. https://app.example.com/home, not https://example.com).
Build and install as usual. Nothing needs to change on the server.
What users will see
The first time, the app needs to be opened once while online, logged in. Offline data starts building from that visit.
Situation | What happens |
|---|---|
App opened without internet | The last version of the start page and of every page already visited is shown. Data that was never loaded, and API data from another domain, is missing; the web app shows its own empty or error state. |
Connection drops while using the app | Nothing changes on screen. Pages and data already seen keep working from the device copy. Actions that need the server (saving, other domains) fail as they would in a browser, unless the web app queues them. |
Page that was never visited, while offline | "Connection Problem" screen. |
Connection comes back | The "Connection Problem" screen (if shown) reloads by itself. Queued changes are sent. Pages already open are not reloaded; they get fresh data the next time the web app asks for it. |
Slow connection (over 8 s to load a page) | The saved copy is shown; the fresh one is stored for next time. |
Check that it works
Install a build with the flag on and open the app once online. Browse a few pages.
Close the app fully, turn on airplane mode, and open it again: the pages you visited should appear, with styles and images.
Turn airplane mode off: the app keeps working, and a "Connection Problem" screen (if any) reloads.
For more detail (what is stored, events, the write queue), open the app's WebView in desktop Chrome at chrome://inspect → Application → Service Workers/Cache Storage. The full test list is in the Technical Design.
Turn it off
Set OFFLINE_ENABLED back to false and ship the build. The next time each user opens the app online, the offline data and its background worker are removed automatically.
Good to know
Offline data is limited to what users have already visited, up to roughly 100 MB / 500 items per device, oldest removed first.
Saved API data is protected by the app's private storage (like the web app's own local data), not encrypted separately. Queued changes are encrypted.
A captive Wi-Fi portal counts as "online"; requests then fail and are retried later.
How it works, design decisions, limits and tests: Technical Design.