Building a device matrix in 2026: tackling Android and iOS fragmentation

You cannot test on every phone, and you do not need to. A good device matrix tells you exactly which Android and iOS combinations cover your real users, so fragmentation stops being a guessing game. This guide shows you how to build one from your own data, how to tier it, and how to keep it current through 2026’s release calendar.

Why you need a device matrix in 2026

Fragmentation has not gone away; it has shifted. Android still spans dozens of manufacturers, each with its own skin, such as Samsung One UI, Xiaomi HyperOS, OPPO ColorOS and vivo OriginOS. Meanwhile, iOS looks uniform but covers several active OS versions, from the iPhone SE to the largest Pro Max, plus iPads with multitasking.

Without a device matrix, coverage drifts toward whatever phones your team happens to carry. Usually, that means recent flagships on the latest OS. However, your users may be on a Galaxy A16 running Android 14 with large text enabled. As a result, the bugs that hurt most ship untested.

A device matrix fixes this by making coverage a decision. It answers three questions in writing: which environments matter, how much each one matters, and how often you test it. Consequently, product, QA and engineering share one definition of “tested.”

The dimensions of fragmentation your device matrix must cover

A device model is only one axis. Bugs depend on combinations, so your device matrix should capture every dimension that changes behavior.

• OS version: Android 13 through 16 and iOS 18 through 26 are all common in 2026, with long tails beyond them.
• OEM skin: battery optimizers on Xiaomi, OPPO and vivo kill background work differently from stock Android on a Pixel.
• Screen size and density: compact phones, tall 20:9 screens, foldables such as the Galaxy Z Fold and Z Flip, and tablets.
• Hardware tier: 3 to 4 GB of RAM and entry-level chipsets behave very differently from flagships under memory pressure.
• WebView and browser: Chrome, Samsung Internet and Safari versions matter for hybrid apps and web flows.
• Accessibility settings: large text, display zoom, bold text, dark mode and screen readers change layouts.
• Locale and region: right-to-left languages, long German strings, regional date and number formats.
• Network and carrier: covered in depth in our guide to testing on real networks.

You will not test every combination. Instead, you pick representative combinations that span the risky edges of each dimension.

Data sources for building a device matrix

Start with your own users, because nobody else’s audience looks exactly like yours. In addition, combine several sources, since each has blind spots.

1. Product analytics: sessions and, more importantly, revenue by device model, OS version and country over the last 90 days.
2. Google Play Console: installs, crashes and ANRs by device, plus the device catalog for hardware specs.
3. App Store Connect: crashes and usage by device and iOS version. Apple also publishes iOS adoption figures that show how quickly users move to new versions.
4. Crash and performance tools: devices with disproportionate crash or slow-start rates deserve a slot even with modest usage.
5. Support tickets: tag tickets by device and OS to spot environments that generate complaints.
6. Market plans: if you are launching in Indonesia or Nigeria next quarter, add their dominant devices now, before you have analytics.

For new apps without data, use market-level device share for your target countries as a starting point. Then replace it with your own analytics as soon as you have a few weeks of traffic.

How to tier your device matrix

Tiering keeps your device matrix affordable. Each tier gets a different testing depth and cadence. Here is a simple, repeatable process:

1. Rank combinations by revenue share, not just session share, so high-value users get priority.
2. Group near-duplicates. A Galaxy S24 and S25 on the same One UI version behave similarly, so one can represent both for most tests.
3. Set coverage targets. For example, Tier 1 should cover roughly 60 to 70% of revenue, and Tiers 1 and 2 together 85 to 90%.
4. Add risk picks. Include the lowest-spec device with meaningful usage, one foldable, one tablet, and the oldest OS version you support.
5. Assign cadence. Tier 1 on every release candidate, Tier 2 on major releases, Tier 3 in targeted quarterly passes.

A sample device matrix for a global consumer app

The table below is illustrative. Replace each row with your own data, but keep the structure.

Notice that the matrix mixes flagships, budget phones and risk picks. That mix is the point, because flagships hide the problems your budget users see every day.

Match test depth to each tier

Tiers are not only about which devices you test; they also set how deeply you test each one. Otherwise, every release turns into a full regression on twelve phones, and the matrix becomes too expensive to run.

