Every mobile developer eventually looks up the device fragmentation numbers, sees something like "over 20,000 distinct Android device models in active use", and concludes the problem is unsolvable.
It is not unsolvable, because those thousands of models are not thousands of distinct testing problems. Most of them differ in ways your app cannot detect. What your app actually experiences is a much smaller set of variables, and once you test across the variables rather than the models, the problem shrinks to something a small team can handle.
Test the variables, not the devices
Your app does not experience "a Samsung Galaxy A34". It experiences a combination of:
- Screen size and aspect ratio — does the layout hold?
- Screen density — do assets look right, are tap targets big enough?
- OS version — API behaviour, permission model, system UI
- Available memory and CPU class — does it stay responsive, does it get killed in the background?
- Manufacturer skin — battery optimisation, default keyboard, permission dialogs, gesture navigation
- Notch/cutout/gesture area — does anything get obscured?
Two phones that differ only in camera megapixels and battery capacity are, for your purposes, the same device. Two phones with the same screen but different manufacturer skins are genuinely different.
Start with your own data, not the market
The most common mistake is choosing devices from global market share statistics. Global share is not your share.
If you already have users, your analytics have the real answer. Look at device model, OS version, and screen size, sorted by volume. In most apps the distribution is steep — a modest number of configurations covers the large majority of sessions.
Also look at the tail, filtered by something that matters. Which devices have the worst crash rate? Which have the lowest conversion? A device with 2% of your users and triple the crash rate deserves a slot in your matrix far more than one with 8% and no problems.
If you are pre-launch, use the market data for the countries you are actually targeting. Device profiles differ enormously between regions — the median device in one market may be several years and one price tier away from the median in another.
A matrix that works for most teams
If you want a default to start from, this is a reasonable shape.
iOS: 3–4 devices
| Slot | Why |
|---|---|
| Current flagship, latest OS | What reviewers and early adopters use |
| Small/compact model | Where layouts break first |
| 3–4 year old device on the oldest OS you support | Performance floor and deprecated API behaviour |
| iPad, if you support it | Different layout entirely — genuinely a separate product surface |
iOS is the easy side. A handful of screen sizes, fast OS adoption, and one manufacturer means coverage is achievable with a small set.
Android: 5–7 devices
| Slot | Why |
|---|---|
| Recent Samsung flagship | Largest single OEM share in most markets; One UI is its own environment |
| Pixel on the latest Android | Closest to stock; your baseline |
| Mid-range device, 4GB RAM | Where most of your users actually are |
| 3–4 year old budget device, oldest supported OS | Memory pressure, thermal throttling, slow storage |
| A second OEM skin — Xiaomi, Oppo, or similar, depending on your market | Aggressive background process management |
| Tablet or foldable, if relevant | Large screens and hinge states |
The mid-range and older budget slots are the ones teams skip and the ones that find the most bugs. Testing exclusively on flagships is how you ship an app that is fine for you and sluggish for a third of your users.
Web, if you have a web surface
Chrome and Safari at minimum, plus mobile Safari on a real iPhone — which behaves differently enough from desktop Safari that treating them as one target causes real bugs. Firefox if your analytics justify it.
OS versions matter more than models
If you had to choose between adding a sixth device model and adding a second OS version, take the OS version. OS-level behaviour changes are where the sharp edges are: permission model changes, background execution limits, notification behaviour, privacy restrictions, and default UI changes.
Practical rule: always test the newest OS (including the beta, if a release is coming), and always test the oldest version you claim to support. The middle usually takes care of itself.
Buying devices vs. borrowing them
A representative Android matrix is expensive to buy — and the purchase is the cheap part. The ongoing cost is worse: keeping devices charged, updating some while pinning others to old OS versions, replacing dead batteries, and maintaining a cupboard of hardware that is out of date in eighteen months.
The alternatives:
Device farms give you remote access to a large pool. Good for automated suites and for reproducing a specific model-specific bug. Less good for anything involving feel, real network conditions, or a device with a real life on it — a farm device is a pristine machine in a rack.
Real testers on their own devices give you the opposite trade-off: genuine device diversity you did not have to buy, on hardware with real storage pressure, real notifications, real network, and a human attached who notices when something feels wrong even if nothing technically failed.
For most teams the sensible combination is emulators for iteration, and real people on real devices before releases — with a farm in the mix if you have a mature automated suite. Our emulators vs real devices piece covers where each one stops being useful.
How to know your matrix is wrong
Watch for these signals:
- Crash reports from device classes you do not test on. The clearest possible signal, and easy to ignore.
- Support tickets that cluster by manufacturer. Usually battery optimisation or a keyboard behaviour.
- Conversion that drops on older devices. Often a performance problem you cannot feel on your own hardware.
- Bugs found in production that a slower device would have exposed. Race conditions and timing bugs hide on fast phones.
Revisit the matrix roughly twice a year. Devices age out, OS adoption shifts, and the mid-range slot in particular needs refreshing.
Bugfed spreads your test runs across vetted testers on real phones, tablets and desktops, so you get device and OS diversity without owning or maintaining any of it.