How to Test Mobile Apps on a Simulator or Emulator

Testing a mobile app on a simulator or emulator means running the app inside a virtual device – Android Studio’s Android Emulator (AVD) or Xcode’s iOS Simulator – installed on your development machine, then executing manual checks or automated test scripts (Espresso, XCTest, Appium) against that virtual device exactly as you would against a phone.

The setup differs by platform: Android’s emulator actually emulates hardware and can run on Windows, macOS, or Linux; Apple’s Simulator only runs on macOS and simulates the OS environment rather than full hardware. Both get you a working test target in minutes, for free, without a physical device.

This guide covers the part most emulator/simulator explainers skip: the actual steps to set one up and run a real test on it, what breaks along the way, and the specific conditions – not device or OS in general, but real hardware behavior – that neither virtual environment can reproduce no matter how it’s configured.

What You Need Before You Start

• For Android: Android Studio (free, Windows/macOS/Linux), a system image downloaded through the SDK Manager, and enough free disk space – a single system image plus its AVD instance commonly runs 4-10GB.
• For iOS: A Mac running Xcode (free from the Mac App Store). There is no way to run Apple’s actual Simulator on Windows or Linux – it’s tied to Xcode’s toolchain.
• Either way: the app build you want to test (an .apk/.aab for Android, or an .app/.ipa built through Xcode for iOS) and, if you’re testing automated scripts rather than clicking around manually, your test framework already set up (Espresso/UI Automator for Android, XCTest/XCUITest for iOS, or Appium if you want one script to target both).

Setting Up and Running Tests on the Android Emulator (AVD)

1. Open Device Manager. From Android Studio’s Welcome screen: More Actions > Virtual Device Manager. From an open project: View > Tool Windows > Device Manager, then the + icon and Create Virtual Device.
2. Pick a hardware profile. Choose a device definition (Pixel models are the default recommendation). Profiles with the Google Play logo are the ones that ship with the Play Store app installed, not just Play services – that distinction matters later.
3. Choose a system image. Pick an API level at or above your app’s minSdk, and pay attention to architecture: Apple Silicon Macs (M-series) need an ARM64 system image; Intel Macs and most Windows/Linux machines use x86_64. Picking the wrong architecture for the host is one of the most common reasons a first-time AVD setup fails to boot or runs at a crawl.
4. Configure and finish. Set the AVD name, startup orientation, and – under Show Advanced Settings – RAM, storage, and the Emulated Performance: Graphics setting (Hardware, Software, or Automatic; Hardware uses the host GPU and is faster where supported). Click Finish.
5. Launch it. From the Device Manager’s Virtual tab, click the launch (play) icon next to the AVD. First boot is noticeably slower than subsequent ones because the image is cold-starting.
6. Install and run the app. Run it directly from Android Studio’s Run button with the AVD selected as the target, drag an .apk onto the running emulator window, or use adb install app.apk from the terminal.
7. Run your tests. Instrumented tests (Espresso, UI Automator) run the same way they would on a physical device – through Android Studio’s test runner or ./gradlew connectedAndroidTest with the AVD running and visible to adb devices. For running the same suite at scale in CI rather than one emulator at a time, Android Studio’s Gradle Managed Devices feature provisions and tears down emulator instances automatically per build.

Things that trip people up: Intel’s HAXM accelerator, long the default way to speed up the Android Emulator, has been deprecated since 2023 – current setups rely on Windows Hypervisor Platform (WHPX) or AEHD on Windows and Apple’s built-in Hypervisor.Framework on macOS instead, so an old HAXM-based setup guide will steer you wrong on a fresh machine. A non-Play-Store system image will run your app fine but can’t test any flow that depends on the actual Play Store app (in-app updates via Play Core, licensing checks) – use a Google Play image if that matters. And the emulator’s Extended Controls panel is more capable than most people assume: it can simulate cellular network type and signal strength, battery level and charging state, GPS routes from a GPX/KML file, incoming calls and SMS, and several device sensors (light, pressure, humidity, proximity) – genuinely useful for exercising conditional app logic without touching a real network.

Setting Up and Running Tests on the iOS Simulator (Xcode)