• Tier 1: full regression of revenue and trust flows, plus a short exploratory charter on changed areas.
• Tier 2: smoke tests of the top journeys, plus focused checks on whatever makes the device risky, such as battery optimizers or foldable posture changes.
• Tier 3: install, launch, login and one core journey, run quarterly or before a market launch.

As a result, a typical release candidate might run deep tests on five devices and lighter checks on seven more, all within one cycle. Write the depth into the matrix itself, next to each row, so nobody has to guess what “covered” means for a given device.

Common Android and iOS fragmentation bugs to look for

Knowing where fragmentation bites helps you design tests for each tier. Here are patterns that show up repeatedly, with example bug titles.

Android

• Background work killed: “Reminders never fire on Redmi Note 14 with HyperOS battery saver on.”
• Custom permission flows: “Notification permission dialog does not appear after OS upgrade on OPPO ColorOS.”
• Memory pressure: “Camera upload restarts app on Galaxy A16 with 4 GB RAM.”
• WebView differences: “Payment 3DS page renders blank in WebView on Android 13.”
• Foldables: “Checkout state lost when unfolding Galaxy Z Fold mid-flow.”

iOS

• Small screens: “Continue button hidden behind keyboard on iPhone SE.”
• Dynamic Type: “Plan names truncated at largest accessibility text size on iPhone 13.”
• OS-version behavior: “OTP autofill fails on iOS 18 but works on iOS 26.”
• iPad multitasking: “Layout breaks in Split View at one-third width.”

Use these as test ideas for each row of your matrix. In addition, follow the platform guidance on compatibility, such as the screen and density recommendations on the Android developer site.

Covering your device matrix without buying a lab

Owning every device in your device matrix is expensive and slow. Devices age, batteries swell, and regional models are hard to buy. Therefore, most teams split coverage three ways.

• In-house set: five to eight Tier 1 devices for daily development and quick checks.
• Automation on device farms or emulators: fast functional checks across many OS versions, with the limits we cover in real devices vs emulators.
• Managed crowd: real people on real devices for Tiers 2 and 3, the long tail, and market-specific phones on local carriers.

The crowd is especially useful for the hardest cells in your matrix. For example, a cycle can include a Tecno phone in Lagos, a Redmi in Jakarta and a Moto G in São Paulo on the same day. On TestGate, vetted testers in 120+ countries use their own devices, and every report includes device model, OS build, skin and settings. Explore mobile app testing to see how coverage is selected, or read the platform overview for how results reach your tracker.

Keeping your device matrix current

A device matrix is a living document. Left alone, it goes stale within two quarters. Consequently, put maintenance on the calendar.

• Quarterly review: re-pull analytics, re-rank combinations by revenue and adjust tiers.
• OS launches: add new iOS and Android versions to Tier 1 when betas reach public testing, then again at release.
• Flagship launches: add new iPhone, Galaxy and Pixel models within weeks, because early adopters often spend more.
• Retirement rule: drop combinations below your usage threshold, for example under 0.5% of revenue for two consecutive quarters.
• Escaped defects: any production bug tied to an untested environment earns that environment a slot.

Finally, publish the matrix where everyone can see it. When product managers know which devices a release covered, they make better launch decisions, and fewer surprises reach your users.

Frequently asked questions

What is a device matrix?

A device matrix is the list of devices, OS versions, browsers and other environment variables you test on, grouped into tiers by priority. It turns fragmentation into a deliberate, data-backed coverage plan.

How many devices should my device matrix include?

Most teams cover their real user base well with 15 to 30 device and OS combinations across three tiers. The right number depends on how fragmented your audience is, especially on Android and in emerging markets.

How often should I update a device matrix?

Review it every quarter against your analytics, and update it immediately after major iOS and Android releases and flagship launches. Retire combinations that fall below your usage threshold.

Do I need to own every device in my matrix?

No. Keep a small in-house set for daily development, and use a managed crowd for the long tail. On TestGate, vetted testers cover real devices in 120+ countries, including the regional models that are hard to buy.

Cover your device matrix with TestGate

Fill every tier of your matrix with real devices, real OS builds and local carriers, with cycles that start in under 24 hours: talk to us.

#android testing #device fragmentation #device matrix #ios testing #mobile testing