Network Conditions

Friday evening. Marta orders dinner in a food delivery app while walking to the train. She taps Place order, the spinner spins, and she steps into the station elevator. The spinner keeps spinning. She taps again. Back on the street, two confirmation emails arrive: two dinners, charged twice.

Nothing was “broken” on the developer’s desk, where the office Wi-Fi is fast and never drops. The bug only exists on a real street, with a real phone, on a real network. That’s why testing network conditions is one of the most valuable things a mobile tester does.

Why it matters

• Most users are not on fast Wi-Fi. They’re on mobile data, moving between cell towers, in basements, on trains and in crowded stadiums.
• Network bugs cost money and trust. Double orders, lost photos, prices that are hours out of date, and “Something went wrong” with no way out.
• Developers rarely see them. A spinner that never stops looks fine for the 80 ms it’s visible on office Wi-Fi.

Wi-Fi, mobile data and the “G”s

A phone connects to the internet in one of two ways: Wi-Fi (a local router, often fast but sometimes overloaded or behind a login page) or mobile data (the cellular network). Mobile data comes in generations:

Network	Typical real-world speed	Typical latency	Where you still meet it
2G / Edge	0.1–0.25 Mbps	500–1000 ms	Rural areas, basements, fallback when 4G is overloaded
3G	0.5–5 Mbps	100–500 ms	Older networks (many countries are switching it off), weak signal areas
4G / LTE	5–50 Mbps	30–100 ms	The everyday mobile network for most users
5G	50–1000+ Mbps	10–30 ms	Cities; drops back to 4G indoors and at the edge of coverage
Wi-Fi	10–500+ Mbps	5–50 ms	Home, office, cafés, hotels (quality varies wildly)

Latency, bandwidth and packet loss

These three words describe how a connection is bad. Each one breaks apps in a different way.

A useful rule of thumb: latency hurts chatty apps (many small requests in a row), low bandwidth hurts heavy apps (big images, videos, uploads), and packet loss hurts everything unpredictably (requests stall, then fail or succeed seconds later).

Real-life situations to recreate

Bad networks aren’t just “slow”. Here are the situations that find the most bugs:

Situation	What happens to the network	What to watch in the app
Offline	No connection at all	Clear offline message, cached content, actions queued or blocked politely
Airplane mode	Wi-Fi and cellular off (Wi-Fi can be turned back on separately)	Same as offline; also test turning it off again: does the app recover by itself?
Switching networks mid-request	Wi-Fi → cellular when leaving home; the device gets a new IP address and open connections break	In-flight requests fail or hang; uploads and payments must not be lost or duplicated
Elevator / tunnel	Connection disappears for 10–60 s, then comes back	Spinner forever? Automatic retry? Data lost?
Captive portal (hotel, airport, train Wi-Fi)	Wi-Fi is “connected” but every request returns the portal’s login page (HTML, not JSON)	App shows a helpful error instead of crashing on unexpected HTML
VPN	Extra latency, different country/IP, some hosts blocked	Region-specific content, login, payments and maps still work
Data Saver / Low Data Mode	The OS limits background data (Android Data Saver, iOS Low Data Mode)	Background sync, autoplay video and prefetching respect the setting; the app still works
Weak signal / crowded network	High latency and packet loss	Timeouts, retries, double submits

What a good app does

A resilient app doesn’t need a perfect network. It needs good answers to the question “what if this request is slow, fails, or never comes back?”

Try it: the network lab

This food delivery app loads a list of restaurants. Start on 3G, then try Lossy with the timeout set to Never. Then switch on Timeout, Retry and Cache one by one and compare the timeline.

🧪 Network lab

Pick a network, then switch the app’s resilience features on and off. Each change reloads the feed.

Network profile

Wi-Fi4G3GEdgeLossyOffline

RTT 300 ms · 750 kbps ·High latency and low bandwidth. Every round trip costs a third of a second.

Timeout

Give up on a request after…

Never5 s15 s

Retry with backoffAfter a failure, try again after 1 s, then 2 s.Cache last resultShow the restaurants saved on the last visit while loading.

