Real Devices, Emulators or a Device Cloud: How to Test Mobile Apps

Use both. Emulators and simulators are fast and free, so run them on every pull request for layout, logic and navigation. Real devices catch what emulators cannot: cameras, sensors, real memory limits, real networks, battery drain and maker-specific Android quirks. Test on real devices, your own or a device cloud, before every release. A device cloud makes sense once you need more than a handful of phones.

If you would rather have it tested for you, see how RAITHub would test this below. RAITHub tests iOS and Android apps on real devices and device clouds; it does not develop mobile apps.

What is the difference between an emulator, a simulator and a real device?

• Android emulator: a virtual Android phone that runs the real Android system image on your computer. Google says it "provides almost all the capabilities of a real Android device", including simulated calls, location, network speeds and sensors (Android Emulator).
• iOS Simulator: part of Xcode on a Mac. It runs your app compiled for the Mac's processor, not a full copy of iPhone hardware. Apple's Simulator guide notes that some hardware features must be tested on a device, and that the Mac's CPU, memory and network are likely to be very different in capacity and speed from a phone's (Apple: Testing and debugging in Simulator).
• Real device: a physical phone or tablet, either on your desk or hosted in a data centre and driven remotely through a device cloud.

What do emulators and simulators miss?

Area	Emulator or simulator	Real device
Layout, navigation, business logic	Reliable	Reliable
Camera, microphone, barcode and document scanning	Faked or unavailable	Real
Sensors: motion, proximity, barometer, ambient light	Simulated values at best	Real
Performance and memory	Runs on a fast computer, so hides slowness	Shows real start times and out-of-memory crashes
Network	Throttling is simulated	Real mobile networks, handovers and captive portals
Battery and heat	Not meaningful	Measurable
Maker-specific Android behaviour (custom skins, aggressive battery savers)	Stock Android only	Real
Biometrics, NFC, Bluetooth pairing	Partial or simulated	Real
Speed and cost per run	Fast, free, easy to run in CI	Slower; costs hardware or cloud minutes

Apple's own advice for review is direct: "thoroughly test on devices running the latest software and fix all bugs before submitting" (Apple App Review). A build that only ever ran in the Simulator has not met that bar.

Should you buy test phones or use a device cloud?

Own a small shelf of phones for daily hands-on testing, and rent breadth from a cloud. Owning every device you need gets expensive quickly: phones age, OS updates need managing, and someone has to keep them charged and enrolled. A device cloud hosts real phones and lets you run manual sessions or automated suites on them remotely.

Device cloud	Pricing model (list price, 7 October 2026)	Note
AWS Device Farm	$0.17 per device minute, first 1,000 minutes free; unmetered slots from $250 a month	Real Android and iOS devices (AWS Device Farm pricing)
Firebase Test Lab	Physical devices $5 an hour and virtual $1 an hour after daily free time	Deprecated, shutting down 30 September 2027 (Firebase Test Lab migration)
BrowserStack	Plans priced per user or per parallel test	Real iOS and Android devices for manual and automated testing (BrowserStack pricing)
Maestro Cloud	$250 per device a month	Hosted Android, iOS and web devices for Maestro flows (Maestro pricing)

If you use Firebase Test Lab today, plan the move now. Google recommends the Developer Device Platform on Google Cloud, which keeps Test Lab rates until 30 April 2027 and then changes to new pay-as-you-go and per-slot pricing. A cost breakdown across these options is in mobile app testing cost.

Which tests should run where?

A practical split for a small team:

When	Where	What runs
Every pull request	Emulator and simulator in CI	Unit tests, plus a short automated smoke flow on the core journey
Nightly	Emulators, plus a few cloud devices	The full automated regression suite
Before each release	Real devices: your shelf plus a cloud matrix	Full regression on the device matrix, manual exploratory testing, hardware features, performance on the oldest device
After a crash spike	The exact device and OS from the crash report	Reproduce first, then fix and add a regression test

Your test framework also limits where tests can run. Maestro supports Android emulators and physical devices, but lists iOS support for simulators (Maestro supported platforms). Detox runs on Android devices, with real iOS devices "not yet supported" (Detox on GitHub). Appium's XCUITest and UiAutomator2 drivers cover real devices on both platforms. Our comparison of Appium, Detox and Maestro covers this in more detail.

How do you run mobile tests on an emulator in CI?

This GitHub Actions job starts a hardware-accelerated Android emulator with the android-emulator-runner action and runs Maestro flows against your debug build. It assumes an earlier step built the APK at the path shown.

