Mobile QA is easy to underestimate because a mobile app looks like a smaller, simpler version of a web product. It isn't. Device fragmentation, OS-level permission models, unreliable networks, and app store review processes each introduce failure modes that don't exist on the web at all. A checklist built for web QA, lightly adapted, will miss most of what actually breaks mobile apps in production. Below is a practical device-and-OS strategy, the areas mobile QA teams consistently under-test, and a checklist you can adapt directly for your next release.
Device and OS Matrix Strategy
You cannot test every device, and the attempt to do so is how mobile QA budgets get consumed without proportional improvement in quality. Build a matrix instead, anchored in your actual analytics: cover the current OS version and the two prior major versions on both iOS and Android, since a meaningful share of users lag behind the latest release. On Android specifically, include at least one low-end device with limited RAM alongside a flagship, because performance and memory-related crashes on budget hardware almost never show up on a developer's high-end test phone. Cover a range of screen sizes and aspect ratios, not just the two or three the design team mocked up. And test key flows — camera, GPS, biometric login, push notifications — on real devices, not just simulators and emulators, since several of these behave meaningfully differently or aren't accurately simulated at all.
Permissions Testing
Permission handling is one of the most under-tested areas in mobile QA, and one of the most visible when it breaks. Test the grant path, the deny path, and — on both platforms — the 'ask every time' and limited-access options users increasingly choose by default. Test what happens when a user denies a permission the app assumes it has: a graceful fallback and a clear explanation, not a crash or a silently broken feature. Test permission revocation mid-session through OS settings while the app is running, and confirm the app detects the change and recovers rather than continuing to call an API it no longer has access to. Android's granular media and location permissions, and iOS's app tracking transparency prompt, both deserve their own explicit test cases.
Offline and Interrupted Connectivity
Mobile networks are unreliable by nature, and users expect apps to handle that gracefully rather than assume a stable connection like a desktop web app might. Test full offline mode: does the app show a clear state, queue actions for later, or fail silently? Test degraded connectivity — throttled to a slow speed — to see whether timeouts are set sensibly or whether the app just hangs. Test the transition from wifi to cellular mid-request, and the reverse, since a request that started on one network and needs to complete on another is a common source of dropped uploads and stuck spinners. Test backgrounding the app during an active network call, and test resuming after the OS has killed the app entirely to free memory — a very ordinary event on Android that development-device testing rarely reproduces. Finally, test data sync conflicts that occur when a device reconnects after changes were made elsewhere.
App Store Review Readiness
A build that passes every functional test can still get rejected or pulled for reasons that have nothing to do with bugs. Confirm store metadata — screenshots, description, age rating — accurately reflects what the app actually does; mismatches are a common rejection reason and an even more common source of user complaints after release. Verify the privacy label or data safety section matches the app's real data collection behavior, since app stores now actively cross-check this against network traffic. Test in-app purchase and subscription flows end-to-end, including restore-purchase and cancellation, if your app has them. And do a clean install and first-launch test on a device with none of your test accounts or cached data — the exact state a reviewer, and every new user, will actually see.
The Checklist
CategoryCheckDevice coverageCurrent OS plus two prior versions tested on both platformsDevice coverageAt least one low-end Android device includedDevice coverageMultiple screen sizes and aspect ratios coveredPermissionsGrant, deny, and limited-access paths all testedPermissionsMid-session revocation handled without a crashConnectivityFull offline mode shows clear state or queues actionsConnectivityWifi-to-cellular handoff mid-request testedConnectivityApp resume tested after OS terminationStore readinessMetadata and screenshots match actual app behaviorStore readinessPrivacy and data safety disclosures verified against real data useStore readinessClean install and first-launch flow testedGeneralPush notifications tested on real devices, foregrounded and backgroundedA checklist this broad is hard to run thoroughly on every release without a dedicated QA function, which is exactly why most mobile teams either burn engineering time on it or skip sections under deadline pressure. Qyrolax runs mobile QA across real device and OS matrices as part of its dedicated testing teams, so releases go out tested against what users actually run, not just what's on hand in the office.
