How do you choose which devices to test on, and what will an emulator never tell you?

Your analytics, not the market's

The device list starts from the distribution of your own installed base, because that is the only data that describes who is affected when something breaks. Public market-share figures describe a country's phone sales; a banking app in India and a design tool sold to studios have almost nothing in common in either OS version spread or hardware class, and both differ from the market average.

So pull the breakdown you already have from the app stores' consoles and your crash reporter: OS version, device model, and where you can get it, memory. Then sort by users and look for where the curve flattens. Typically a modest number of models covers a large majority of sessions, with a long tail of hundreds of models representing a fraction each. The list you test on should cover the head, and the tail is handled by making the app degrade sensibly rather than by acquiring devices.

The crash reporter deserves separate weighting. If a model accounts for two per cent of sessions and twenty per cent of crashes, it belongs on the list regardless of its rank by users, and that disproportion is usually the most interesting signal in the whole dataset.

Vary the dimensions, not the badge

The common mistake is a list of six devices that are all recent flagships from two manufacturers, which is one device tested six times. Each device you add should differ from the others along an axis that has caused defects.

The axes that pay are the OS version, particularly the oldest one you still support and the newest one including any beta, since those are where API behaviour changes bite. The screen geometry, meaning the smallest width and the largest, plus whatever notch, cutout or rounded-corner arrangement affects your layout, and a tablet or a foldable if you claim to support one. The hardware class, because a low-memory device is where you find the crashes caused by the operating system reclaiming your process and the jank caused by work on the main thread. And on Android, the manufacturer, because vendor skins change background execution policy, notification handling, permission dialogs and default keyboards, and those differences produce real defects that never appear on a stock build.

Then treat the list as perishable. Review it each release cycle against fresh analytics, because OS adoption moves within months of a release and a list agreed a year ago is describing a population that no longer exists.

What the emulator genuinely cannot do

Emulators and simulators are excellent for what they are for: fast layout checks across many screen sizes, most business logic, navigation, localisation, and the bulk of a UI automation suite running on every commit. Insisting on physical hardware for all of that buys nothing and costs you a fast feedback loop.

What they cannot represent faithfully falls into a few groups. Anything involving the physical sensors and radios — camera and its focus behaviour, microphone, GPS with real signal loss, Bluetooth pairing, NFC — because a simulated input is a file, not a sensor. Performance and thermal behaviour, because the emulator runs on your workstation's CPU and memory, so a screen that is smooth in the simulator can be unusable on a three-year-old mid-range phone. Battery and background execution, since the interesting question is what the OS does to your app when it decides you are using too much power, and that decision is made by the real system. Biometric authentication and the secure hardware behind it. And on Android specifically, everything the manufacturer changed, which by definition does not exist in a stock emulator image.

Interruptions sit in between. An incoming call, a notification shade pulled down mid-form, the app being killed while backgrounded and restored later: some of these can be triggered on an emulator, but the ones that matter most are those the OS initiates on its own schedule, and those need a real device left in a real state.

Where the two layers meet in a pipeline

The arrangement that follows from this is layered by cost. Unit and business-logic tests run everywhere with no device at all. The UI automation suite runs on emulators or simulators on every commit, across two or three configurations, because it needs to be fast and repeatable and most of what it checks is not hardware-dependent. A smaller suite runs on real hardware nightly and before release, covering the sensor-dependent flows, the performance-sensitive screens, and the specific models your crash data has flagged. Manual testing on real devices then concentrates on what automation is bad at: how something feels, whether the layout is right on a small screen with the system font enlarged, and how the app behaves when you interrupt it rudely.

Cloud device farms make the real-hardware layer practical without a cupboard full of phones, and are the right default for breadth. The trade-off worth naming is that a remote device is fine for functional coverage but poor for anything where you need to hold the phone: perceived responsiveness, camera work, and the judgement calls about feel that are the reason a human is looking at all. Keeping a handful of physical devices in the team, chosen to include one cheap low-memory Android, covers that gap cheaply.

The device nobody puts on the list

The high-risk device is not the newest flagship, it is the cheap Android two or three years old with little free storage, an aggressive vendor battery manager and a slow network. It is where the process gets killed while backgrounded and your state restoration is exercised for the first time, where your image handling exhausts memory, where a synchronous call on the main thread becomes a visible freeze, and where the vendor silently prevents the background work your feature depends on. It is also disproportionately represented in the crash data of most consumer apps and disproportionately absent from test plans, because it is unpleasant to use and nobody on the team owns one.

Buying one and keeping it on the desk changes what the team ships, which is a stronger answer than any device-matrix formula, and it is the concrete thing to offer when an interviewer asks what you would do differently.