Run almost everything on the simulator. Keep a hardware pass before release.
That is the whole answer, and the useful version of the question is not "can I trust simulators?" but "which of my bugs is a simulator physically unable to see?" That list is short, specific, and mostly not the things teams worry about. Everything not on it belongs on a simulated device.
We sell simulator streaming, so read what follows knowing we have a side. We still tell customers to keep a hardware pass, because the alternative is shipping a camera bug we could never have caught for them.
Who this page is for
Teams deciding how to split a mobile test suite, and anyone who has been told "simulators aren't real devices" and wants to know exactly how much that matters. If you ship an app whose core function is the camera, a Bluetooth peripheral or turn-by-turn navigation, your split will lean harder on hardware than most.
What runs where
| What you are testing | Runs on | Why |
|---|---|---|
| Business logic and state management | Simulated | Your real code, compiled and executed. Nothing about it is approximated. |
| Navigation, routing and deep links | Simulated | The same view controllers and the same stack your users get. |
| Layout across screen sizes | Simulated | Real rendering, and you can sweep the size matrix in parallel. |
| Localization and right-to-left | Simulated | Language and region are settings, not hardware. |
| Dynamic type and accessibility sizing | Simulated | Text scaling is an OS setting the same code path reads. |
| Light and dark appearance | Simulated | A trait change your views handle identically either way. |
| Permissions and system dialogs | Simulated | Presented by the OS in both cases, so the flow is the one your users hit. |
| Empty, error and offline states | Simulated | These are branches in your own code, reached the same way. |
| Form validation and input handling | Simulated | Your validation logic, not the keyboard hardware. |
| Onboarding and first-run flows | Simulated | A clean install is a reset, and resets are cheap here. |
| OS version matrix | Simulated | Multiple runtimes on one machine, without owning a phone per version. |
| Visual regression per screen | Simulated | Deterministic rendering is what makes screenshot comparison stable — VibeView's visual check, on by default in every new group, compares each step's screenshot with its baseline. |
| Regression suites on every commit | Simulated | Frequent, and hardware is too slow and too contended to absorb this load. |
| Camera capture | Hardware | Apple's earlier Simulator documentation listed the camera as unsupported hardware. |
| Motion, orientation, step counting | Hardware | Apple's earlier Simulator documentation listed accelerometer and gyroscope motion as unsupported. |
| Proximity, barometer, ambient light | Hardware | Apple's earlier Simulator documentation listed all three as unsupported. |
| Graphics performance and thermals | Hardware | Apple's Metal documentation says Simulator does not emulate the device GPU; it translates calls to the Mac's GPU. |
| Bluetooth, NFC, cellular conditions | Hardware | Apple's earlier Simulator documentation listed Bluetooth as unsupported, and the other radios have no simulated equivalent either. |
| Release sign-off | Hardware | The last check before users get it should run on what users hold. |
Nineteen rows, and six of them need hardware. Notice what those six have in common: not one is about whether your app works. They are sensors, radios, the GPU and the final sign-off. Everything above them — the logic, the screens, the states, the whole matrix you actually run on every commit — is the same code doing the same thing, and it does not need a phone to do it.
That ratio is the argument. The hardware list is short and it is fixed. The simulated list is long and it is most of your suite.
What it genuinely cannot see
Apple was explicit about the gaps. Its Simulator documentation listed the hardware Simulator does not support: the camera, motion from the accelerometer and gyroscope, the proximity sensor, the barometer, the ambient light sensor and Bluetooth. Audio input was on that list too, with an exception for Siri; Apple's current Device Hub documentation describes choosing a simulator's sound input, including the Mac's own.
Apple has since retired that page. Its current Xcode documentation covers the gap in one line: simulators "don't replicate the performance or features of a physical device". Its Metal documentation gives the graphics reason: Simulator does not try to emulate the device's GPU, it translates Metal calls to the Mac's GPU, and it may support fewer features or different limits than the phone.
Add the ones that follow from running on your Mac rather than in your user's hand: real cellular conditions, thermal throttling, battery pressure, and the memory ceiling of a four-year-old handset. A simulator has your laptop's resources, so it will happily run an app that a real phone kills.
That is the honest list. It is worth reading twice, because it is shorter than the reputation suggests, and because nothing on it is "the app behaves differently".
What hardware costs you
The reason not to run everything on devices is not that hardware is worse. It is that a physical lab is expensive and hard to scale.
Maintaining one means buying, updating and replacing hardware across many models and OS versions, and configuring each device individually before and during tests. Running tests in parallel across many devices demands either substantial in-house infrastructure or a cloud lab. And even a large lab keeps coverage gaps, because it is impractical to hold every legacy, regional and niche model.
Simulators invert all three. They boot on demand, run many at once, and cost nothing to keep on a shelf.
How to split it
Use a common layering: unit and integration tests on every commit, UI and end-to-end tests less frequently, on release candidates or in CI.
Map that onto the table. The frequent layers go to simulated devices, because those layers run constantly. Your limited hardware time goes to two things: the release-candidate pass, and any flow that touches a sensor, a radio or the GPU. If a feature does not touch those, a hardware pass buys confidence you already had.
One rule worth adopting: never read absolute performance numbers off simulated hardware. Apple's own note that Simulator runs graphics on the Mac's GPU rather than emulating the phone's settles it on its own, and your Mac has more CPU and memory headroom than the phone on top of that. Those timings are only useful as a relative signal between builds.
Where a streamed simulator like VibeView fits
Most of the value here is the simulator half, and it has an access problem rather than a fidelity problem: the runtime needs macOS, so the reviewer, the PM and the developer on Windows do not have one.
That is the gap VibeView fills, and not only for iOS. It runs iOS simulators, Android emulators, Apple TV, Android TV and Roku devices in the cloud and streams them to a browser. Cloud builds compile the simulator or emulator build with no Mac, anyone you send a link to can open it without installing anything, an agent can drive it, and CI runs your tests against a device nobody has to own, with screenshot checks against a baseline. Running an iOS simulator in the browser covers what the device can do, and preparing your build covers uploading one you built yourself.
The limit is the one this whole page is about: VibeView's phones and tablets are simulators and emulators, not physical devices, so the six hardware rows still need hardware of your own.
Start free: 2 devices at once (iOS, Android, Apple TV, Android TV, Roku), 30 streaming minutes and $1 of usage credit a month, no card.
Published 29 July 2026 · Updated 23 October 2026 · Apple Metal and Xcode documentation verified 23 October 2026 · Hardware list from Apple's earlier Simulator documentation (archived copy of 9 June 2025)