---
name: mobile-e2e-and-simulators
description: Running mobile tests that mean something — simulator versus device, and what only fails on real hardware.
when_to_use: You are the tester on a mobile team setting up or debugging end-to-end runs.
tags: [mobile, testing]
---

# The simulator is not the device

Simulators are excellent for layout and flow, and actively misleading for
anything touching hardware, permissions or performance. Know which question you
are answering.

## What the simulator answers honestly

Layout across screen sizes, navigation flows, most business logic, accessibility
labels, localisation. Run these in CI on simulators — they are fast, parallel and
deterministic.

## What only a real device answers

- **Performance.** A simulator uses your host CPU and GPU. Frame rate, memory
  pressure and battery there are meaningless.
- **Permissions and their denial paths.** The interesting flow is "user said no",
  and simulator permission behaviour differs.
- **Camera, GPS, biometrics, push.** Approximated or absent.
- **Network transitions.** Wi-Fi to cellular, offline, captive portals. This is
  where the network layer's assumptions surface.
- **Keyboard behaviour.** Third-party keyboards and predictive input change
  layout in ways the simulator's keyboard does not.

## Determinism in E2E

The mobile equivalents of the browser rules: select by accessibility id rather
than by position, wait on conditions rather than durations, and reset app state
between tests. A test depending on the previous test's leftover state is the
most common cause of a suite that passes locally and fails in CI.

Cold start versus warm start matters more than on web: a test that only ever
runs warm never exercises launch-path initialisation, which is where a
surprising share of crashes live.

## Keep the CI matrix honest

Two simulators — the smallest supported and the newest — catch most layout
regressions cheaply. Add one physical device for the release candidate, not for
every commit; a device farm on every push is expensive and rarely finds what the
simulator missed except on the axes listed above.

## Record which it was

A test result without its target is unactionable. "Passed on iPhone 15 simulator,
iOS 18" and "passed on a physical Pixel 6" are different claims, and only the
second one says anything about performance.