Most teams should use both: emulators and simulators for fast, parallel, everyday CI runs, and a smaller set of real devices for final validation of hardware-specific behavior. Android emulators and iOS simulators run entirely in software, start in seconds, snapshot and restore state instantly, and can be scaled horizontally in a data center or CI runner far more cheaply than physical hardware, which makes them well suited to catching regressions on every commit. Real devices remain necessary for things software cannot fully reproduce, including actual camera and sensor behavior, cellular network conditions, GPU-specific rendering quirks, thermal throttling, and OEM skins from vendors like Samsung or Xiaomi that modify stock Android. A practical split many organizations use is the large majority of test execution on emulators and simulators for speed and cost, with a targeted smoke suite on a handful of real devices before release. Battery, camera, and biometric edge cases are the most common source of behavior that only shows up on physical hardware. Nanobase AI builds Mobile Test Lab environments that run the bulk of Android and iOS test execution on local emulators and simulators, with no physical devices required for day to day CI validation.
Why the debate is really about which bugs each catches
Framing emulators against real devices as a single either-or choice misses the point: each environment catches a different, mostly non-overlapping category of bug. Emulators are deterministic virtual machines running the same OS image every time, which makes them excellent for catching logic and layout regressions but structurally unable to reproduce anything tied to real silicon, real radios, or real thermal behavior. The question is not which environment is better, it is which category of defect you are trying to catch with a given test.
Technical gaps emulators cannot close
A few gaps are worth naming specifically because teams discover them the hard way in production rather than in CI. Root and integrity detection is the most common: many banking and payment apps use Play Integrity or DeviceCheck-style attestation that deliberately fails on an emulator, so any test touching that code path needs a real device or a build variant with attestation mocked out. GPU-specific rendering differences, particularly on OpenGL ES or Metal shader edge cases, only show up on the actual GPU silicon a user's device has. Thermal throttling, which changes app performance under sustained load, has no emulator equivalent at all. Cellular network behavior, including real carrier handoffs and signal degradation, differs from an emulator's simulated network profile in ways synthetic profiles cannot fully replicate. These are structural gaps in what an emulator can simulate, not tuning problems that a better emulator configuration will eventually close.
A practical allocation framework
| Test category | Best environment | Why |
|---|---|---|
| UI logic, navigation, forms | Emulator/simulator | Fast, deterministic, cheap to parallelize |
| Layout across screen sizes | Emulator/simulator | Device profiles cover most size/density combinations |
| Camera, GPS, biometric mocks | Emulator/simulator | Both platforms provide built-in mock hardware |
| Root/integrity-gated flows | Real device | Emulators fail attestation checks by design |
| GPU rendering edge cases | Real device | Emulator GPU emulation is not identical to real silicon |
| Thermal and sustained-load performance | Real device | No emulator equivalent exists |
| OEM-skin-specific behavior (Samsung, Xiaomi) | Real device | Manufacturer customizations aren't in stock emulator images |
Map each test category to its environment explicitly, rather than defaulting an entire suite to one or the other.
The Apple Silicon complication
Apple Silicon Macs changed simulator economics for the better: the iOS Simulator runs natively on ARM without translation overhead, unlike the older Intel-based simulators, which makes simulator-based CI meaningfully faster on M-series hardware. Android emulators have a parallel consideration: ARM-based system images run natively on Apple Silicon hosts, while x86_64 images require translation and run slower, so choosing the correct emulator image architecture for your CI host is worth checking explicitly rather than assuming a default image is optimal. On Apple Silicon hosts, an ARM system image is consistently faster than the x86_64 default many setups still use.
Frequently asked questions
What percentage of tests should run on real devices?
There is no universal number; it depends on your app's dependence on hardware-specific behavior. A common pattern is running the large majority of functional regression on emulators and simulators, reserving a small, targeted real-device smoke suite for camera, biometric, attestation, and performance-sensitive flows before release.
Do emulators catch layout bugs as reliably as real devices?
Yes, for standard layout issues. Both Android and iOS ship device profiles covering common screen sizes and densities, so layout regressions across phones, tablets, and foldables are reliably caught on emulators and simulators without needing physical hardware for that category.
Why does a test pass on an emulator but fail on a real device?
The most common causes are root or integrity detection blocking a code path, a GPU rendering difference, or a timing difference since emulators and real devices have different CPU and memory characteristics that can expose race conditions the emulator's timing happens to avoid.
Can we skip real devices entirely if our app has no camera or biometric features?
Possibly, but check for integrity or attestation checks (common in fintech and enterprise apps even without biometrics) and confirm your performance requirements don't depend on real thermal behavior before committing to an emulator-only strategy.
How Nanobase AI helps
Nanobase AI's Mobile Test Lab runs the bulk of Android and iOS test execution on local emulators and simulators, correctly matched to host architecture for speed, while helping clients identify exactly which flows genuinely require physical hardware rather than defaulting to real devices out of habit. This keeps CI fast without leaving hardware-specific defects uncaught. See our AI Mobile Test Lab overview or explore our solutions.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.