Picture a release that passed everything. The regression suite was green on the team’s three test phones, the new checkout flow worked, and the build went out on a Thursday afternoon. By Friday morning, support had forty tickets from users who upgraded from the previous version and got logged out, and their saved carts were gone.
Nobody had tested an upgrade with real data on it. Not because it was hard, but because it wasn’t on anyone’s list.
That’s how most release-day bugs get through. They aren’t hidden in obscure code paths; they sit in checks nobody was assigned, on devices nobody had on their desk, or on OS versions that dropped out of the test plan months ago. This mobile app testing checklist is built to close those gaps: 60 checks grouped by release stage, each with how to verify it and when to run it, plus a device matrix that keeps coverage consistent from one release to the next.
If you’re newer to the discipline, start with the fundamentals of mobile app testing and come back. If you run releases, this list is meant to be copied, trimmed and owned.
How to Use This Checklist
A checklist only prevents missed checks if three things are true for every line on it:
- It has an owner. One named person, not a team. Shared ownership is how checks quietly get skipped.
- It has evidence. A link to a test run, a screenshot or a log. “Someone looked at it” isn’t evidence.
- It has a cadence. Each check below is tagged every build, every release, Major release or after release. Every-build checks belong in automation; the rest belong in the release plan.
Trim checks that don’t apply to your app (no payments, no tablets), but trim them on purpose and write down why. A check that’s missing by decision is fine. A check that’s missing by accident is the release-day bug.
Most release-day bugs aren’t hard to find. They’re in the checks nobody owned.
1. Release Scope and Readiness
Before anyone touches a device, agree what’s in the build and what could break. Five minutes here saves the classic surprise: a change that shipped without anyone testing it, because nobody knew it was in.
| # | Check | How to Verify | When |
|---|---|---|---|
| 1 | Release scope is frozen and listed | Every story, fix and config change in the build appears in the draft release notes, and nothing unlisted is in the diff. | Every release |
| 2 | Test scope is based on risk | Map each change to the journeys it can break. High-risk changes get more devices and exploratory time. | Every release |
| 3 | Every check has an owner and evidence | One named owner per check and a link to the result. Unowned checks are the ones that get skipped. | Every release |
| 4 | You’re testing the build you’ll ship | Signed release build, release configuration, minified and obfuscated, pointing at production services behind flags. Never sign off on a debug build. | Every release |
| 5 | Known issues are triaged | Every open bug is marked fix, ship with a workaround (plus a release-note line) or block, and the decision is recorded. | Every release |
2. Device and OS Coverage
This is where coverage drifts. The test devices stay the same while your users’ phones change, so each release is tested against a slightly less accurate picture of who actually uses the app. Build the matrix from data, then keep it current.
| # | Check | How to verify | When |
| 6 | Device matrix comes from your analytics | Top devices and OS versions by active users this quarter, not the phones on the team’s desks. Refresh it every quarter. | Major release |
| 7 | Oldest supported OS version | Core journeys on your minimum supported iOS and Android versions. Deprecated APIs and missing system features fail here first. | Every release |
| 8 | Newest OS, and the next one | IOS 27 and Android 17 are the current releases as of October 2026. Run core journeys on both, and on any beta likely to ship before your next release. | Every release |
| 9 | Smallest and largest screens | Smallest supported phone, a large phone and a tablet if you support one: look for clipped text, overlapping controls and keyboards covering inputs. | Every release |
| 10 | An entry-level Android device | The device with the least RAM in your matrix. Watch for slow starts and the app being killed in the background. | Every release |
| 11 | Manufacturer skins | At least the two largest Android manufacturers in your analytics. OEM battery savers and permission dialogs behave differently from stock Android. | Every release |
| 12 | Foldable and split screen, if supported | Fold, unfold and resize mid-task. State should survive the configuration change. | Major release |
| 13 | Real devices for the final pass | Emulators give breadth during development. Real devices are needed for camera, biometrics, push, GPS, performance and OEM behavior before release. | Every release |
For the last check, a real device cloud is the practical way to reach models nobody has in the office. And because Android coverage is the harder half, our guide to Android fragmentation covers how to pick devices that represent the long tail.
A device matrix that stays consistent
Inconsistent coverage usually means the matrix is a list of phones rather than a set of reasons. Organize it by tier instead:
| Tier | What goes in it | How to choose | When to run |
| Tier 1: core | 5–8 devices covering roughly three-quarters of your active users | Top devices and OS versions from analytics, both platforms | Smoke on every build, full suite every release |
| Tier 2: edges | Oldest supported OS, newest OS and beta, smallest screen, lowest-RAM device, tablet or foldable if supported | One device per risk, not per brand | Every release |
| Tier 3: long tail | A rotating sweep of other models and manufacturer skins | Real device cloud, changing models each release | Major releases and quarterly |
The tiers are a starting point. Check them against your crash reports: a device that keeps appearing there belongs in Tier 1 or 2, whatever its market share.
3. Install, Update and Data Migration
Fresh installs get tested constantly. Upgrades, where real users actually arrive, mostly don’t. That’s backwards: on release day, most of your users get the new version as an update, carrying whatever data the old one left behind.
| # | Check | How to verify | When |
| 14 | Clean install on every Tier 1 device | Fresh install, first launch, onboarding and every permission prompt, on the release build. | Every release |
| 15 | Upgrade from the current store version | Install today’s production version, create real data, then upgrade. Login persists, data migrates, nothing resets. | Every release |
| 16 | Upgrade across several versions | Upgrade from the oldest version still in meaningful use (check analytics). Users skip releases. | Major release |
| 17 | Data migrations are safe | Schema and storage migrations run once, survive being interrupted (kill the app mid-upgrade) and never lose data. | Every release |
| 18 | App size is explained | Compare download and install size with the last release, and explain any jump before users notice it. | Every release |
| 19 | Reinstall and restore | Reinstall restores what it should (cloud backup, saved settings) and nothing it shouldn’t (stale tokens, old sessions). | Major release |
4. Core Journeys and Functional Regression
These are the checks most teams already run. The value of listing them is consistency: the same journeys, on the same matrix, every time, with failures investigated rather than re-run until they pass.
| # | Check | How to verify | When |
| 20 | Smoke test on the release build | Launch, log in, reach the main screen, complete one core transaction, log out, on every Tier 1 device. | Every build |
| 21 | Critical journeys end to end | The 5–10 journeys that earn money or keep users (sign-up, purchase, booking, sharing) pass on the full matrix. | Every release |
| 22 | Regression is green, with flaky tests quarantined | Failures are investigated, not re-run until green. Flaky tests are tracked separately so they don’t hide real breaks. | Every build |
| 23 | Authentication edge cases | Expired sessions, password reset, biometric login, single sign-on, multi-factor and switching accounts. | Every release |
| 24 | Payments and in-app purchases | Purchase, restore, renewal and cancellation in the sandbox, with receipts validated on the server. | Every release |
| 25 | Push notifications and deep links | Notifications open the right screen from killed, background and foreground states. Deep links and app links route correctly. | Every release |
| 26 | Feature flags in both states | Every flag in the release is tested on and off, and its launch default is set and recorded. | Every release |
Check 22 deserves a word. A suite that’s “mostly green” trains everyone to ignore red, which is how a real regression ships. Our guide to flaky tests covers how to separate noise from genuine failures.
5. Interruptions, Network and Device State
Phones get interrupted constantly, and test labs barely interrupt them at all. This group recreates real life: bad signal, incoming calls, an OS that kills your app to free memory, and users who say no to permissions.
| # | Check | How to verify | When |
| 27 | Offline and poor networks | Airplane mode mid-request, a slow network profile and a Wi-Fi to cellular switch. No data loss, clear messages, sensible retries. | Every release |
| 28 | Backgrounding and process death | Background mid-task, let the OS kill the app (Android’s “Don’t keep activities” option helps), then return. State is restored. | Every release |
| 29 | Interruptions during critical flows | Incoming call, alarm, notification shade and low-battery dialog during payment, upload and form entry. | Major release |
| 30 | Permissions denied and revoked | Deny each permission, grant one-time access (“Allow once”, “Only this time”) or approximate location, and revoke in settings while the app runs. It degrades gracefully. | Every release |
| 31 | Device settings | Dark mode, largest text and display size, reduced motion, battery saver or Low Power Mode, another locale and 24-hour time. | Every release |
| 32 | Dates, times and time zones | Change time zone mid-session, cross a daylight-saving change, switch 12/24-hour format. Schedules and timestamps stay right. | Major release |
6. Performance, Stability and Battery
On Android, performance has a scoreboard. Google Play’s Android vitals set bad-behavior thresholds, and an app that exceeds them can lose visibility on Google Play or get a warning on its store listing. Treat them as ceilings, not targets.
| # | Check | How to verify | When |
| 33 | No new crashes or ANRs | No new crash signatures in pre-release testing. In production, stay under Android vitals’ 1.09% user-perceived crash rate and 0.47% ANR rate overall, and 8% on any single phone model. | Every release |
| 34 | Startup time hasn’t regressed | Measure cold start on your lowest-tier device and compare with the last release. Investigate any regression before shipping. | Every release |
| 35 | Memory holds steady | A 30-minute session on a low-RAM device with no steady growth and no out-of-memory kills. Google says memory vitals may affect Play visibility from February 2027. | Major release |
| 36 | Battery and background work | Location, sync and wake locks behave in the background. Android vitals flags excessive partial wake locks above a 5% threshold. | Major release |
| 37 | Network efficiency | Payload sizes, calls per screen and image sizes on cellular. No polling loops left running. | Major release |
| 38 | Smooth scrolling and animation | Long lists, image-heavy screens and transitions on the low-end device, with no visible stutter. | Major release |
| 39 | Back end ready for release-day load | The APIs the new version calls are load-tested for launch traffic, including the spike after a push notification. | Major release |
7. UI, Accessibility and Localization
Layout bugs are the ones users screenshot. Accessibility bugs are the ones some users can’t get past at all, and in the EU they’re now a compliance issue for many consumer services, not only a quality one.
| # | Check | How to verify | When |
| 40 | Layout across sizes and orientations | Rotation where supported, notches and camera cut-outs, safe areas and on-screen keyboards. | Every release |
| 41 | Visual regressions | Compare screenshots with the last release across the matrix, and sign off intentional changes. | Every release |
| 42 | Screen readers | Core journeys can be completed with VoiceOver and TalkBack: every control labelled, focus order logical. | Every release |
| 43 | Text size, contrast and color | Largest text sizes don’t truncate content. Contrast meets WCAG 2.2 level AA, and color is never the only signal. | Every release |
| 44 | Accessibility claims match reality | If you publish Apple’s Accessibility Nutrition Labels, users must be able to complete all common tasks with each declared feature. EU consumer services such as banking and e-commerce have been covered by the European Accessibility Act since 28 June 2025. | Major release |
| 45 | Localization | Every shipped language: truncation, right-to-left layout, plurals, date, number and currency formats, untranslated strings. | Every release |
| 46 | Copy and legal text | Release notes, in-app messages, terms and privacy links are current and correct in every locale. | Every release |
8. Security and Privacy
Security testing deserves its own plan, and our mobile app security testing guide covers it in depth. These six checks are the release-day minimum: the ones that should never depend on someone remembering.
| # | Check | How to verify | When |
| 47 | Data at rest | No tokens, passwords or personal data in plain text in local storage, logs or screenshots. Secrets live in the Keychain or Keystore. | Every release |
| 48 | Data in transit | TLS everywhere with certificate validation enforced, and no clear text exceptions left over from debugging. | Every release |
| 49 | Sessions and tokens | Tokens expire and refresh correctly, logout invalidates the session on the server, and a revoked token gets nothing. | Every release |
| 50 | Permissions match your disclosures | Every permission has a reason string, is actually used, and matches your App Store privacy details and Google Play Data safety form. | Every release |
| 51 | iOS privacy manifest | Your app and its third-party SDKs declare approved reasons for required-reason APIs. Apple has required this for uploads since May 2024. | Every release |
| 52 | Account deletion works | If users can create an account, they can delete it in the app (both stores require this), and Google Play also requires a web link to request deletion. | Major release |
9. Store Compliance and Release Mechanics
Store rules change on fixed dates, and a missed one doesn’t produce a bug. It produces a rejected upload on the day you planned to ship. These checks also cover how the release goes out, because a good rollout plan turns a bad build into a small incident instead of a big one.
| # | Check | How to verify | When |
| 53 | Build meets current platform requirements | Google Play: new apps and updates must target Android 16 (API level 36) from 31 August 2026, with extensions to 1 November 2026 on request. Apple: uploads need Xcode 26 and the iOS 26 SDK, and must target iOS 13 or later. | Every release |
| 54 | 16 KB memory pages (Android) | Apps targeting Android 15 or later must support 16 KB page sizes on 64-bit devices. From 1 February 2027, updates that don’t can’t be released. Test native libraries on a 16 KB device or emulator image. | Major release |
| 55 | Store listing is current | Screenshots, description, what’s-new text and age rating answers (Apple’s updated questionnaire) are up to date, and every link works. | Every release |
| 56 | Staged rollout plan | Phased release on the App Store or a staged rollout percentage on Google Play, with a named owner watching and a halt threshold agreed in advance. | Every release |
| 57 | Kill switch and hotfix path | Remote flags can switch the new feature off without a new build, and a hotfix path is ready. You can’t roll back a binary on users’ phones. | Every release |
| 58 | Monitoring is live on the release build | Crash reporting, analytics events for new features, and alerts on crash rate and key funnels all verified on the release build. | Every release |
10. After You Ship
Release day isn’t the end of testing; it’s the start of the only test with every real device in it. Two checks keep that test useful.
| # | Check | How to verify | When |
| 59 | Watch the first 24–72 hours | Crash-free users, ANRs, ratings, support tickets and key funnels against the previous version. Pause the staged rollout if a threshold breaks. | After release |
| 60 | Hold a 15-minute release retro | Record what escaped, which check would have caught it, and add or adjust a check. This list should change every quarter. | After release |
The Release Gate: Checks That Should Stop a Ship
Not every check is a blocker. Some are judgement calls for the release manager. These twelve, though, should stop a release outright if they fail:
THE RELEASE GATE Build and scope: 4 (testing the build you’ll ship) Coverage: 7 and 8 (oldest and newest OS) Upgrades: 15 (upgrade from the store version, with real data) Journeys: 21 (critical journeys on the full matrix) Stability: 33 (no new crashes or ANRs) Security: 47, 48 and 49 (data at rest, in transit, sessions) Store and rollout: 53 (platform requirements), 56 and 57 (staged rollout, kill switch)
Write the gate into your release template, and make the release manager’s sign-off depend on evidence for each of these twelve, not a verbal “looks good”.
What to Automate, and What to Keep Human
Around half of this list can run without anyone watching: smoke tests, regression, visual comparisons, performance baselines and basic security checks across the device matrix on every build. That’s the job of mobile app testing tools, and our comparison of the leading options covers the trade-offs. The point is consistency. A machine runs check 20 on all eight Tier 1 devices every time; a tired person on release day runs it on two.
The other half needs judgement: exploratory testing around risky changes, accessibility with real assistive-technology users, reviewing the store listing, and deciding whether to halt a rollout. If you need a refresher on how those fit together, our guide to mobile app testing types maps each type to what it’s good at.
Where Sofy mobile testing agent comes in
Sofy’s mobile testing agents are built for the half of this checklist that should run on every build. AI agents generate, execute and maintain tests on real iOS and Android devices, covering native, React Native, Flutter and hybrid apps, and tests are written in plain language rather than scripts.
Mapped to the list above, that covers:
- Coverage (checks 6–13): the same tests on your full device matrix, on real devices, so Tier 2 and Tier 3 aren’t skipped when time runs short.
- Regression (20–22): smoke and regression runs triggered from GitHub Actions, Azure DevOps, CircleCI or GitLab on every build.
- Performance (33–38): CPU, memory, battery and network monitored across device configurations, with crash monitoring alongside.
- Visual checks (41): visual QA that flags inaccuracies across devices.
- Security (47–49): security testing on a schedule or tied to pipeline events.
What Sofy doesn’t replace: exploratory testing, testing with people who use assistive technology every day, or the release decision itself. The goal is that the people on your team spend release day on judgement, not on re-running the same smoke test on another phone.
Frequently Asked Questions
What should a mobile app testing checklist include?
At minimum: release scope, device and OS coverage, install and upgrade paths, core user journeys, interruptions and network conditions, performance and stability, accessibility and localization, security and privacy, store compliance, and post-release monitoring. Each check needs an owner, evidence and a cadence.
How many devices should you test on before a release?
Use tiers rather than a single number: five to eight core devices that cover most of your active users, one device per edge risk (oldest and newest OS, smallest screen, lowest RAM), and a rotating long tail on a real device cloud for major releases.
Which OS versions should you test?
Your minimum supported version, the current release (iOS 27 and Android 17 as of October 2026), any beta likely to ship before your next release, and the versions your analytics show most of your users running.
What is the most commonly missed pre-release check?
Upgrading from the current store version with real data on the device. Teams test fresh installs constantly, but most users arrive on release day as an upgrade, and that’s where migrations, logouts and lost data show up.
What are the 2026 App Store and Google Play requirements?
Google Play requires new apps and updates to target Android 16 (API level 36) from 31 August 2026, with extensions to 1 November 2026. Apple requires uploads built with Xcode 26 and the iOS 26 SDK. Apps targeting Android 15 or later must support 16 KB memory pages, and from 1 February 2027 updates that don’t will be blocked.
Can a mobile app testing checklist be automated?
Around half of it. Smoke, regression, visual, performance and basic security checks can run automatically on every build across your device matrix. Exploratory testing, accessibility with assistive-technology users, store listing review and rollout decisions still need people.
The Bottom Line
Releases rarely fail on the checks everyone remembers. They fail on the upgrade path nobody tried, the OS version that slipped out of the matrix, or the store rule that changed in August. A checklist fixes that only if every line has an owner, evidence and a cadence.
Copy the 60 checks, cut the ones that don’t apply on purpose, build your device matrix from real usage, and make the twelve gate checks non-negotiable. Then let automation carry the repetitive half, so the people on your team can focus on the judgement calls.