Joy Foroughi
Executive Assistant
Real Device Testing: How to Choose Which Phones to Test Before Launch
Choose test devices based on your target users, then cover the differences most likely to cause problems: operating system, screen size, memory and manufacturer software. For an app launching on both iOS and Android, a practical starting point is five to eight real phones, with cloud devices adding coverage where needed. One phone can cover several requirements, and tablets only belong in the plan if your app supports them.
Choose test devices based on your target users, then cover the differences most likely to cause problems: operating system, screen size, memory and manufacturer software. For an app launching on both iOS and Android, a practical starting point is five to eight real phones, with cloud devices adding coverage where needed. One phone can cover several requirements, and tablets only belong in the plan if your app supports them.
TL;DR
Build the list from data: your analytics if you have them, public U.S. market share and OS distribution if you don't, and your user personas either way.
Cover differences that break apps: OS version, screen size, hardware tier (RAM and chip), and manufacturer software on Android.
For manual testing, 5 to 10 popular devices for your market is a sound range. Put real phones behind your release-critical journeys.
Use simulators for fast early checks and real phones for cameras, Bluetooth, battery, weak networks and anything a customer pays through.
Review the list on a schedule. Drop phones that add no unique coverage and add one whenever crash reports point to a model.
Why the phone list matters more than the phone count
A launch fails on the phone you did not test. Founders usually test on the phones the team already owns: a couple of recent iPhones and one Pixel. That set says nothing about the shopper on a three-year-old budget Android with 3 GB of RAM, or the customer whose manufacturer skin kills background tasks after two minutes.
The goal is a risk-based selection. TechTarget describes picking device and OS combinations as a risk analysis that depends on knowing your customers, market research and personas. That framing keeps the list short and defensible: every phone is there for a reason you can write down.
It also stops you from over-buying. A bigger lab is not a safer lab. TestGrid makes the point that a raw device count creates false confidence unless the devices can be reserved, reset, configured and observed with logs, screenshots and crash signals. Ten phones that are charged, updated and logged into test accounts beat fifty in a drawer.
Step 1: Start from who actually uses your app
Your first question is not "which phones are popular?" but "which phones do my users carry?" Work through these sources in order.
If you have analytics
Pull device model, OS version, region and user segment from your product analytics. BrowserStack advises starting there and warns against assuming that the latest or most expensive phones represent your audience. A previous version of the app, a web version, or a beta group can all supply this data. If you are setting up tracking, our guide to mobile app analytics for startups explains what to capture from day one.
If you have no data yet
Most pre-launch teams are here. Do three things:
Write two or three personas with their likely budget, age group and context of use. A student using a prepaid Android differs from a clinician using an employer-issued iPhone.
Use external data: Sauce Labs suggests traffic volume, market share, recommended OS version, screen sizes, popularity, region, industry and company size when you lack your own numbers.
Check Apple’s published OS adoption figures and Google Play Console’s Reach and devices data. Check each dataset’s date and audience before using it to guide your test matrix.
Pro Tip: Ask marketing who you are buying ads for. If the paid campaign targets a specific age group or region, that is your best device data before launch.
Watch the manufacturer in your target region
On Android, the brand matters as much as the OS number. BrowserStack recommends including at least one representative model from a manufacturer that dominates your target region, because manufacturer customizations can change permissions, notifications and background tasks. In the U.S., that usually means a Samsung phone, plus a Pixel as the reference build.
Step 2: Cover the differences that actually break apps
Phones differ along four axes. A good set varies each of them on purpose instead of by accident.
Operating system versions
For iOS, BrowserStack's guidance is to cover the latest supported version, the previous major version, and the oldest version that still holds meaningful share among your users. For Android, cover your minimum supported version, the most-used version, the latest stable release, and any version tied to production failures. Add the upcoming beta if you have capacity. Maestro puts it simply for U.S. teams: test the current OS and the two before it, and expect Android to need more attention than the more uniform iOS ecosystem.
Screen sizes
Cover small phones, standard phones, large phones and tablets. Maestro's checklist groups them as roughly 5 to 5.5 inches, 6 to 6.5 inches, over 6.5 inches, and tablets of 8 to 12 inches, and adds foldables where relevant. Also look at notches and cutouts, where layouts commonly clip buttons or text, and at landscape orientation if your app allows it. Our UX/UI design work builds layouts for these ranges from the first wireframe so testing confirms rather than rescues.
Hardware tiers
Low-end and high-end phones expose different bugs. BrowserStack recommends older, low-RAM devices to surface slow startup, rendering problems, memory pressure and performance trouble. If your app feels fast only on your team's flagships, read why apps feel slow before launch, not after your first one-star reviews.
Hardware features and OS behavior
If your app uses the camera, GPS, Bluetooth, NFC or biometrics, those paths need real hardware. Aggressive battery controls and notification handling also vary by device, and they are the bugs users blame on your app.
Step 3: Build the starter set
Here is a practical starter set that combines the guidance above. It is our synthesis, not a fixed standard, so swap models based on your Step 1 data.
Slot | What it covers | Why it earns a place |
|---|---|---|
Recent iPhone, standard size | Latest iOS, mainstream iPhone behavior | Represents a mainstream iPhone configuration; validate against audience data |
Large-screen iPhone, if not already covered | Large screen, strongest hardware | Camera, performance and layout at the top end |
Older supported iPhone with less memory | Previous major iOS, smaller screen, less memory | Finds slow screens and clipped layouts |
Popular Samsung or other leading regional Android model | Manufacturer software and relevant Android version | Represents a leading Android brand in your launch region |
Pixel | Google’s Android implementation and newer OS coverage | Adds coverage of Google’s device and software combination |
Mid-range or budget Android | Low RAM, slower chip, older OS | Where performance and memory bugs surface |
Compact phone, if not already covered | Compact layout | Exposes truncated text and hidden buttons |
Tablet coverage, separately for each supported tablet platform | Wider layouts | iPad and Android tablets use different layouts and multitasking |
These are coverage roles, not a shopping list. One device may fill several roles. Record the exact model and installed OS version for every selected device.
That is six to eight phones and is consistent with the 5 to 10 range from Sauce Labs for manual testing. Sauce Labs also notes that for public apps teams often run automated tests on 25 to 30 devices, which is where a cloud service earns its keep.
Rank them in tiers
Not every phone gets every test. Use three tiers:
Must pass: the phones behind most of your sessions plus one low-end phone. Every release gets full regression here.
Should pass: mid-range, small screen and tablet. They get core journeys and compatibility checks.
Nice to have: older or niche devices. Rotate them in before major releases.
This mirrors BrowserStack's guidance to put high-share devices in smoke and regression testing, moderate-share devices on core journeys, and to keep any phone that shows up in crash or support reports in regression until you understand the pattern.
Step 4: Decide where real phones are non-negotiable
Simulators and emulators are quick and free, and you should use them for early development and continuous integration feedback. Real phones are for what an emulator cannot reproduce. TechTarget notes that emulators multiply your combinations but cannot reproduce all the physical characteristics of real devices.
Use real phones for:
Sign-up, onboarding, checkout and any payment flow.
Camera, location, Bluetooth, NFC and biometric login.
Battery drain, heat, and performance on lower-memory hardware.
Weak signal, airplane mode toggling and Wi-Fi to cellular switching.
Push notification delivery and tapping, and what happens when the OS suspends your app in the background.
Depth beats breadth
HeadSpin offers a useful rule for small teams: running a core flow such as onboarding or checkout across eight different device models is more valuable than testing every minor feature on only two phones. Spend your real-device hours on the journeys that make money or retain users, and leave the secondary screens to simulators.
Accessibility belongs in the same rounds. Screen readers and large text behave differently across devices, so work through our accessibility checklist for pre-launch on at least one iPhone and one Android phone.
Step 5: Buy phones, rent them, or both
Buying gives you instant access, hands-on debugging and a device you can carry to a demo. Cloud access gives you hundreds of model and OS combinations without storing, charging and updating them. Neither is a complete answer alone, and TechTarget points to device farms as a way to reduce the need for an on-site lab.
The hybrid pattern most small teams settle on:
Own 5 to 8 phones for daily work, exploratory testing and debugging. These are the must-pass and should-pass slots above.
Rent cloud devices for broad regression runs, the long tail, and models you rarely need, such as a foldable or an older Android version.
Use secondhand or refurbished phones for the budget and older slots. They do not need to be new, only representative.
Whichever way you go, keep each phone release-ready: charged, on a current build, signed into test accounts, and able to produce logs and screenshots when a bug appears.
Perspective
Device bugs are often familiar: they are a small-screen layout nobody checked, a mid-range Android that stutters on the home feed, or a notification that never arrives on one manufacturer's phones.
Choose test devices early using your personas and target market, and involve the developers who will investigate device-specific bugs. Keeping testing and debugging closely connected helps the team resolve issues faster during launch week.
Our advice is to treat the device list as a living part of the product plan, not a QA afterthought. Settle it during MVP definition, test on it from the first build, and keep revisiting it after launch as real usage data arrives.
Step 6: Keep the list current after launch
Your first list is a hypothesis. Once real users arrive, replace guesses with telemetry. BrowserStack recommends reviewing the device matrix on a fixed schedule and also when something changes:
A new iOS or Android version ships.
You launch in a new country or reach a new user segment.
Analytics show a clear shift in device or OS share.
A model starts appearing in crash reports or support tickets.
A new feature depends on hardware or background behavior.
A phone or OS version reaches end of support.
At each review, remove phones that no longer add unique coverage, add phones only when they cover something new, and write down why. A simple log with the date and reason keeps the decision from becoming folklore.
Reduce risk while you learn
You will not catch everything before launch, and you do not need to. Release gradually and watch crashes by device. Our guide to feature flags and progressive rollouts shows how to expose a new build to a small share of users first, and beta testing before launch explains how to recruit testers who bring their own varied phones. If you need people, see how to find beta testers.
Common mistakes to avoid
Testing only on the team's phones. They skew new, fast and expensive.
Ignoring the low end. Slow devices create the reviews that sink early ratings.
Counting devices instead of coverage. Three phones that differ in OS, size and tier beat six near-identical flagships.
Never retiring devices. A list that only grows becomes a cost with no extra coverage.
Skipping the process. Our mobile development workflow guide shows where device checks fit into each sprint.
Let senior engineers set up your device strategy
If you are heading toward launch and want a team that picks the test devices, runs the tests and fixes what turns up, that is what we do. TouchZen's senior developers and designers handle everything from market research and prototyping to mobile app development, launch, and ongoing support and growth, so your device matrix evolves with your users. Building a first version? Our MVP development for startups service plans testing from the start.
Talk to us through touchzen.ai about your launch timeline and the devices your audience uses.
FAQ
How many real phones do I need before launch?
For manual testing, 5 to 10 popular devices for your market is a sound range, per Sauce Labs. Most startups do well with 6 to 8 that cover both platforms, small and large screens, and a low-end Android. Add cloud devices for wider automated coverage.
Can I rely on simulators and emulators alone?
They are good for early development and quick checks, but they cannot reproduce every physical characteristic of a phone. Test hardware features, battery, performance and weak networks on real devices, and always run your checkout or sign-up journey on them before release.
Which iPhone and Android models should I pick first?
Pick from your own analytics if you have them. If not, start with a recent mainstream iPhone, an entry-level iPhone, a Samsung flagship, a Pixel and a mid-range or budget Android. Adjust once your personas and region are clear.
How often should I update my test devices?
Review on a fixed schedule, such as quarterly, and whenever a new OS version ships, you enter a new market, or a model shows up in crash reports. Remove phones that add no unique coverage and record the reason for each change.