9:41

Deliver to · Home

Near you

Content visible

—

Requests sent

0

Result

Loading

Request timeline

Replay Skip

0 s0.5 s1 s

Latency (handshakes) Download Waiting, nothing arrives Failed / timed out

Event log0.00 s

Simulated, replayed at 2× speed. Times are typical, not exact.

What to test

Loading and slowness

• Every screen that loads data shows a loading state on slow 3G. No frozen UI, no blank screen.
• Buttons that send data (Pay, Send, Save) are disabled or show progress while waiting. Tapping twice doesn’t create two orders.
• Screens remain usable while images load slowly (text first, images later).
• Long operations show progress, and the user can cancel or leave safely.

Offline and errors

• Opening the app offline: cached content with an offline indicator, or a friendly offline screen.
• Every error message is human-readable and offers a next step. Try again actually tries again.
• Requests time out in a reasonable time. No endless spinners.
• The app recovers automatically when the connection returns (or after one tap on Try again).

Interruptions and switching

• Switching Wi-Fi → mobile data (and back) during loading, uploading and paying.
• Going offline in the middle of an upload, a form submission and a payment: nothing is lost or duplicated, and the user is told what happened.
• Turning airplane mode on and off with the app in the foreground and in the background. Related: interruptionsInterruptionAnything that takes the user away from the app mid-task: a call, an alarm, a notification, low battery.Open in glossary → and the app lifecycleApp lifecycleThe states an app moves through: not running, foreground, background, suspended and terminated.Open in glossary →.

Special networks

• Captive portal Wi-Fi (connected, but no real internet).
• VPN on, especially with a VPN server in another country.
• iOS Low Data Mode / Android Data Saver on.
• Very high latency (1–2 s) with normal bandwidth, and good latency with very low bandwidth.

Common bugs

#	Bug	What you see	Typical severity
1	Infinite spinner	Spinner never stops offline or on a lost request; no timeout, no error	High
2	Double submit on slow network	User taps Pay again because nothing happened; two orders or two payments	Critical
3	Technical error text	NSURLErrorDomain Code=-1009, SocketTimeoutException, stack traces	Medium
4	Silent data loss	A photo, message or form disappears after the connection drops, with no message	High
5	Stale data shown as current	Old cached prices, balances or stock with no “offline” or “last updated” hint	High
6	Dead retry button	“Try again” does nothing, or only works after restarting the app	Medium–High
7	No recovery	The app stays in the offline state after the network returns	Medium
8	Crash on unexpected response	Captive portal HTML or a truncated response crashes the app	High
9	Too-short timeout	Works on Wi-Fi, always fails on 3G or Edge although the server answers	High
10	Race condition after reconnecting	Old responses arrive late and overwrite newer data. See race conditionsRace conditionA bug that depends on the timing or order of events, so it only happens sometimes.Open in glossary →	Medium

Find the bug

This sports shop app has six network bugs. Use the Device network switch under the phone like you’d use airplane mode or a throttling tool. Try every screen on Wi-Fi, on Slow 3G and offline, switch networks in the middle of things, and watch the network log.

🐞 Bug hunt: Sports shop on a bad network

This demo has 6 hidden bugs. Explore it like a tester, then check your findings.

Found0/6

9:41

Shop

ShopOrdersProfile

Device network

Restart app

Wi-Fi Slow 3G Offline

Network log

• Requests will appear here…

1. 1

   Hint: Go offline, then open the Orders tab.

   Orders tab spins forever when offline

   The network log shows GET /v2/orders failed instantly with no connection, but the app ignores the error. The spinner never stops, there is no timeout, no message and no retry. Expected: an offline message ("You’re offline. Connect to see your orders.") with a Try again button, or cached orders.

   Reveal answer✓ I found this
2. 2

   Hint: Switch to Slow 3G, open a product and tap Buy now twice.

   Double order when tapping "Buy now" twice on a slow network

   The button shows no loading state and stays enabled for ~3.5 s, so a second tap sends a second POST /v2/orders. Two orders are created (check the Orders tab). Expected: the button is disabled with a spinner after the first tap, and the server ignores duplicates (idempotency key).

   Reveal answer✓ I found this
