Mobile App Testing Checklist: What to Test Before Every Release (2026)

A mobile app testing checklist before release needs eleven areas covered: core functional flows and form validation, device/OS matrix coverage, permission grant/deny/“don’t ask again” paths, offline and degraded-network handling, push notifications, deep links, app lifecycle behavior, App Store and Google Play compliance, an accessibility pass, performance and battery checks, and a defined split between what the automated suite re-runs every release and what stays manual. Skip any one of these and you ship the bugs that show up most in app-store reviews: a permission crash, a dead deep link, a form that loses its state after backgrounding. This is a copy-paste checklist for each area, with what’s actually required by Apple and Google today — not the version of their guidelines everyone still repeats from a few years back. Where we reference Qualflare, it’s a results/observability layer for the automated side of this checklist — not a device lab, so it doesn’t run any of the checks below itself.

What functional flows should you test before every mobile release?

Functional regressions are the ones users notice within seconds, and they’re still the most common release blocker.

• Every primary user journey completes end-to-end: sign-up, login, core purchase or primary action flow, sign-out
• Form validation covers required fields, invalid formats (email, phone, card number), and boundary values (min/max length, special characters)
• Navigation: back button/gesture on every screen, tab switches preserve state, deep navigation stacks don’t strand the user
• Empty, loading, and error states each render correctly — not just the happy path
• Keyboard input, autofill, and paste all populate fields correctly
• Rotating the device mid-flow doesn’t lose entered data

What devices and OS versions should you test on before release?

Android and iOS fragment very differently, so “test on real devices” means different coverage on each platform. As of mid-2026, iOS 26 alone runs on roughly 79% of iPhones, per Apple’s own adoption data; Android’s install base is split much wider — Android 16, the single most common version, covers only about 25% of devices, and it takes six versions combined to reach roughly 89% coverage, per StatCounter’s Android version market share data.

• Test the current OS version plus at least the previous two major versions, on each platform
• Include at least one low-end or low-memory Android device — fragmentation-driven bugs surface there first, not on a flagship
• Include at least one small-screen and one large-screen device per platform
• Set your app’s minimum supported OS version deliberately, based on usage data, and test that floor explicitly
• Test at least one real device per platform — emulator/simulator-only testing misses timing, sensor, and memory-pressure differences

How do you test permission grant, deny, and “don’t ask again” flows?

Permission flows are commonly under-tested because the happy path (grant) is the only one most manual passes ever exercise — and it shows: Pew Research found 43% of users have uninstalled an app after discovering how much personal data it wanted, and 60% declined to install one in the first place for the same reason.

• Grant path: the permission is requested at the moment it’s needed, not on first launch, and granting it produces the expected behavior
• Deny path: a single refusal leaves the feature gracefully degraded — no crash, a clear explanation of what’s missing
• Permanent-denial path: after repeated refusal, Android stops showing the system dialog and treats it as “don’t ask again”; iOS does the same after one denial. Both require the app to route users to Settings instead of re-prompting into nothing
• Revoke mid-session: the user revokes a permission from system settings while the app is running or backgrounded — the next permission-gated action shouldn’t crash
• Test camera, location, notifications, and contacts permissions individually — one working flow doesn’t validate another’s UX
• On Android, reset permission flags between test runs (adb shell pm clear-permission-flags) so denial testing isn’t polluted by a prior run’s state

How do you test offline and flaky network conditions?

Apps that assume a reliable network fail in front of users constantly, so this pass has to include failure, not just absence.

• Cold start in full airplane mode — the app doesn’t crash and shows a clear offline state
• Enable airplane mode mid-session, during an active request — the in-flight request fails visibly instead of hanging silently
• Throttle to a slow/flaky connection (a 3G-equivalent profile) for every critical flow, not just the happy path on Wi-Fi
• Network loss mid-request doesn’t leave the UI in an inconsistent state — no double-charged payment, no half-submitted form
• Reconnection recovers and syncs queued actions once connectivity returns, without duplicate submissions
• Test on a real cellular connection at least once — simulator-only throttling doesn’t reproduce every real-world failure mode

