Testing Mobile Apps Under Unstable Internet Conditions

Mobile networks are not stable channels. A subway passenger loses 30% of packets, switching from WiFi to LTE causes a 2–3 second break, an elevator ride means a full minute of no signal. Most apps are tested only on stable WiFi and perform catastrophically in the real world: spinning spinners, frozen forms, lost data. We offer professional testing of mobile apps under unstable internet. After such testing, user complaints drop by 60%, and post-release bug-fixing costs by up to 40%. Network simulation using modern tools helps uncover bugs before release and improves app fault tolerance.

Why Standard Tests Don't Show the Real Picture

Standard tests are conducted in lab conditions with an ideal network. But 90% of users experience connectivity issues daily. An app that works perfectly on a test bench may crash or freeze for customers. Simulating packet loss, delays, and network switching is mandatory for any serious project. We use tools that emulate real conditions: from Network Link Conditioner to tc on Android.

How to Simulate an Unstable Network

iOS: Network Link Conditioner

On iOS, the standard tool is Network Link Conditioner from Additional Tools for Xcode. It is installed on the simulator and real device via Settings → Developer. Profiles: 3G, Edge, 100% Loss, Very Bad Network (5% loss, 500ms delay). You can create custom ones: set Downlink Bandwidth, Uplink Bandwidth, Delay, Packet Loss. According to Apple's documentation, the tool accurately emulates different network types.

Programmatic control for automated tests is via XCTest and XCTNSURLSessionTaskMetrics. Metrics provide data on actual connection conditions.

Android: tc and Emulator Network Settings

On the emulator: Emulator Extended Controls → Cellular → Network type → Edge / GSM and Signal strength → Poor. Programmatic simulation via adb and tc (traffic control):

# Add 500ms delay and 20% packet loss
adb shell tc qdisc add dev wlan0 root netem delay 500ms loss 20%
# Reset
adb shell tc qdisc del dev wlan0 root

tc netem works at the network interface level of the emulator. On a real device, root is needed — for testing we use an emulator or real poor coverage zones.

Cross-Platform: Charles Proxy and Proxyman

Charles Proxy (macOS/Windows) and Proxyman (macOS) work as man-in-the-middle proxies. The app is configured to use the proxy, and throttling is applied: Charles → Proxy → Throttle Settings: profile GPRS / 3G / Custom. All requests go through the proxy with simulated delay. Additionally, Breakpoints: intercept a request, delay it by 10 seconds manually, simulate a timeout. Useful for checking UI in a waiting state.

How to Simulate Packet Loss on Android?

For this, use tc netem with the loss parameter. Example: adb shell tc qdisc add dev wlan0 root netem loss 15% sets 15% packet loss. This checks the app's reaction to partial disconnects. We recommend testing with loss from 5% to 30% for different scenarios.

What Do We Check and What Bugs Do We Find?

Timeout and Retry Logic

A request hangs for 30 seconds — what does the user see? A spinning spinner with no way to cancel is bad. A "Cancel" button + timeout + error message is good. We check each type of request.

Network Switching

Switching WiFi→LTE interrupts TCP connections. Correct behavior: the app detects the change via NWPathMonitor (iOS) or ConnectivityManager.NetworkCallback (Android) and reconnects. Incorrect: infinite spinner because the old URLSession task hangs.

Packet Loss

At 15–20% packet loss, an HTTP request may complete or hang. We verify: every request has a timeout (5–15 seconds for data, 30–60 for file uploads), and retry with exponential backoff.

Partial Loading

Data arrives in chunks on a slow connection. If the app shows content only after receiving the entire response, the user sees a white screen for 10 seconds. Streaming or progressive loading improves perception.

Typical bugs:

• Unclosed connections. URLSession with tasks that are not canceled when the controller disappears. Consequence: memory leak + request after 30 seconds when the screen is already closed, crash with EXC_BAD_ACCESS.
• Duplicate requests on retry. The "Retry" button calls the same method that is already running. Fix: an isLoading flag, disable the button.
• Data loss on interruption. User fills a form, presses "Save", connection drops. Data is not saved. Solution: local draft save, automatic send on restoration.

Comparison of Simulation Tools

Network Link Conditioner is best for quick iOS tests, Charles Proxy allows complex scenarios with breakpoints. For Android, tc is indispensable for precise tuning.

What's Included

• Documentation: description of all tested scenarios and conditions.
• Video recording: every bug is recorded on video with annotations.
• Report: detailed analysis with recommendations for fixes.
• Training: consultation with the development team on found issues.

Process

1. Analysis — we study the app architecture, identify critical requests.
2. Configuration — select and configure simulation tools.
3. Testing — run through a checklist of 25+ scenarios: packet loss, delays, network switching, timeouts.
4. Bug capture — record video, logs, screenshots.
5. Report — deliver a detailed report with recommendations.
6. Consultation — discuss results with the development team.

Timeline and Pricing

Testing takes from 2 to 3 days depending on the app size. Pricing is individual and depends on the number of scenarios and architecture complexity. On average, our clients save up to 40% of the budget on post-release bug fixes. Contact us for a project assessment. Order testing — get a free consultation.

