Your app will not behave the same on every phone. OS versions, screen sizes, memory, hardware, and manufacturer changes can all affect what the user sees and how the app performs.
Since you cannot test every available device, you need a focused device set. That choice should come from your users, product features, target regions, and the risks most likely to affect a release.
The next step is to identify those factors and use them to build a practical device matrix. Start with the technical requirements of the app, then narrow the list using audience data, OS coverage, screen sizes, manufacturers, and market share.
What is Mobile App Testing?
Mobile app testing is the process of verifying that an Android or iOS application works correctly, performs reliably, and provides a consistent user experience across supported devices, operating systems, screen sizes, and network conditions.
It covers functional testing, usability, performance, security, compatibility, permissions, interruptions, and hardware features such as the camera, GPS, Bluetooth, and biometrics. Since these areas can behave differently across devices, device selection directly affects the quality and relevance of the test results.
Importance of Device Selection in Mobile Testing
Device selection determines how closely your test coverage matches the conditions in which users run the app. A test suite may pass on a limited set of devices and still miss failures caused by OS versions, hardware limits, screen dimensions, or manufacturer-specific behavior.
A well-planned device set helps you:
- Cover the main user base: Prioritize the devices, operating systems, and versions used by your target audience.
- Detect fragmentation issues: Find layout, compatibility, and behavior differences across screen sizes, Android variants, and device models.
- Test realistic performance: Check startup time, memory use, battery impact, and responsiveness on both high-end and lower-end devices.
Read More: Top Tools for Mobile App Performance Testing
- Validate hardware-dependent features: Confirm that camera, GPS, Bluetooth, biometrics, sensors, and permissions work across supported devices.
- Use testing time effectively: Run broader regression tests on high-priority devices and focused checks on lower-priority combinations.
- Reduce production risk: Catch device-specific failures before they affect a large group of users.
How to Use Market Data to Prioritize Mobile Devices
Market data helps you decide which devices need full regression coverage and which ones only need focused checks. Start with your product analytics, then add external market data where your own numbers are limited.
| What the data shows | What it means for testing | How to prioritize |
|---|---|---|
| A device handles a large share of sessions or transactions | A defect could affect many users or important business flows | Include it in smoke, regression, and release testing |
| A device has moderate usage but covers a major OS version | It adds compatibility coverage that your top devices may not provide | Run core user journeys and compatibility checks |
| A device appears often in crash reports or support tickets | Usage may be low, but the failure risk is high | Keep it in regression until the issue pattern is understood |
| A manufacturer dominates a target region | Its Android customizations may affect permissions, notifications, and background tasks | Include at least one representative model from that manufacturer |
| An older device has limited RAM or processing power | It can expose startup, rendering, memory, and performance problems | Use it for performance-sensitive and resource-heavy flows |
| A device has low usage and adds no unique coverage | It contributes little to the matrix | Remove it or test it only before major releases |
Example
Suppose most of your users are on recent iPhones and Samsung devices. Those models should receive full regression coverage. A Xiaomi device may account for fewer users, but it should still be included if the app depends on background notifications because its battery controls can affect delivery.
You may also keep an older Android phone with limited memory even when its usage is low. It adds performance coverage that your flagship devices cannot provide.
This approach gives every device a clear role in the matrix. The device is included because of user reach, business impact, technical coverage, or known risk.
Read More: Top Android Devices For Mobile App Testing
Selecting Devices For Mobile App Testing: Factors to Consider
Here are the factors to consider while selecting mobile devices for testing:
1. Technical Parameters
Technical parameters help you remove unsupported devices and identify combinations that need deeper testing. Review them against the app’s requirements before assigning devices to smoke, regression, or compatibility runs.
| Parameter | Why it matters | Testing impact |
|---|---|---|
| OS version | APIs, permissions, and system behaviour change between releases | Include the minimum supported version, widely used versions, and the latest supported version |
| Processor and RAM | Lower-end hardware can expose slow startup, dropped frames, and memory-related crashes | Run performance-heavy flows on at least one limited-resource device |
| Available storage | Low storage can affect installation, updates, downloads, caching, and media handling | Test app behaviour when storage is nearly full |
| Screen size and pixel density | Layouts may break even when two devices have similar resolutions | Cover compact, standard, large, and tablet layouts |
| Camera and biometrics | Sensor quality and authentication support vary across models | Include devices that represent each supported camera or biometric flow |
| Bluetooth, NFC, GPS, and sensors | Hardware support and implementation differ by device | Select devices based on the features used by the app |
| Network capability | Devices may support different bands, Wi-Fi standards, and network generations | Test critical journeys under the network conditions used by the target audience |
| Battery and background controls | Some Android manufacturers restrict background activity more aggressively | Validate notifications, sync, location tracking, and long-running tasks |
Once the technical list is ready, group the devices by test depth:
- Primary devices: Used for development checks, smoke tests, and critical flows on every build.
- Tier 1 devices: Used for full regression and release validation.
- Tier 2 devices: Used for targeted compatibility, screen, OS, or hardware checks.
This classification keeps the matrix manageable while preserving coverage for the technical risks that matter to the app.
2. Target Audience and Popular Devices
Your device list should reflect the people who actually use the app. Start with product analytics and check device models, OS versions, regions, and user segments. Avoid assuming that the latest or most expensive devices represent your audience.
A few examples show why this matters:
| User or product pattern | Device selection decision |
|---|---|
| Most users are in price-sensitive markets | Include budget and mid-range Android devices with lower RAM and older OS versions |
| The app is used mainly by enterprise customers | Prioritize devices approved or issued by those organisations |
| A large share of users is on older iPhones | Keep those models in regression until usage drops below an agreed threshold |
| The app depends on media, gaming, or visual quality | Add devices with different display sizes, refresh rates, and GPU capabilities |
| The app targets older users | Include devices with larger text settings, accessibility options, and common mid-range models |
Popular devices deserve strong coverage because an issue can affect a large number of users. They should not fill the entire matrix, though. You still need devices that expose specific risks such as low memory, older software, unusual screen dimensions, or aggressive battery controls.
3. Device Matrix
A device matrix records which devices you test and why they are included. It helps the team avoid random device selection and makes gaps easier to identify before a release.
A useful matrix should include:
| Field | What to record |
|---|---|
| Device and manufacturer | Exact model and brand |
| OS version | Installed version and whether it is the minimum, latest, or widely used version |
| Screen profile | Size, resolution, density, notch, fold, or tablet layout |
| Hardware profile | Processor, RAM, storage, camera, biometrics, NFC, Bluetooth, and sensors |
| User share | Percentage of sessions, users, or transactions |
| Risk covered | Performance, compatibility, layout, hardware, regional usage, or known defect |
| Test level | Smoke, full regression, core-flow, or targeted testing |
| Review status | Date reviewed and reason for keeping or removing the device |
For example, two phones running the same Android version may still belong in the matrix if one covers a major user segment and the other covers low-memory performance. The value of a device comes from the risk or audience it represents, not just its model name.
4. Operating Systems
OS coverage should be based on your support policy and actual user distribution. Testing only on the latest release can leave defects unnoticed for users who have not upgraded.
For iOS, device and OS variation is relatively controlled. Cover the latest supported version, the previous major version, and the oldest version used by a meaningful share of your customers. Also test a new iOS release before updating the app’s support policy.
Android needs broader coverage because several versions remain active at the same time. Manufacturer customizations can also change permissions, notifications, storage access, and background behaviour.
A practical OS set can include:
| OS category | Why it belongs in the matrix |
|---|---|
| Minimum supported version | Confirms that the app still installs and core flows work at the lower support boundary |
| Most-used version | Covers the largest part of the current user base |
| Latest stable version | Detects issues caused by recent API, permission, and platform changes |
| Version linked to production failures | Keeps known compatibility risks under regression |
| Upcoming beta version | Gives the team time to fix issues before the public release |
Do not select OS versions in isolation. Pair them with devices that represent the hardware and manufacturers used by your audience. Testing Android 14 only on a Pixel, for example, may not reveal background-process or notification issues seen on Samsung or Xiaomi devices.
Read More: Top Android Devices For Mobile App Testing
5. Screen Size & Resolution
Screen coverage is about how the app behaves when the available layout space changes. Resolution alone does not give you that coverage. Two devices may have similar resolutions but use different screen sizes, pixel densities, aspect ratios, or display cutouts.
Your matrix should include devices that can expose different layout problems:
| Screen profile | What to check |
|---|---|
| Small phone | Truncated text, overlapping controls, hidden actions, and crowded forms |
| Standard phone | Main layouts and common user journeys |
| Large phone | Stretched components, excessive spacing, and one-handed usability |
| Tablet | Multi-column layouts, orientation changes, and unused screen space |
| Notched or punch-hole display | Content placed too close to the camera or status area |
| Foldable device | Layout changes during folding, unfolding, and app resizing |
Also test with larger system fonts and display scaling. A screen that looks correct with default settings may break when a user increases the font size. Pay close attention to navigation bars, forms, modal windows, tables, and buttons with long labels.
6. Device Manufacturers
Android manufacturers change parts of the operating system to manage battery usage, permissions, notifications, storage, gestures, and background activity. These changes can affect an app even when two devices run the same Android version.
The manufacturer matters most when your app depends on background behaviour or hardware access.
| App behaviour | Manufacturer-related risk to test |
|---|---|
| Push notifications | Delayed or blocked notifications caused by battery controls |
| Background sync | Processes paused when the app is inactive |
| Location tracking | Location updates reduced or stopped in the background |
| Camera and media upload | Differences in camera output, file handling, and permissions |
| App links and deep links | Links opening in the browser or failing to reach the correct screen |
| Gestures and navigation | Conflicts with system gestures or custom navigation controls |
You do not need every model from each brand. Select one or two devices that represent the manufacturer’s current software and a hardware profile used by your audience.
7. Market Share
When choosing devices for mobile app testing, market share plays an important role. It helps determine which smartphones and tablets are most commonly used, allowing testers to prioritize devices that will reach the widest audience.
According to recent statistics, Apple leads the global market share with 30.85%, followed by Samsung at 19.09%, making them a priority for testing to ensure compatibility with the most widely used devices.
Why Test Mobile Apps on Real Devices
Real devices show problems that emulators and simulators may not reproduce accurately. They let you test the app with actual hardware, manufacturer settings, network changes, system interruptions, and touch input.
Use real devices when testing:
- Camera, GPS, Bluetooth, NFC, biometrics, and other hardware features
- Push notifications, background sync, and battery restrictions
- Weak networks, signal loss, and switching between Wi-Fi and mobile data
- Startup time, memory usage, battery consumption, and overheating
- Gestures, keyboards, orientation changes, notches, and foldable screens
- Installation, app updates, low storage, and retained user data
Emulators still work well for early development checks and repeatable functional tests. Real devices should cover release-critical journeys and areas affected by hardware, performance, OS behaviour, or manufacturer customizations.
How to Review and Update Your Device Matrix
A device matrix starts losing value when it stays unchanged for too long. User distribution shifts, new OS versions arrive, manufacturers release new devices, and production issues expose risks that were not visible when the matrix was created.
Review the matrix on a fixed schedule and whenever one of these changes occurs:
- A new Android or iOS version is released
- The app enters a new country or user segment
- Analytics show a clear change in device or OS usage
- A device starts appearing frequently in crash reports or support tickets
- The app adds a feature that depends on hardware or background activity
- A model or OS version reaches the end of your support window
During each review, check whether every device still serves a clear purpose. A device may stay because it represents a large user group, covers the minimum supported OS, exposes low-memory behaviour, or validates a manufacturer-specific risk.
Remove devices whose usage has dropped and whose coverage is already provided by another model. Add new devices only when they contribute meaningful coverage. Replacing one Samsung flagship with its newer version may make sense. Adding three new phones with the same OS, screen profile, and hardware range usually does not.
Record the reason for each change in the matrix. This gives QA, engineering, and product teams a shared view of why a device was added, retained, or removed.
Conclusion
Device selection affects the quality of every mobile test run. A matrix built only around popular flagship phones can miss problems caused by older OS versions, limited hardware, unusual screens, or manufacturer-specific Android behaviour.
Build your device list using product analytics, target-market data, technical requirements, and production failures. Also, assign each device a clear role across smoke, regression, compatibility, performance, or hardware testing.