3. 3

   Hint: Go offline and tap the refresh button in the Shop.

   Raw system error shown when refreshing offline

   The alert shows Error Domain=NSURLErrorDomain Code=-1009 … including internal keys and the API URL. Expected: a human message like "You’re offline. Check your connection and try again." Technical details belong in logs, not in the UI.

   Reveal answer✓ I found this
4. 4

   Hint: Start changing your profile photo, then go offline before it reaches 100%.

   Photo upload silently lost when the connection drops

   The progress bar disappears, the old avatar comes back, and nothing tells the user the upload failed (the log says connection lost). Expected: a clear "Upload failed" message with Retry, or the upload is queued and resumes when the connection returns.

   Reveal answer✓ I found this
5. 5

   Hint: Note the prices on Wi-Fi. Go offline, tap Restart app, and compare.

   Outdated cached prices shown as current while offline

   Offline, the app falls back to prices cached yesterday (shoes $79.99 instead of $99.99) with no offline banner and no "last updated" time. Users think the sale is still on. Expected: an offline indicator and a timestamp, or prices hidden until they can be confirmed.

   Reveal answer✓ I found this
6. 6

   Hint: Go offline, tap Buy now, go back online and tap Retry.

   Retry button on a failed order does nothing

   Tapping Retry sends no request (nothing appears in the network log) and the error banner stays. Expected: Retry sends the order again (once!) and shows the result.

   Reveal answer✓ I found this

How to simulate bad networks

You don’t need to ride an elevator all day. Every platform has tools to fake bad networks. Use them to find bugs quickly, then confirm the important ones in the real world.

iOSAndroidWeb viewsProxy toolsReal world

Network Link Conditioner on a real iPhone

1. Enable the Developer menu: connect the iPhone to a Mac with Xcode once, then turn on Settings → Privacy & Security → Developer Mode (iOS 16 and later) and restart.
2. Open Settings → Developer → Network Link Conditioner.
3. Pick a profile such as 3G, Edge, Very Bad Network, High Latency DNS or 100% Loss, and turn Enable on.
4. Test, then turn it off again. It stays on until you do, and it slows down every app on the phone.

You can also add your own profile with exact bandwidth, latency and packet loss values.

From Xcode: open Window → Devices and Simulators, select the connected device and use Device Conditions → Network Link to start a profile.

For the iOS Simulator: the simulator uses your Mac’s network. Install Network Link Conditioner from Apple’s Additional Tools for Xcode download and enable it in System Settings. Remember that it slows down your whole Mac.

Android Emulator

1. Open the emulator’s Extended controls (the ⋯ button in the side toolbar).
2. Go to Cellular and set Network type (e.g. GSM, EDGE, UMTS/3G, LTE, 5G), Signal strength and Data status (e.g. turn data off).
3. For offline tests, pull down the quick settings inside the emulator and turn on Airplane mode, or turn Wi-Fi and mobile data off separately.

You can also start the emulator with network options, e.g. emulator -avd Pixel_8 -netdelay gprs -netspeed edge.

Real Android devices have no built-in throttling, so use airplane mode, Wi-Fi/mobile data toggles, Data Saver (Settings → Network & internet), a proxy tool, or a router that can limit speed. In Developer options, Mobile data always active keeps cellular on while Wi-Fi is connected, which affects how quickly the phone can switch networks; test with it on and off if network switching matters.

Many apps show some screens as web pages inside the app (web views), and mobile websites are tested in the browser.

1. Open Chrome DevTools → Network (or the Network conditions panel).
2. Use the throttling dropdown: presets like Slow 4G, 3G and Offline, or add a custom profile with your own download, upload and latency values.
3. For an Android web view, connect the device (debug build with web view debugging enabled) and open chrome://inspect in desktop Chrome. For iOS web views, use Safari → Develop on the Mac (the app must allow inspection).

