In this guide
Your office Wi-Fi is fast and stable. Your users ride trains, sit in lifts and walk through areas with one bar of signal. An app that only works on a good connection fails exactly where people use their phones. Testing weak connectivity on purpose finds these failures early.
What can go wrong
- No loading state. The screen looks frozen while waiting.
- Endless waiting. No timeout, so the app never gives up or explains.
- Lost input. A form is submitted, the connection drops, and the text is gone.
- Duplicate actions. A slow response makes the user tap again and the request runs twice.
- Crashes on empty responses. The app expects data and gets an error or nothing.
- Stale data shown as fresh. Cached content looks current when it is not.
- Broken recovery. The connection returns, but the app stays in an error state until restarted.
Simulate it yourself
Pick whichever method you can do in a few minutes:
- Airplane mode. The simplest way to test "no connection". Switch it on at different moments: before launch, mid-screen, mid-upload.
- Turn off Wi-Fi and mobile data separately. Some bugs appear only when one of the two goes away.
- Walk away from the router, or switch to a slow mobile connection.
- Network throttling tools. Developer tools on both platforms and on emulators can slow the connection or add delay and packet loss. Look in your platform's current tooling for the exact option.
- A proxy on your computer that delays or drops requests, if you are comfortable with that.
- Switch networks mid-action. Move from Wi-Fi to mobile data while something loads.
Ask testers to try it
Testers cannot throttle a network easily, but they can do these:
- Open the app, switch on airplane mode, and try the main task.
- Start a task, then switch airplane mode on halfway. Switch it off again.
- Use the app in a lift, basement or other weak-signal place, if they happen to be there.
- Leave the app open, lose connection for a minute, come back.
Ask them to report: what they saw, whether the message told them what to do, and whether the app recovered by itself. For a longer script, see how to test the offline behavior of your app.
What to look for
- A clear, human message instead of a raw error.
- A visible loading state, and a timeout that ends it.
- A way to retry without losing what was typed.
- No duplicate submissions.
- Saved or cached content labeled honestly.
- Automatic recovery when the connection returns.
Also check the other side
Sometimes "no internet" is not the tester's connection at all. A server outage, a blocked domain or a certificate problem look the same on the phone. Ask the tester to open another app or website to rule out their own network.
Related
- Hub: App testing problems: causes and fixes
- Tester screenshots unusable
- Beta feedback overload: how to organize it
AppReviewX gives you private, structured feedback from testers on their real networks. Start here and add a connection task to your test.