There is no such thing as complete device coverage for a mobile app. The combinations of device, OS version, screen size, and manufacturer customization are effectively unlimited. The goal is a matrix that covers real risk, not every possibility.
The devices and OS versions your actual users are on should drive the matrix, not a generic "top 10 phones" list. A B2B app used mostly on company-issued iPhones has a very different risk profile than a consumer app with a long tail of budget Android devices.
Your top few devices by usage deserve full functional and visual testing. Everything else mostly needs a lighter pass: does it install, launch, and complete the core flow without crashing? That distinction alone cuts a huge amount of unnecessary testing.
Emulators and simulators are useful for quick functional checks, but they don't reliably surface real-world issues: network degradation, battery and thermal behavior, interrupt handling (a call or notification arriving mid-flow), or manufacturer-specific quirks. A small set of real devices in the mix catches problems emulators miss.
Device and OS version distribution shifts over time. A matrix built a year ago may be testing devices your users have already moved away from, while missing ones they've moved to. Revisiting it quarterly, against current analytics, keeps it relevant.
Talk to our QA team about mobile app testing.