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, which boots on demand, runs many at once, and costs nothing to keep on a shelf.
We sell simulator streaming, so read the next section 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 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 precisely 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. |
| Localisation 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. |
| Regression suites on every commit | Simulated | Frequent, and hardware is too slow and too contended to absorb this load. |
| Camera and microphone capture | Hardware | Apple documents that Simulator does not support audio and video input from either. |
| Motion, orientation, step counting | Hardware | Apple documents that Simulator does not simulate accelerometer or gyroscope motion. |
| Proximity, barometer, ambient light | Hardware | Apple documents that Simulator does not simulate these sensors. |
| Graphics performance and thermals | Hardware | Apple notes Simulator does not use a tile-based deferred renderer, so GPU behaviour diverges. |
| Bluetooth, NFC, cellular conditions | Hardware | Radios have no simulated equivalent to exercise. |
| 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's Simulator documentation is explicit about the gaps. It states that Simulator does not simulate motion support from the accelerometer and gyroscope, does not support audio and video input from the camera and microphone, and does not simulate the proximity sensor, barometer or ambient light sensor. It also notes that Simulator does not use a tile-based deferred renderer — which is the technical reason graphics behaviour and performance are not comparable to a 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 the layering most teams already run: 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 and need to boot on demand and run many at once. 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 does not use a tile-based deferred renderer 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 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. It runs iOS simulators in the cloud and streams them to a browser, so anyone with a link can use the build, and CI can run a suite against a device nobody has to own. If you want the mechanics, running an iOS simulator in the browser covers what the device can do, and preparing your build covers producing the simulator build you need.
The limit is the one this whole page is about. There is no physical device cloud here, so the six hardware rows in that table are not ours to serve — use a real-device service for those. We would rather say so than sell you a camera test we cannot run.
If that half of the work is what you need covered, the free tier runs two sessions at once with 30 streaming minutes a month and no card, though each free session stops at five minutes.
Published 29 July 2026