Real device vs emulator: when each is enough

There are two unhelpful positions on this. One says emulators are fine for everything (cheaper, faster, scriptable). The other says nothing counts unless it's on a real device (real hardware, real users). Both are wrong because they're answering the wrong question. The right question is per-test: does this particular check depend on something only real hardware has? Most don't; some absolutely do. Getting that split right is the whole skill, and it's part of a sane mobile coverage strategy.

What emulators/simulators are genuinely good for

For a large share of testing, an emulator is not a compromise — it's the efficient choice:

• Functional and UI logic. Does the flow work, does the form validate, does navigation behave. The app logic doesn't know it's on an emulator.
• Fast iteration during development. Quick reruns, easy resets, scriptable in CI. Cheap to spin up many configurations.
• Multiple screen sizes and OS versions for layout. Checking a layout across a range of resolutions and densities is faster and cheaper on emulators.
• Automated regression in CI. Most of your automated mobile suite can run on emulators for speed and cost, with real devices reserved for the parts that need them.

What needs a real device

Some things an emulator either fakes or can't represent, and these are exactly where real-device bugs come from:

• Performance and feel. Real CPU/GPU, real memory pressure, real thermals. An emulator on a powerful laptop hides the jank a mid-range phone shows. Anything performance-sensitive needs real hardware.
• Sensors and hardware. Real camera, GPS, accelerometer, biometrics, NFC, Bluetooth. Emulated versions are approximations at best.
• Network reality. Real cellular, real handoffs, real flakiness — the exact conditions behind the Wi-Fi-only bug. Emulators run on your stable office connection.
• Battery, interruptions, and OS behaviour. Real battery drain, real OEM background-killing, real incoming calls and notifications interrupting your flow.
• Touch, gestures, and ergonomics. How it actually feels in a hand — gesture accuracy, reachability, haptics — is invisible on a clicked-through emulator.
• Final pre-release confidence. Whatever else you do, the release candidate gets exercised on real devices.

Choosing real device vs emulator

• Functional/UI logic, fast iteration, layout across sizes, CI regression → emulator is enough
• Performance, feel, and jank on mid-range hardware → real device
• Camera, GPS, biometrics, NFC, Bluetooth, sensors → real device
• Real-world network conditions and handoffs → real device
• Battery, interruptions, OEM background behaviour → real device
• Gesture accuracy, haptics, ergonomics → real device
• Final release-candidate sign-off → real device
• Decide per test: does this check depend on real hardware? If not, the emulator is fine

My opinion: a pyramid, not a side

The model I argue for is a pyramid. A wide base of emulator testing — fast, cheap, most of the functional and regression work — topped by a deliberate layer of real-device testing for performance, hardware, network, and final sign-off. Insisting on real devices for everything is slow and expensive and buys you nothing on tests that don't touch hardware. Insisting on emulators for everything ships the performance, sensor, and network bugs that only real hardware reveals. "Enough" is not a fixed answer; it's a judgement per test about whether the thing you're checking lives in software or in the device. Make that call deliberately and you get most of the cost savings without the blind spots.