skip to content

Why isn't the iOS Simulator or Android emulator enough to sign off a React Native feature, and what do they misreport?

level: middleimportance: must knowfreq 55%

answer

  1. hardware too fast, build too slow
  2. debug builds are much slower
  3. no real camera feed
  4. network, touch, vendor variants
  5. test release builds on low-end phones

basics

~20 s

Simulators run a debug build on fast computer hardware, so speed is wrong both ways, and they lack real cameras, real networks, real touch and vendor variants. Hardware features and performance must be checked on real phones in release builds.

solid answer

~50 s

Simulators and emulators are fine for layout and logic but misreport what users see. Speed is wrong twice: the laptop's processor is far faster than a mid-range phone, while the debug build is much slower on the JavaScript thread than release, so neither number is real, and the React Native docs say to test performance in release builds. Hardware is missing or faked: the iOS Simulator has no camera, and the Android emulator's is a virtual scene or the webcam, so a camera feature like a plant-identification capture can't be signed off there. Networks, touch input and vendor OS customisations also differ. Even the dev loop differs: devices embed a fallback bundle on iOS and use `localhost` on Android. So I iterate on simulators, then verify hardware features and performance on real phones, including a low-end Android, in a release build.

go deeper

for a junior

Recall the main gaps: no real camera, much faster hardware, debug-only builds, and different network and touch behaviour.

for a middle

Explain why simulator speed is wrong in both directions and why only a release build on a real phone gives meaningful performance numbers.

for a senior

Plan a device matrix for a real app, including a low-end Android, hardware-dependent flows and release-build checks before every release.

for a principal

Set the team's testing budget across simulators, a device lab and release checks, trading speed of iteration against the cost of bugs that only real hardware shows.

## Why interviewers ask "Why test on a real device when the simulator works?" checks whether a candidate has shipped a mobile app. The iOS Simulator and the Android emulator are excellent for layout and logic, but they run on a development computer with different hardware, different inputs and, usually, a different build type than users get. Take a **plant-identification app** whose core feature is photographing a leaf: the simulator can show the screen, but it cannot tell you whether the feature works. ## What simulators and emulators misreport | Area | What the simulator shows | What a real phone reveals | |---|---|---| | Camera | No real camera feed: the iOS Simulator has no camera to open, and the Android emulator offers a virtual scene or the host's webcam | Real focus, exposure, orientation and permission prompts | | Speed | The computer's processor and memory, often far faster than a mid-range phone | Real JavaScript-thread and UI-thread headroom | | Build type | Usually a debug build, which the React Native docs say is much slower on the JavaScript thread | Only a release build shows real performance | | Network | The computer's stable connection | Mobile data, poor coverage, captive portals | | Touch and gestures | A mouse pointer | Thumbs, multi-touch, edge swipes, vendor gesture settings | | Hardware and OS variants | A clean system image | Vendor customisations, older OS versions, small memory budgets | Some old reasons are weaker than people think. For example, Expo's notification docs state that push notifications work on iOS simulators with Xcode 14 or later and on Android emulators with Google Play services, so "push needs a device" is no longer the whole story. ## Speed: two layers of distortion Performance on a simulator is wrong in **two directions at once**: - The **hardware is too fast**: a laptop processor makes heavy JavaScript and large images look cheap. - The **build is too slow**: debug builds do much more work at runtime for warnings and error messages, and the React Native docs say to always test performance in release builds. Neither number is the user's number. A real mid-range phone running a **release build** is the only measurement that counts. On Android, the `debugOptimized` build type (added in React Native 0.82, backported to 0.81) narrows the gap for everyday development by optimising the native C++ libraries while staying debuggable, but it is still not a release build. ## Behaviour that only exists on devices Several React Native behaviours differ between simulator and device builds, even in debug: - On iOS, a Debug build for the **Simulator** loads JavaScript from Metro only, while a Debug build for a **device** also embeds a bundle and can silently fall back to it when Metro is unreachable. - On Android, the **emulator** reaches Metro through `10.0.2.2`, while a **physical device** uses `localhost` and needs `adb reverse` or a Wi-Fi host setting. - Permission prompts, background limits and battery optimisations follow the real OS configuration of the device. ## Where simulators are the right tool None of this makes simulators second-class; they are the right tool for most of the work: - fast iteration on layout, navigation and state logic; - trying many screen sizes and OS versions quickly; - automated end-to-end tests in CI, where real devices are expensive; - reproducing a bug report with a known clean system image. The skill interviewers look for is knowing which questions a simulator can answer and which it cannot. ## A practical testing mix 1. Develop and iterate on simulators and emulators; they are fast and scriptable. 2. Test each hardware-dependent feature, such as the camera, on at least one real iPhone and one real Android phone. 3. Include a **low-end Android device**, since that is where performance and memory problems surface first. 4. Before release, run a **release build on a device** and check start-up, the heaviest screens and the camera flow. ## Mistakes interviewers listen for - "It's smooth in the simulator, so it's fast enough." - "The simulator has a camera; it just uses the laptop's." - Measuring performance in a debug build and reporting it as real. - Testing only on the newest flagship phone.

  • Why is a debug build a poor place to judge a screen's smoothness even on a real phone?
    Debug builds do much more work at runtime to produce warnings and error messages, and the React Native docs say JavaScript thread performance suffers greatly in dev mode. A screen that stutters in debug may be fine in release, and the reverse can hide real problems, so performance judgements need a release build on the device.
  • Which devices would you insist on for a camera-heavy app's pre-release check?
    At least one current iPhone and one Android phone to cover both camera stacks and permission flows, plus a low-end Android with little memory, because large photos and image processing expose memory and speed problems there first. Simulators remain useful for everything around the camera screen, but not for the capture itself.
  • Is 'push notifications need a real device' still true?
    Not entirely. Expo's notification docs state push works on physical devices, Android emulators with Google Play services, and iOS simulators on Xcode 14 or later. Devices still matter for the full delivery path and real app states, but a simulator can receive pushes.

A simulator is a flight simulator bolted to a desk: perfect for learning the controls and rehearsing procedures, but it cannot tell you how the real aircraft handles in crosswind, and its clock runs at a different speed from the real flight.

saying these in an interview costs you the question

  • If it's smooth in the simulator, it will be smooth on phones.
  • A debug build on a device shows real performance.
  • The iOS Simulator can open a camera using the Mac's webcam.
  • Testing on the newest flagship covers low-end phones too.
  • Push notifications can never be tested on a simulator.