What should you test for push notifications before release?

The three app states — foreground, background, killed — each handle a tapped notification differently, and it’s the killed-app path teams forget.

• Notifications deliver and display correctly with the app in foreground, background, and fully killed states
• Tapping a notification from a cold start (app not running) opens to the correct screen, not just the home screen
• Tapping a notification with the app backgrounded (warm start) resumes to the correct screen without restarting the session
• Foreground notification handling doesn’t duplicate or silently suppress the visual notification
• Denying notification permission doesn’t break the rest of the app
• Rich payloads — images, action buttons — render and route correctly when tapped

How do you test deep links and universal links?

Cold-start and warm-start deep links are functionally different code paths, and testing only one is the most common gap.

• Every deep/universal link routes correctly from a cold start (app not running)
• Every deep/universal link routes correctly from a warm start (app already running in the background), without losing prior state
• Malformed or unrecognized links fail gracefully — a fallback screen or web redirect, not a crash
• Links that require authentication route to login first, then continue to the intended destination after sign-in
• iOS universal links and Android App Links are verified against their domain association files (apple-app-site-association, Digital Asset Links) — a misconfigured file silently falls back to the browser instead of opening the app

What app lifecycle scenarios should you test?

Backgrounding is not the same as process death, and a suite that only tests the former misses most real-world state loss.

• Backgrounding and returning preserves scroll position, form input, and navigation state
• Force-kill the process (not just background it) and relaunch — critical state restores, or the app recovers gracefully instead of dropping the user mid-flow
• Simulate low-memory conditions — Android’s background process death, iOS’s memory-warning termination — and confirm unsaved input survives
• Switching to another app mid-upload or mid-download doesn’t silently cancel the operation
• Interruptions mid-flow (incoming call, low-battery alert, OS update prompt) don’t corrupt app state

What App Store and Google Play compliance checks belong in QA?

• Account deletion: if the app supports account creation, an in-app deletion path exists — required under Apple’s Guideline 5.1.1(v) and Google Play’s account deletion policy
• A privacy policy link is present in both the store listing and inside the app
• Permission purpose strings (iOS Info.plist usage descriptions, Android permission rationale) accurately describe why each permission is requested — vague strings are a common rejection reason
• iOS: a privacy manifest (PrivacyInfo.xcprivacy) is present and declares required-reason API usage for any covered APIs the app or its SDKs use
• Android: the Play Console Data safety declarations match what the app actually collects and shares
• The actual submission build is what’s tested — not a dev build with debug flags or test payment methods still enabled

What accessibility checks belong in a mobile release checklist?

• A full TalkBack (Android) and VoiceOver (iOS) pass on every primary flow — confirm spoken labels make sense out of context, not just that tab order works
• Every interactive element is reachable by swipe/linear navigation, not just visible on screen
• Test at the largest supported Dynamic Type / font-scale setting — text should reflow, not truncate or overlap
• Check color contrast against WCAG AA minimums, especially on custom-themed components that skip platform defaults
• Touch targets meet platform minimums so they’re reachable for users with motor impairments
• Run an automated pass (Android’s Accessibility Scanner or Compose UI Check Mode, Xcode’s Accessibility Inspector) as a baseline — it catches contrast and labeling gaps a manual pass misses

What performance and battery checks belong before release?

• Cold-start time measured on a low- or mid-range device, not just a current-year flagship
• Memory footprint stays within reasonable bounds during a realistic session — watch for growth that doesn’t release, not just peak working-set size
• Battery drain measured over a realistic usage session (roughly 30 minutes of typical use), not just idle background drain
• Frame rate and jank on scroll- or animation-heavy screens, specifically on a lower-spec device
• App download and install size checked against your own release-over-release trend

What regression should you automate vs. test manually before release?

