---
title: "Real devices vs emulators and simulators: which mobile flows need a physical device"
description: "Which mobile flows simulators and emulators can test on every PR, which need a physical device, and how to split the suite between them."
canonical: "https://momentic.ai/blog/real-devices-vs-emulators-simulators"
last-updated: "2026-11-02T19:11:43Z"
---

# Real devices vs emulators and simulators: which mobile flows need a physical device

URL: https://momentic.ai/blog/real-devices-vs-emulators-simulators

[blog](/blog) [/ resources](/blog/category/resources)  / real-devices-vs-emulators-simulators

Resources

Which mobile flows simulators and emulators can test on every PR, which need a physical device, and how to split the suite between them.

Wei-Wei Wu

CEO, Momentic

## TL;DR

- Run [iOS simulators](/ios-testing) and Android emulators on every PR to catch app logic and UI regressions without waiting for physical devices.
- Before release, run a short physical-device pass for camera, NFC, push delivery, biometrics, performance, and OEM-specific behavior. Simulated inputs cannot establish how sensors, device hardware, or [vendor](/blog/evaluate-ai-test-automation-vendors) firmware behave.
- Keep the real-device pass scoped to flows your app uses. Device clouds provide hardware access, but adding them to every PR increases CI cost and can introduce device availability delays.
- Momentic runs mobile tests on iOS simulators and [Android emulators](/android-testing) only. Use a separate physical-device service for the release pass.

## What simulators and emulators actually emulate

A simulator or emulator can run much of your app’s code without reproducing the phone that customers hold. Apple’s iOS Simulator runs an app built for the simulator against simulated iOS frameworks on a Mac. An Android emulator runs Android in a virtual device using an ARM or x86 system image. Both can exercise navigation, form handling, API calls, and UI rendering, so they can catch many regressions introduced by a PR.

The app binary must match the environment. An iOS simulator needs a simulator-compatible build rather than the build installed on an iPhone. An Android emulator needs an APK compatible with its virtual device. Whether you provision the virtual device locally or on a remote host, installing the build there does not give the test access to physical sensors or the firmware on a customer’s phone. Momentic’s mobile tests run on iOS simulators and Android emulators, not physical devices.

A passing virtual-device test therefore gives you evidence about the app’s software behavior in that environment. It cannot establish how a camera sensor responds, how an OEM-modified Android build behaves, or how the app performs on a particular phone under load. Those checks need a physical device.

## Which mobile flows need a physical device

Simulators and emulators can verify most app logic and UI behavior before release. A physical device becomes necessary when a flow depends on a sensor, real network delivery, device performance, or an OEM’s version of Android.

| Flow | What a simulator or emulator catches | What needs a physical device |
| --- | --- | --- |
| Camera | Permission handling and app behavior with a supplied image or video feed. | Autofocus, exposure, low-light capture, and camera switching depend on real optics and drivers. |
| NFC | App behavior after a mocked scan result, where the test setup supports one. | Tag detection, read distance, and contactless interactions depend on an NFC radio and antenna. |
| Face ID or fingerprint | Success, failure, and cancellation paths triggered through simulated biometric responses. | Enrollment, sensor failures, and the experience of authenticating with a face or finger require the hardware. |
| Push notifications | In-app handling of a test notification. Some emulator setups can also receive remote pushes. | End-to-end delivery, wake-up behavior, and notification presentation should be checked on a device with the intended OS and network conditions. |
| Performance, heat, and battery | Slow app code or obvious resource spikes under repeatable test conditions. | Thermal throttling and battery drain depend on physical silicon, cooling, and battery hardware. |
| OEM skins and fragmentation | Behavior on the Android versions and virtual device configurations you run. | Vendor permission screens, background restrictions, and firmware changes require devices running those OEM builds. |
| Bluetooth and GPS | App logic with mocked locations or simulated peripheral responses. | Pairing, radio dropouts, GPS drift, and recovery after signal loss depend on real radios and surroundings. |
| App size and cold start on low-end phones | Package-size checks and repeatable startup tests in a virtual configuration. | Install experience and cold-start time need measurement on the storage, memory, and processor your users have. |

Choose physical devices based on the flows your app actually uses. A banking app with contactless payments needs an NFC pass, while an app that never uses NFC does not. For either app, [simulator and emulator](/blog/emulators-vs-simulators-in-mobile-testing) tests remain useful for exercising the surrounding UI and error handling before the hardware check.

## Cost and speed trade-offs: device clouds vs emulators in CI

Running the full mobile suite on physical devices can make every PR slower and more expensive. A hosted emulator or simulator can run alongside other CI jobs when capacity is available. A physical-device run needs an available handset with the right OS version, and a device-cloud queue may delay the job before testing starts.