Throttling in DevTools only affects that browser tab, not the rest of the app. See DevToolsDevToolsDeveloper tools built into browsers for inspecting pages, network traffic and errors.Open in glossary →.

Proxy tools like Charles and Proxyman can throttle all traffic from a phone that goes through them:

• Charles: Proxy → Throttle Settings… → enable throttling and choose a preset (e.g. 3G) or set bandwidth and latency yourself. You can limit it to specific hosts.
• Proxyman: Tools → Network Conditions → create a rule for a domain with a preset or custom speed.

Proxies can also return errors, empty responses or HTML pages (great for captive-portal tests). Read the next lesson: Proxy Tools: Charles and Proxyman.

Simulators are great, but nothing beats reality. Plan a short “walking test” for critical flows like checkout, sending messages or uploading:

• Start a payment on Wi-Fi and walk out of range so the phone switches to mobile data.
• Use the app in an elevator, a basement, an underground car park or a train.
• Try a hotel, airport or café Wi-Fi with a login page.
• Turn on a VPN, and try Low Data Mode / Data Saver.
• Test on a real deviceReal deviceA physical phone or tablet used for testing, as opposed to an emulator or simulator.Open in glossary → with a cheap prepaid SIM on a slower network.

Write down where you were and what the phone showed, because real-world bugs can be hard to reproduce.

Example test cases

Checklist

Network conditions checklist

0 of 12 checked

Copy

• Every data screen shows a loading state on slow 3G / Edge
• Submit buttons are disabled while waiting; double taps never create duplicates
• Requests time out in a reasonable time; no endless spinners
• Error messages are human-readable and offer a next step
• "Try again" buttons really send a new request
• Offline: cached content is shown and clearly marked as offline / last updated
• Actions done offline are queued with a visible status, or clearly blocked
• Switching Wi-Fi ↔ mobile data mid-request loses no data and creates no duplicates
• Going through an elevator/tunnel (10–60 s offline) recovers without a restart
• Captive portal Wi-Fi and unexpected HTML responses do not crash the app
• VPN, Low Data Mode and Data Saver do not break core flows
• Network simulation tools are turned off again after testing

Check your understanding

Quick quiz

0/5 answered · 0 correct

1. 1.A screen with many small requests feels slow on 3G, even though each response is tiny. What is most likely the problem?

   ALow bandwidthBHigh latencyCToo much storage usedDDark mode

2. 2.The spinner never stops when the network loses packets, and the "Retry" setting makes no difference. What is missing?

   AA cacheBA timeoutCA bigger image sizeDA push notification

3. 3.On a slow network, a user taps "Pay" twice and is charged twice. Which fixes help? (Pick the best answer.)

   AMake the button biggerBDisable the button while waiting and make the server ignore duplicate requestsCShow a toast after paymentDIncrease the timeout to 5 minutes

4. 4.The hotel Wi-Fi shows full bars, but the app crashes on launch. What is a likely cause?

   AA captive portal returns an HTML login page instead of JSONBThe phone is in dark modeCThe battery is lowD5G is too fast

5. 5.Which tool slows down the network for every app on a real iPhone?

   AChrome DevTools throttlingBNetwork Link Conditioner in Settings → DeveloperCAndroid emulator Cellular settingsDLow Power Mode

Key takeaways

• Test how the app behaves on slow, flaky and missing networks, not the network itself.
• Latency slows down chatty apps, bandwidth slows heavy content, packet loss causes random hangs and failures.
• Good apps show loading states, use timeouts and sensible retries, explain errors in plain words, cache content (clearly labeled) and queue offline actions.
• The biggest risks are infinite spinners, double submits, silent data loss and stale data shown as current.
• Simulate with Network Link Conditioner (iOS), emulator cellular settings (Android), DevTools (web views) and proxy throttling, then confirm critical flows in the real world.
• Always switch simulation tools off when you’re done. Related: network throttlingNetwork throttlingDeliberately slowing the connection to test how an app behaves on poor networks.Open in glossary →.