1. Install the simulator runtimes you need. In Xcode, go to Xcode > Settings > Platforms (or Components in older Xcode versions) and download the iOS versions you want to test against – Xcode ships with the latest by default, but older OS versions need a separate download.
2. Pick a simulator. Open your project and use the device/scheme selector at the top of the Xcode window to choose a device model and iOS version combination (e.g., iPhone 16, iOS 18.2).
3. Build and run. Product > Run or ⌘R builds the app and launches it in the selected Simulator.
4. Run your tests. Use the Test navigator (⌘6) to run individual XCTest/XCUITest cases or the full suite against the running Simulator, or drive it from the command line with xcodebuild test -destination 'platform=iOS Simulator,name=iPhone 16,OS=18.2' – the same command CI pipelines typically call.
5. Simulate specific conditions. The Simulator’s Debug menu (in newer Xcode, Features menu) can trigger a simulated location, a low-memory warning, or a slow animation for visual debugging. Push notifications can be tested without a real device by running xcrun simctl push booted <bundle-id> payload.json or dragging an .apns payload file onto the Simulator window.

Things that trip people up: simulated push notifications bypass Apple’s actual push network (APNs) entirely, so a payload that “delivers” correctly in the Simulator only proves your app can handle a push – it doesn’t prove real APNs delivery works, which still needs a real device before shipping anything that depends on it. Camera capture, CoreNFC, real Bluetooth peripherals, and true Face ID/Touch ID hardware aren’t available in the Simulator at all – Face ID can be “enrolled” and toggled for UI testing, but there’s no actual biometric sensor being exercised. And because the Simulator runs your app as a Mac-native binary against a simulated iOS environment rather than translating ARM instructions the way an emulator does, an app that behaves fine in the Simulator can still hit an architecture-specific bug that only shows up compiled for a real iPhone’s hardware.

What Emulators and Simulators Are Genuinely Good At

It’s worth saying plainly: for a large share of day-to-day mobile QA, this is the right tool, not a compromise. Both are free, start in seconds after the first boot, don’t require managing a device inventory, and are easy to script into a CI pipeline where you might want a dozen parallel instances for a pull-request check. The Android Emulator’s extended controls (network conditions, battery states, GPS routes, sensor values) cover a genuinely wide range of conditional logic testing without any physical hardware. For catching layout regressions, running unit and most UI automation, and getting fast feedback during active development, reaching for a real device every time would just be slower for no real accuracy gain at that stage.

Where Simulator/Emulator Testing Hits a Wall

The honest limitation isn’t that emulators and simulators are “inaccurate” in general – it’s that a specific, predictable set of conditions can’t be reproduced on virtualized hardware no matter how the AVD or Simulator is configured:

• Real thermal and battery behavior. Battery drain and thermal throttling under sustained load are properties of physical silicon and casing – a simulated battery percentage isn’t the same as a phone actually heating up and downclocking mid-test.
• OEM skins and manufacturer customizations. Samsung’s One UI, Xiaomi’s MIUI/HyperOS, and similar overlays change permission dialogs, notification behavior, and background-process limits in ways a stock AVD image doesn’t replicate.
• Real network variance. Simulated network profiles change reported speed and signal strength; they don’t reproduce a real cell tower handoff, carrier-specific throttling, or the packet loss pattern of an actual weak-signal area.
• Real biometric and sensor hardware. Fingerprint and Face ID can be toggled as pass/fail states for UI testing, but neither environment exercises the actual sensor hardware or its failure modes.
• Device-model-specific bugs. A bug that only reproduces on a particular chipset, RAM configuration, or screen panel simply doesn’t exist on a virtual device built from generic specs.

This is where a real device cloud earns its place in the pipeline rather than replacing the Simulator or Emulator: running the same Appium, Espresso, or XCTest suite you already wrote against actual Android and iOS hardware closes exactly the gaps above – real thermal and battery readings, real OEM builds, real carrier network conditions, and no host-machine dependency – without requiring a rewrite of the test scripts themselves. Pcloudy’s real device cloud runs Appium, Espresso, XCUITest, and Selenium scripts as-is against 5,000+ real Android and iOS devices.

Emulator vs. Simulator vs. Real Device: Quick Comparison

How to Choose Your Setup

There isn’t one right answer here – the right setup depends on what stage of the pipeline you’re testing at and what you’re trying to catch:

• Early development, fast iteration, no release decision riding on it yet: the Emulator or Simulator is the right call, full stop. It’s faster to spin up, free, and plenty accurate for the layout, logic, and unit-level bugs you’re catching at this stage.
• CI pipelines running dozens of parallel checks per pull request: emulators and simulators (or Gradle Managed Devices for Android) are usually the more practical choice on cost and scale grounds – provisioning that many real-device sessions for every PR is rarely worth it unless the team is specifically hunting device-specific regressions.
• Pre-release validation, or bug reports tied to specific device models, OS versions, or real-world network/battery complaints: this is where virtual devices stop being sufficient regardless of how well-configured they are – move the same test suite onto real hardware, since OEM skins, real thermal behavior, and carrier network conditions don’t reproduce on a virtual device no matter how it’s tuned.
• Apps where a sensor, biometric flow, or hardware-dependent feature (camera capture, NFC, real GPS drift, Bluetooth peripherals) is core to the product: real devices are close to mandatory for that specific flow, even if the rest of the app is tested fine on virtual devices – test the hardware-dependent path on real hardware and everything else wherever it’s most efficient.

Frequently Asked Questions

Can I test an iOS app without a Mac?
Not with Apple’s own Xcode Simulator – it only runs on macOS and is tied to the Xcode toolchain. Third-party browser-based iOS simulation services exist for basic checks, but they simulate the environment rather than running Apple’s actual Simulator, and they’re a different tool for a different (non-Mac) use case than the workflow in this guide.

Is the Android Emulator slower than a real device?
It depends on host hardware and configuration more than on the emulator itself. A modern machine with hardware graphics acceleration enabled and the correct system image architecture for the host (ARM64 on Apple Silicon, x86_64 elsewhere) runs close to real-time for most apps; a mismatched architecture or software-rendered graphics setting is the usual cause when it feels sluggish.

Do I need Appium to test on an emulator or simulator?
No – Android Studio’s Espresso/UI Automator and Xcode’s XCTest/XCUITest both run natively against the emulator or simulator without Appium. Appium is worth adding when you want one test script to target Android and iOS (or emulator, simulator, and real device) without maintaining separate native test suites.

Can push notifications be tested on the iOS Simulator?
Yes, using xcrun simctl push or by dragging an APNs payload file onto the Simulator window – but this bypasses Apple’s real push network (APNs) entirely, so it verifies your app’s handling logic, not real-world delivery. Confirm actual delivery on a real device before shipping anything that depends on it.

Why won’t my Android emulator boot after I set it up?
The most common cause is an architecture mismatch between the system image and the host machine – an x86_64 image on an Apple Silicon Mac, or vice versa. The second most common cause is hardware acceleration not being available or enabled (check the Emulated Performance: Graphics setting and confirm virtualization is enabled on the host).

What’s the difference between an emulator and a simulator?
An emulator (like the Android Emulator) reproduces both the hardware and the operating system, running your app’s actual compiled code against emulated hardware. A simulator (like Apple’s iOS Simulator) reproduces the OS environment and APIs but runs your app as a native binary on the host Mac’s own hardware – which is why it’s faster to launch but architecturally different from a real iPhone.

Can I run automated tests on an emulator in a CI pipeline?
Yes – this is one of the most common use cases. Android’s Gradle Managed Devices and standard xcodebuild test commands against a named Simulator destination both integrate into Jenkins, GitHub Actions, GitLab CI, or CircleCI without much extra setup.

Does the Android Emulator support testing Google Play Store features?
Only if you picked a system image with the Google Play Store logo when creating the AVD. Images that include just Google APIs (not the Play Store app itself) can’t test in-app update prompts or Play-Store-dependent licensing flows.

Is fingerprint/biometric testing possible on an emulator or simulator?
Both support simulated versions – the Android Emulator can simulate up to 10 fingerprint scans (on API 23+; not available on Wear OS or API 22 and below), and the iOS Simulator lets you enroll and toggle a simulated Face ID/Touch ID match or non-match. Neither exercises actual sensor hardware, so a biometric flow should still get a pass on a real device before release.

When should I stop testing on emulators/simulators and move to real devices?
Not at a fixed point in every project – it depends on what you’re validating. Move a specific test to real hardware whenever it depends on a condition virtual devices can’t reproduce: real network/carrier behavior, OEM-skin-specific UI, actual thermal/battery readings, or a bug report tied to a particular device model. Everything else – layout, logic, most UI automation – can reasonably stay on the emulator or simulator for as long as it keeps catching what it’s supposed to catch.

Related Reading

• Emulator vs. Simulator vs. Real Device: When to Use Each – the decision framework for choosing between them, if this guide’s “How to Choose” section needs more depth on the trade-offs.
• How Does an Emulator Work? A Complete Guide – the architecture and internals behind what this guide shows you how to operate.
• Android App Testing on Real Devices – run the same Espresso/Appium scripts from this guide against real Android hardware.
• Real Device Cloud for App Testing – 5,000+ real Android and iOS devices for the validation stage where virtual devices stop being enough.