The cost comparison depends on how often you run the suite. Momentic charges credits for hosted simulator and emulator runs, so estimate PR-stage usage by multiplying credits per run by expected run volume. The current credit rate is not provided here, so check your plan before converting that estimate to dollars. For a [device cloud](/blog/real-device-cloud-testing), include any session charges or reserved-device costs in the estimate, along with queue time in the CI latency you measure. Neither option has unlimited parallel capacity.

BrowserStack, Sauce Labs, and Firebase Test Lab provide access to real hardware that virtual devices cannot reproduce. Use that access for flows whose behavior depends on sensors, device performance, or manufacturer software. Keep the broader app-logic and UI suite on emulators or simulators for PR checks, where repeated runs would otherwise consume device time without testing those hardware differences.

## The recommended split: emulators on every PR, real devices before release

Run the core iOS simulator and Android emulator suites on every PR. Use them to gate merges on navigation, forms, permissions UI, and other app behavior that does not depend on physical hardware. Keep these runs focused enough to return a useful result while the PR is still under review.

In CI, build and upload the app assets, assign a channel and tag to identify the build, and run the mobile suites in parallel. Momentic can run the simulator and emulator tests at this PR stage. A failing test should block the merge until you determine whether the app regressed or the test needs attention.

Gate releases on a smaller physical-device pass. Choose devices and flows based on what the app uses, such as camera capture, NFC reads, biometric enrollment, push delivery, and cold starts on lower-end phones. Include an Android device with a relevant OEM skin if your users depend on one. Run that pass nightly as well when release-only feedback would arrive too late to investigate. Physical-device checks cover hardware and device-specific behavior that the PR suite cannot verify.

## Where Momentic fits and where it doesn't

Momentic runs iOS tests on simulators and Android tests on emulators only. It does not support physical devices. Use it for frequent PR checks of app logic and UI flows, where a real sensor or a particular phone model is not part of what the test needs to verify.

For camera capture, NFC reads, push delivery, and biometric hardware behavior, supplement Momentic with a physical-device pass. Real devices also remain necessary for performance on low-end phones and OEM-specific bugs. A simulated fingerprint prompt can verify how your app handles authentication, but it cannot verify a physical sensor.

Keep the simulator and emulator suite on every PR, and run the narrower hardware checks before release. That split gives you frequent regression coverage without treating a virtual-device pass as proof that hardware-dependent flows work.

## Engineering takeaway

Run app logic and UI checks on emulators or simulators for every PR. Schedule a short physical-device pass before release for flows that depend on sensors, device performance, or OEM behavior. That split keeps routine feedback fast without treating a virtual device as proof that hardware-dependent flows work.

## Frequently asked questions

Do I need real devices, or are simulators and emulators enough?    Run simulators and emulators on every PR for app logic and UI regressions. Before release, test hardware-dependent flows on physical devices. Momentic runs mobile tests on simulators and emulators, not physical devices.    Which simulator gaps can cause production incidents?    A simulated camera can confirm that your app handles an image, but it cannot expose focus or permission behavior on a particular phone. Real devices can also reveal NFC read failures, delayed push delivery, and slow cold starts on low-end hardware.    How often should a real-device pass run?    Run a short pass before each release. Add nightly device runs when you change hardware-dependent flows often or need earlier feedback. Keep the pass scoped to flows and devices your users rely on.    Can I catch OEM skin bugs without physical devices?    Vendor-specific emulator images, where available, can reveal some layout or software behavior. They cannot reliably reproduce every interaction with OEM firmware, so verify release-critical OEM behavior on the affected hardware.

Still have additional questions?

## Keep reading.

[Resources   Replacing an in-office device farm: hosted emulators and parallel mobile test runs     How to retire an in-office device lab: compare device clouds, Firebase Test Lab and hosted emulators, size parallel runs and keep a few real devices.     Wei-Wei Wu     9 min read](/blog/replace-device-farm-hosted-emulators)[Resources   Real Device Cloud Testing: How to Test Mobile Apps on Devices Virtually     What real device cloud testing is, what it does well, and where you might be better off relying on simulators and emulators to test devices virtually.     Wei-Wei Wu     9 min read](/blog/real-device-cloud-testing)[Resources   Emulators vs Simulators in Mobile Testing     The pros and cons of emulators vs simulators in mobile testing, and how each option can help your team release faster and catch defects earlier.     Wei-Wei Wu     8 min read](/blog/emulators-vs-simulators-in-mobile-testing)

## Close the feedback loop.

Point Momentic at your app. Free to start, no credit card.

[Try for free](https://app.momentic.ai/signup) [Contact sales](/sales)