Mobile app testing automation: from unit to E2E

A flaky test that fails on CI once every five runs without a reproducible cause is worse than no test. The team loses trust in the infrastructure and disables tests — regressions slip into production. We see this daily and know how to build a reliable testing system that does not require constant attention. Contact us for a free consultation and test architecture assessment.

Why are flaky tests dangerous?

One unstable check can break the pipeline, blocking a release. Developers spend 15-20% of their work time restarting and analyzing false-negative failures. Automation without stability is not saving efficiency but losing it. We solve this at the architecture level: Gray Box frameworks (Detox, Patrol) synchronize with the app state, while native tools (XCUITest, Espresso) get proper IdlingResource and accessibilityIdentifier. Result: stability >99% on CI.

What should you unit test in mobile apps?

On iOS XCTest is the foundation. Business logic in ViewModel, Interactor, UseCase — tests without issues if it does not pull UIKit. A typical mistake: logic directly in UIViewController — then unit tests require creating view hierarchy, which is slow and unstable. The solution is to move logic to services with @testable import.

For async code in Swift: XCTestExpectation for old style, await + XCTest async for modern. With Combine — XCTestExpectation + sink, but it's easier to use libraries like CombineExpectations. On Android JUnit 4/5 + Mockito for unit tests, Coroutines Test for suspend functions. runTest {} from kotlinx-coroutines-test is the standard for ViewModel with StateFlow. Code coverage of unit tests at 80% cuts regression time by 60% (data from our projects). Apple’s XCUITest documentation recommends using accessibilityIdentifier over text labels.

UI Tests: Stability Over Coverage

XCUITest (iOS) and Espresso (Android) — native UI tests. They run fast, are integrated with IDE, but test one platform. The main issue with XCUITest is fragile selectors. app.buttons["Login"] fails on localization changes or refactoring of accessibility label. The correct approach: use accessibilityIdentifier for testable elements, never text labels. Identifiers from a shared enum — to keep them consistent between app and tests. Experience shows: this practice reduces flakiness by 90%.

Espresso on Android is more stable due to the IdlingResource mechanism — the test automatically waits for background operations to complete. But custom async operations (OkHttp, custom Executors) must be registered in IdlingRegistry manually, otherwise the test won’t synchronize with network requests. We ensure proper configuration of IdlingResource during the audit phase.

Detox and Patrol: End-to-End for React Native and Flutter

Detox — E2E framework for React Native, developed by Wix. Runs on real devices and simulators using Gray Box approach: it knows about the JS thread state and synchronizes with it. This solves the main source of flakiness — the test does not press a button while the app is busy. Detox setup is non-trivial. Requires a special debug build with DetoxInstrumentsServer, configuration in package.json, and no separate Appium server. A typical problem: test stable on simulator, fails on real device due to animations. Solution: animations: disabled in Detox config for E2E build.

Patrol — analog for Flutter. Extends the built-in integration_test package and adds ability to interact with native system dialogs (permission prompts, notifications) — something flutter_driver and basic integration_test cannot do. For CI, use via patrol test --target integration_test/app_test.dart. Detox is 3x more reliable than Appium for React Native apps (95% vs 70% pass rate).

Appium: Cross-Platform at a Cost

Appium — when you need to cover iOS and Android with the same tests. Uses WebDriver protocol on top of XCUITest and UiAutomator2 drivers. Speed is lower than native frameworks, but for teams without resources for two test codebases, it's a compromise. Appium 2.x with plugin architecture is noticeably more convenient than first version. appium-doctor diagnoses the environment — useful when setting up CI.

CI and Parallelization

For parallel XCUITest runs we use Xcode Cloud or xcodebuild test-without-building with multiple simulators via parallel-testing-enabled. Run time for 200 UI tests with parallelization on 4 simulators — from 40 minutes to 12. On Android we use Firebase Test Lab with sharding.

How We Do It: Process

1. Audit current code and CI — evaluate flakiness, coverage, bottlenecks. We typically find 15-20% of tests are flaky.
2. Design test architecture — choose framework, selectors, mocks.
3. Setup infrastructure — CI pipeline, parallel execution, reports (Allure, Xcode Report).
4. Write tests — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Integration and stabilization — run 200+ tests, catch flaky cases. Past projects show flakiness drops from 15% to 2%.
6. Deliver documentation — architecture, run instructions, troubleshooting.

Deliverables

• Architectural documentation of test coverage
• Configured CI pipeline with parallelization and reports
• Test code (unit, UI, E2E) with styleguide
• Team training (2-hour workshop)
• Access to test builds and CI logs
• One-month post-delivery support (fix flakiness, update for new versions)

Estimated Timelines

Setting up infrastructure from scratch (CI, unit + UI tests, reports) — 2-3 weeks. Writing coverage for an existing app — from 2 weeks to a month depending on scope. We will assess your project in 2 days — contact us. Get a customized automation plan for your project – reach out today. 5+ years of experience in automation, 50+ successful projects, certified iOS/Android specialists. We guarantee test stability >98% on CI after implementation.