The very first decision you have to make when setting up a mobile AI agent (an AI agent that taps, scrolls, and reasons through Android or iOS apps) is whether to use an emulator or a real device. That choice decides how fast your agents gets flagged as bots, whether biometric and sensor flows work at all, and what your bill looks like at the end of the month. Let’s explore how you can best make that choice for your own use case, through a technical breakdown of detection, app compatibility, sensors, iOS, cost, and scale.
Where real devices make most sense
Hardware Stealth
On Android, Google's Play Integrity API became the primary attestation standard in early 2025, and it issues a device verdict. A genuine, Play Protect-certified phone earns the strong verdict, MEETS_DEVICE_INTEGRITY. An emulator, at best, gets the weaker MEETS_VIRTUAL_INTEGRITY, and some apps simply refuse to run without the strong one. iOS has its own version of this through App Attest and DeviceCheck. Banking, streaming, and social apps routinely sniff out emulator fingerprints and block them.
Some examples of apps that need a physical device include Reddit, Hinge and the UBS Access app.
Sensor Hardware
Emulators are virtual, and hence by nature don’t have any sensors, and instead have to input fake data. That typically isn’t an issue, but does block certain workflows where real sensor input is mandatory, such as any biometric prompt and camera workflow.
Virtual phones are slowly getting better at handling sensors. For example, Mobilerun’s cloud phones now come with GPS, which does a good job simulating your device’s physical location to be around the same area as your IP proxy. But for many other sensors, there is no other choice than to use a real phone.
The case for emulators
The biggest advantage for using emulators is the ease and low cost of setup and maintenance that comes with virtual devices, something that remains impossible to do with real phone hardware, not to mention the speed and performance gain.
Take iOS for example. Automating a real iPhone means going through Appium's XCUITest driver, which means building WebDriverAgent, dealing with Xcode signing, enabling Developer Mode on every device, and all of this before running a single task, without any guarantee that your device isn’t going to get insta-flagged. A simulator skips nearly all of it and boots in seconds, and even if it gets flagged, can quickly be reset and retried with.
Having instant access and low costs also makes emulators the best way to scale operations, with acquiring a new virtual phone is as simple as clicking a button in a portal. So, unless your workflows have very specific stealth or sensor requirements, cloud phones are the most scalable and hassle-free way to go.
So which should your agent(s) use?
Reach for emulators when you're doing scripted QA, CI regression, layout validation, or fast iteration. Reach for emulators when cost and parallelism matter most and stealth isn’t priority #1. Go with real devices when the target app detects and blocks emulators, when the flow needs access to real biometrics, sensors, or networking, or when the task needs to look like a genuine user as much as possible. Automating a consumer app you don't control? Assume it has anti-emulator defenses, and plan for real hardware, but if a one-time detection isn’t an issue, then try cloud phones first.
For most teams building real mobile automation, the real answer is both. Emulators upstream for speed, cost and flexibility, while real devices for the flows that demand authenticity. The boring answer is that most teams use both, picking devices based on the needs of each specific workflow.
Top comments (1)
the hybrid approach makes sense