Testing on real devices, when an emulator is enough
A simulator is a fast approximation of a phone. Here is the short list of bugs it cannot show you, and what that means for a device budget.
Nobody has the budget to test on forty phones, and nobody needs to. The useful question is not how many devices, but which failures only a real one can produce.
What an emulator gets right
More than teams expect. Layout at a given viewport, most touch behaviour, navigation, forms, and anything that is really just the browser at a smaller size. If the bug you are hunting is a broken grid at 390px, the simulator will find it and it will find it faster.
That covers a large share of front-end defects, which is why emulator-first is the correct default for day-to-day work.
What it cannot show you
The list is short and it is expensive:
- Real network conditions. Not a throttled profile, but a train, a lift, and a connection that drops halfway through an upload.
- Memory pressure. An older device with fifteen tabs open kills your page. A simulator on a laptop with 32GB never will.
- The real keyboard. Autocorrect, autofill, the accessory bar, and the way the viewport resizes when it opens.
- Camera, biometrics, notifications and the share sheet. Anything that touches hardware or another app.
- Actual performance. A four-year-old midrange phone is the machine your users have. Your laptop is not a proxy for it.
A device budget that works
Two physical devices cover most of it. One current iPhone and one older Android in the midrange, where the volume is. Buy the Android used and two generations behind on purpose, because that is the floor your product has to clear.
The device that finds bugs is the slow one. The new one agrees with your laptop.
Add a browser matrix on top for the desktop side, and use a device cloud for the long tail before a big release rather than owning it.
Where it sits in a release
Emulator during development and for the regression suite. Real devices for the release check on anything that touches upload, payment, camera or login, and for any flow a user completes while moving.
That split keeps the fast path fast and puts the slow, expensive checking where a defect would actually cost you something. How we work shows the device matrix we run for a typical engagement.