# .github/workflows/mobile-smoke.yml
name: mobile-smoke
on: pull_request
jobs:
  android:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - name: Enable KVM
        run: |
          echo 'KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"' | sudo tee /etc/udev/rules.d/99-kvm4all.rules
          sudo udevadm control --reload-rules
          sudo udevadm trigger --name-match=kvm
      - name: Install Maestro
        run: |
          curl -fsSL "https://get.maestro.mobile.dev" | bash
          echo "$HOME/.maestro/bin" >> "$GITHUB_PATH"
      - name: Run flows on an emulator
        uses: reactivecircus/android-emulator-runner@v2
        with:
          api-level: 34
          arch: x86_64
          script: |
            adb install app/build/outputs/apk/debug/app-debug.apk
            maestro test .maestro/

Keep this suite short, five to ten minutes, so it does not slow every pull request. The longer real-device run belongs before release. If emulator runs fail at random, read how to fix flaky end-to-end tests before adding retries.

How many real devices do you need?

Fewer than most teams expect, if they are chosen well. Four to eight devices across both platforms covers a first release: a current flagship, an older model, a low-memory Android phone, an unusual screen size and the previous OS version. Apple reported iOS 26 on 79% of all devices on 7 June 2026 (Apple App Store adoption), so iOS needs fewer OS versions than Android. Our mobile app testing checklist has a starting matrix. For mobile web rather than native apps, the trade-offs are different; see the cross-browser testing checklist.

Buy, build or hire?

Option	Choose this when	Trade-off
A tool or SaaS testing platform (a device cloud)	You have engineers who will write and maintain the suites	Pay only for device time; the test upkeep stays with you
Freelancers or crowdtesting	You want many real devices in many countries for a launch	Wide reach; report quality and repeatability vary
An in-house QA hire	Mobile is your core product and you ship often	Deep product knowledge; one person and one shelf of phones
A managed QAaaS team	You want a device strategy, the runs and the reports owned for you	A vendor relationship; insist that tests and reports stay yours

Why RAITHub for this

• Both layers. RAITHub sets up emulator runs in your CI and runs manual and automated passes on real devices and device clouds before release.
• A device matrix from your data. Devices are picked from your analytics and crash reports, not a generic list.
• Testing discipline you can check. RAITHub's web products carry large automated suites, such as 530+ tests on Sundor Skin. There is no published mobile case study yet, so we do not quote mobile results.
• Managed, not placed. Buy a monthly QA plan, a fixed-price audit, or a dedicated team that RAITHub manages and bills monthly. It is not staff augmentation.

When you don't need us

• Your app is small, on one platform, and a developer can test it on two or three phones before each release.
• You need native code written or fixed. RAITHub tests mobile apps but does not build them.
• You need hundreds of devices across many countries in one week. Crowdtesting is built for that.

How RAITHub would test this

• Device matrix: chosen from your analytics, crash data and target markets, split between owned devices and a cloud.
• CI layer: a short emulator and simulator smoke suite on every pull request, in your repository.
• Release layer: full regression and exploratory testing on real devices, including camera, sensors, network changes and the oldest supported phone.
• Reporting: each bug with device, OS version, build, steps and a recording, plus a go or no-go note per release.
• What you receive: the device strategy, the CI configuration and tests in your repository, and a handover document. IP is yours; an NDA is standard.

Scope, timeline and cost come in a written fixed quote after a free 15-minute technical audit. See mobile app testing and the QA as a service overview, or talk to us about your device strategy.

Frequently asked questions

Is emulator testing enough for a mobile app?

Not for a release. Emulators and simulators are good for logic, layout and fast CI feedback, but they miss real hardware, memory pressure, networks, battery and maker-specific Android behaviour. Test on real devices before each release.

What is the difference between an emulator and a simulator?

An Android emulator runs a real Android system image in a virtual machine. The iOS Simulator runs your app compiled for the Mac and imitates the iPhone environment, so it is further from real hardware, especially for performance and sensors.

Is a device cloud the same as testing on a real device?

Yes for the hardware: device clouds such as AWS Device Farm host physical phones. You drive them remotely, so physical actions such as walking between networks or scanning a real document are still easier on a phone in your hand.

What happens to Firebase Test Lab?

Google has deprecated it and will shut it down on 30 September 2027. Its recommended replacement is the Developer Device Platform on Google Cloud, which keeps Test Lab rates until 30 April 2027.

Can I test iOS apps without a Mac?

You can test a built iOS app on a device cloud from any computer, but building and running the iOS Simulator needs Xcode, which runs on macOS. Most teams use a Mac in CI or a hosted macOS runner for iOS builds.

Does RAITHub build mobile apps?

No. RAITHub tests iOS and Android apps on real devices and device clouds. Fixes are made by your developers or a mobile development studio.