15 Device and OS Combinations to Consider When Planning Mobile App Testing

Build the test matrix from your own users, not from a generic device list. Cover your oldest supported iOS and Android versions, the latest releases and the versions you target, at least one low-end Android device, small and large screens, tablets and foldables if you support them, the manufacturers your users actually use, and the upgrade paths from older OS and app versions. Test the highest-risk combinations on real devices for every release and use emulators and cloud device services for wider coverage.

Testing on every device is impossible, and testing only on the team's own phones misses the people most likely to have problems. This list is for product owners, QA leads and developers planning release testing. It complements the wider mobile app testing guide, which covers test types, beta testing and store submission; for text size, dark mode and motion settings, see 12 text and display settings to test.

Pull OS versions, device models and screen sizes from your app analytics or crash reporting tool, and look at your store consoles: Google Play Console shows the devices and Android versions of your users. For a new app, use data from your website's mobile visitors in the target markets as a starting point and replace it with app data after launch.

Then rank combinations by two things: how many users they represent and how likely they are to break. A device used by few people but at the edge of your support range (the oldest OS, the smallest screen, the least memory) often finds more bugs than another popular flagship.

1. Oldest supported iOS version on the smallest supported iPhone. This is where layout overflow, missing APIs and availability checks fail. If your deployment target is several versions back, check that code paths guarded for newer APIs still work, and that the smallest screen still fits key buttons with larger text.

2. The latest iOS release on a current iPhone. New releases change system UI, permissions prompts and default behaviours. Apple also sets minimum SDK requirements for uploads: from 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 and the iOS 26 SDK. Building with a new SDK can change behaviour even on older devices, so retest after every SDK upgrade.

3. iPad, if your app runs on it. Universal apps need layout checks in both orientations, with split view and slide over, and with a keyboard and pointer. iPhone-only apps can still be installed on iPad in compatibility mode in many cases; decide whether that is acceptable and check that it does not look broken.

4. iPhones with different display shapes. Notch, Dynamic Island and home indicator areas affect headers, bottom navigation and full-screen media. Check safe areas on at least one older design and one current design.

5. Your minimum Android version (minSdk) on a low-memory device. Old OS versions tend to sit on older, slower hardware. Check startup time, scrolling, image-heavy screens and what happens when the system kills your app in the background. See app performance optimisation.

6. The Android version you target (targetSdk). Behaviour changes in Android often apply only when your app targets the new version, so raising targetSdk can break things on current devices. Google Play requires new apps and updates to target Android 16 (API 36) from 31 August 2026, with extensions to 1 November 2026 available on request, so the target version changes every year.

7. The latest Android release on a near-stock device. A Pixel or similar device shows the platform's own behaviour without manufacturer changes. It is the reference when deciding whether a bug comes from your code or from a manufacturer.

8. The manufacturers your users actually use. Manufacturers customise Android, including background task limits, battery optimisation, notification handling, keyboards and camera behaviour. If a large share of your users are on one or two brands, test on those, especially for push notifications, background sync and file uploads.

9. A low-end Android device. Low RAM, slower storage and older GPUs expose memory leaks, janky animations and timeouts that never appear on development phones. This matters most in markets where budget devices are common.

10. Edge-to-edge and display cutouts. Android 15 enforces edge-to-edge display for apps targeting API 35, so content draws behind the status and navigation bars unless you handle insets. Check that headers, bottom bars and floating buttons are not hidden on devices with cutouts and gesture navigation.

11. Tablets and foldables. For apps targeting Android 16 (API 36), the system ignores orientation, resizability and aspect-ratio restrictions on displays with a smallest width of 600dp or more; games are excluded, and the temporary opt-out is not available to apps targeting Android 17. An app that was locked to portrait may now appear in landscape and resizable windows on tablets and unfolded foldables, so test those layouts and the fold and unfold transition.

12. Rotation, split screen and multi-window. Configuration changes recreate screens on Android and resize them on iPad. Check that form input, scroll position, video playback and in-progress uploads survive rotation and window resizing.

13. OS versions where permissions changed. Permission behaviour differs by OS version: Android 13 introduced a runtime permission for notifications, and iOS lets users share approximate location or a limited set of photos. Test your permission flows on versions before and after each change you depend on, including the path where the user says no.

14. A mid-range device on a poor network. Combine slow, unreliable and switching connections with a mid-range device. Check loading states, timeouts, retries and offline behaviour; see offline-first planning.

15. Upgrades: a new OS under an existing install, and a new app version over old data. Many real users get your update on top of months of cached data and settings, sometimes after an OS upgrade. Install the previous store version, use it, then upgrade the OS or the app and check migrations, stored sessions and settings. Fresh installs on clean devices miss these bugs.

Split devices into tiers so the matrix stays affordable. The table is an illustrative structure; fill it from your own analytics.

A useful device matrix is small, based on your own users and weighted towards the edges of what you support: the oldest OS, the cheapest device, the largest screen and the upgrade path. Review it every few months against analytics and before each major OS release, and pair it with a staged rollout so problems that escape testing reach fewer people; see mobile app release management.

Google Play Console Help, target API level requirements for Google Play apps. Android Developers, behaviour changes for apps targeting Android 15 and Android 16. Android Developers, notification runtime permission (Android 13). Apple Developer, upcoming requirements (SDK minimum requirements). Accessed 5 November 2026.