Mobile build flakiness is trending the wrong way — Bitrise’s analysis of 10M+ mobile builds found the share of teams hitting flakiness rose from 10% in 2022 to 26% in 2025, while teams using monitoring/observability tooling saw roughly 25% fewer flaky reruns. That’s the argument for being deliberate about what actually earns automated coverage, rather than automating everything and drowning in reruns. The split follows the same logic as manual vs. automated mobile testing generally: automate what’s regression-prone and cheap to keep green, keep manual what’s expensive or impossible to simulate.

• Automate, every release: the critical-path regression suite — login, core transaction flow, navigation — in Espresso, XCTest, or Maestro
• Automate: re-run any previously flaky test that’s since been fixed, to confirm the fix held under real CI conditions, not just locally
• Keep manual: new-OS-beta compatibility passes, before the OS has enough real-world usage to trust an emulator/simulator result
• Keep manual: camera, biometric (Face ID/fingerprint), and real push-notification hardware flows that are expensive or impossible to fully simulate in CI
• Keep manual: subjective UX judgment calls that a pass/fail assertion can’t capture

How do you turn this checklist into a release gate?

Running this list once and forgetting it is how the same regressions creep back in. Turn it into a living test plan with explicit entry/exit criteria, and pair it with release-readiness quality gates so “is this build safe to ship” becomes a measured answer instead of a gut call the week of submission. For the fuller picture of how Android and iOS test management fits together end to end, see the complete guide to mobile testing.

Start free with Qualflare — feed in your Espresso, XCTest, or Maestro regression results and see which parts of this checklist are actually stable release over release, not just green on the last run.

Frequently asked questions

What should be on a mobile app testing checklist before release?

At minimum: core functional flows and form validation, device/OS matrix coverage, permission grant/deny/“don’t ask again” paths, offline and degraded-network handling, push notification delivery and deep-link routing, app lifecycle behavior (backgrounding, process death, low memory), App Store/Google Play compliance items, an accessibility pass, performance and battery checks, and a defined split between what the automated suite re-runs every release and what stays manual.

How many devices and OS versions should you test on before release?

Cover the current OS version plus the previous two major versions on each platform, at least one low-end Android device (fragmentation issues surface there first), and at least one real device per platform rather than emulator/simulator only. Android’s install base needs far more coverage than iOS’s: the single most common Android version (16) covers only around 25% of devices, while iOS 26 alone covers close to 79% of iPhones.

What’s the difference between testing permission grant, deny, and “don’t ask again” flows?

Grant testing confirms the feature works once access is allowed. Deny testing confirms the app degrades gracefully — no crash, a clear explanation of what’s missing — after a single refusal. “Don’t ask again” testing covers the permanent-denial state both platforms enforce after repeated refusal, where the system dialog stops appearing entirely and the app has to route the user to Settings instead of re-prompting into nothing.

Does Apple or Google Play require account deletion inside the app?

Yes, both. Apple’s App Store Review Guideline 5.1.1(v) requires apps that support account creation to also offer account deletion within the app. Google Play’s account deletion policy requires both an in-app deletion path and a web-based deletion request option for the same category of apps.

What should you automate vs. test manually before a mobile release?

Automate the critical-path regression suite — login, core transaction flow, navigation — in Espresso, XCTest, or Maestro, and re-run any previously flaky test that’s since been fixed to confirm it held under real CI conditions. Keep manual: new-OS-beta compatibility passes, camera/biometric/real-push-notification hardware flows that are hard to fully simulate, and subjective UX judgment calls no assertion can capture.

How does Qualflare fit into a mobile release checklist?

Qualflare doesn’t run any of the checks on this list — it doesn’t provision devices, execute tests, or check store compliance. It’s a results and observability layer: once your Espresso, XCTest, or Maestro suite runs these checks in CI, Qualflare ingests the JUnit-XML results and tracks which tests are actually flaky versus genuinely broken, so the regression section of this checklist is backed by historical data instead of a single green or red run.