Many small business tools are now web apps that sit on the phone like any other app. A good one keeps a copy of itself on the device, so it still opens on a weak signal, and holds on to anything you save until the connection comes back.
That is a promise worth checking. At Balay ni Bruno & Co. we run our own team tools this way, and when we set out to prove that one of them really worked offline, the first thing we learned was that where you test matters as much as how.
The Trap: A Preview That Cannot Work Offline
We first tried the test in a browser preview built into a desktop app. It refused to set up the app's saved copy on every address we tried, with a vague "unknown error". We checked our server and it was answering correctly. The problem was the preview itself: it simply does not run that part of a web app.
A failed test is not always a broken app: if a preview cannot run the saved copy at all, it will tell you the app fails offline even when it works perfectly on a phone. Test somewhere that behaves like the real thing.
What Works: A Real Browser You Can Unplug
What worked was a real browser controlled by a testing tool. That tool can switch the network off for real, the app then opens from its saved copy, and anything saved on the device is still there after the page is closed and opened again.
The Four Step Offline Test
Open the app, wait until its saved copy is ready, then reload once so the copy on the device fills up.
The app must still open, and it must say clearly that it is offline.
Still offline, save an item, close the page and open a new one. The item must still be there, waiting to send.
The waiting item must arrive, and arrive only once. Give it a moment if the app does extra work before saving, such as turning a voice note into text.
Making Sure Nothing Arrives Twice
Step 4 is where offline apps usually go wrong. When the connection comes back, several things can try to send at once: a timer, the "back online" signal, and the app being reopened. And if the reply from the server gets lost, the app may send the same item again. We put two guards in place:
Without guards
- A timer, the connection returning and a reopen can all send together
- A lost reply leads to a second send
- The same item can show up twice
With guards
- A lock lets only one send happen at a time
- Every item carries its own id that the server remembers
- A resend just gets the first result back, so nothing doubles
The test takes a few minutes, and it answers the question that matters to your team: if the signal drops in the middle of the day, does their work wait safely and arrive once?
Common Questions
Why does my web app look broken offline in one browser but work on my phone?
Some browser previews built into desktop apps do not run the part of a web app that keeps a saved copy on the device. When we tested one of our own apps in such a preview, it refused that part on every address with an unknown error, even though our server was set up correctly. The preview simply does not support it, so it cannot tell you whether the app works offline.
What is the simplest way to prove a web app works with no internet?
Use a real browser that a testing tool can control, so you can switch the network off for real. Open the app and let it save its copy, switch the network off and reload, save something, close the page and open it again while still offline, then switch the network back on and check that the saved item arrives exactly once.
How do I stop an offline app from sending the same thing twice?
Give every saved item its own id that the server remembers, so a resend after a lost reply just gets the first result back. Then add a lock so the different moments that trigger a send, like a timer, the connection coming back or the app reopening, never send at the same time.
Key Takeaways
- Some built-in browser previews cannot run a web app's offline copy, so they give a false failure.
- Test in a real browser that lets you switch the network off for real.
- Four steps: settle, go offline and reload, save and reopen, go back online.
- The saved item must arrive exactly once when the connection returns.
- A lock plus an id per item stops double sends.