Mobile Testing
Simulators Catch Most Bugs. Real Devices Catch the Ones That Matter
Nebojsa Covic TabasevicJun 26, 20264 min read
Simulators are fast, cheap to scale in CI, and fine for the majority of a mobile test suite. The mistake is assuming they're sufficient for all of it.
What simulators get right
Most functional bugs don't care about hardware. Navigation flows, form validation, API integration, state management — a simulator catches these just as well as a real device, at a fraction of the cost and time.
- Fast enough to run on every pull request.
- Easy to parallelize across OS versions and screen sizes.
- No device farm scheduling or physical unit maintenance.
What only shows up on physical hardware
- Camera and sensor behavior — simulators fake these inputs; real lighting conditions and sensor noise expose bugs that never appear in a simulated feed.
- Battery and thermal throttling — a feature that performs fine for two minutes can degrade once the device heats up under real load.
- Network switching — moving between Wi-Fi and cellular, or dropping to a weak signal, behaves differently on real radios than on a simulated connection.
- Push notifications and background execution — OS-level battery optimization and background app limits are inconsistent across real manufacturers and are hard to reproduce in a simulator.
A practical split
Run the full functional suite on simulators in CI on every commit. Run a smaller, targeted suite on real devices — covering the sensor-dependent flows, older OS versions your users are actually on, and known problem models — before a release ships. That split keeps CI fast without giving up the coverage that actually prevents field bugs.