Most app rejections are not caused by exotic bugs. They are caused by a missing privacy answer, a crash on a five year old Android phone, a login screen that spins forever on a weak connection, or a demo account that stopped working the day before review. All of those are cheap to catch and expensive to discover after submission.
This mobile app testing checklist is the list our QA team runs before any build leaves the building. It is organised by category, it explains why each check matters, and it describes what the failure looks like in production so you can recognise the symptom in your own app. Work through it top to bottom and you will have eliminated the large majority of App Store and Google Play rejection reasons before a reviewer ever opens your binary.
How to use this checklist
- Run it on the release candidate, not on a debug build. Release builds behave differently: code stripping, obfuscation, different API keys, production analytics, real payment endpoints.
- Timebox it. A focused team can complete all 32 checks in one to two days for a mid sized app. Block the time before you announce a launch date.
- Record evidence. One screenshot or short screen recording per check. If a reviewer pushes back, you already have proof of the behaviour.
- Mark severity, not just pass or fail. Use three buckets: blocker (do not submit), fix in this release, backlog.
- Freeze the build. No code changes during the checklist run. If you patch something, restart the affected category.
The rejection reasons this checklist is designed to prevent
Before the checks themselves, it helps to know what reviewers actually reject apps for. These are the recurring ones we see across client submissions on both stores.
| Rejection reason | Typical trigger | Checks that cover it |
|---|---|---|
| Crashes and obvious bugs | Crash on launch on a device or OS version nobody tested | 8 to 12, 17 |
| Broken or incomplete review access | Expired demo credentials, OTP only login, region locked content | 27, 28 |
| Privacy and data disclosure mismatch | SDK collects data that the privacy form does not declare | 23, 24, 29 |
| Account creation without deletion | Sign up exists, in app account deletion does not | 30 |
| Payments outside store rules | Digital goods sold through an external checkout | 31 |
| Permission requested without context | Location or contacts prompt on first launch with no explanation | 22 |
| Metadata and screenshot issues | Screenshots that do not match the build, competitor names in keywords | 32 |
| Placeholder or unfinished content | Lorem ipsum, dead links, empty tabs, test data visible | 6, 7 |
Category 1: Core functionality (checks 1 to 7)
1. Complete the primary user journey end to end, three times
Define the one journey your app exists for: sign up, first meaningful action, result. Run it fully on a clean install, then on an upgrade install, then on a second account.
- Why it matters: Teams test features in isolation and rarely test the whole path in one sitting. Breakage lives in the joins.
- Failure in production: Users sign up, hit a dead end at step three, and churn within the first session. Your funnel shows high installs and near zero activation.
2. Test every authentication path, including recovery
Email and password, social sign in, magic link, biometrics, two factor, password reset, expired session, logout, and login on a second device.
- Why it matters: Auth is the narrowest gate in the app. A single broken path locks out a whole segment of users, and it is also the first thing a store reviewer touches.
- Failure in production: Social login works on iOS but returns an invalid redirect on Android, so a third of your signups silently fail.
3. Validate every form field, in both directions
Submit empty, submit too long, submit emoji, submit leading and trailing spaces, submit right to left text, paste a 500 character string, and submit valid data twice quickly. Mobile App Testing Checklist: The Ultimate Guide covers this in more depth.
- Why it matters: Input handling is where data corruption starts, and duplicate submits create duplicate records or double charges.
- Failure in production: Support receives two identical orders from the same user and nobody can explain it.
4. Interrupt the app mid task
During a critical action (upload, payment, form submission) trigger an incoming call, a system alert, a screen lock, an app switch, a notification tap, and a low battery warning. Then return.
- Why it matters: Mobile apps are constantly interrupted. State restoration is the most commonly skipped test in the entire pipeline.
- Failure in production: A user answers a call during checkout and returns to an empty cart, or worse, to a charge with no order.
5. Test push notifications, deep links and app links
Tap a notification with the app closed, backgrounded and open. Open a universal link or Android App Link from email, from a browser, from a chat app, and while logged out.
- Why it matters: Links from marketing campaigns bypass your normal navigation and hit screens in unexpected states.
- Failure in production: A campaign link opens a blank screen or bounces to the web, and your paid acquisition spend goes nowhere.
6. Hunt every empty, loading and error state
Create a brand new account with zero data. Visit every screen. Then force server errors (400, 401, 403, 500, timeout) and see what the user is told. testrail.com makes the same point with more data.
- Why it matters: Reviewers open your app with an empty account, exactly like a new user. Empty states are their first impression.
- Failure in production: A new user sees three blank tabs and a spinner that never stops, then uninstalls.
7. Remove test artefacts and placeholders
Search the build for lorem ipsum, TODO, “test”, staging URLs, debug menus, verbose logging, mock data, and hidden feature flags left on.
- Why it matters: Unfinished content is an explicit rejection reason on both stores, and a staging endpoint in a release build is a real security incident.
- Failure in production: Production traffic hits your staging database, or users find a debug screen that exposes internal IDs.
Category 2: Device and OS compatibility (checks 8 to 12)
8. Build a device matrix from your own analytics
Do not test on whatever phones the team happens to own. Pull your actual install base by device model, OS version and screen size, then weight by session volume and crash rate.
- Why it matters: A device that carries 8 percent of your sessions deserves a slot in the matrix. The flagship on the CTO’s desk may carry 0.3 percent.
- Failure in production: A crash confined to one popular mid range Android family drags your Play Console vitals below the bad behaviour threshold and your store ranking drops.
A workable minimum matrix for a new app looks like this:
| Slot | iOS | Android | What it catches |
|---|---|---|---|
| Newest OS, current flagship | Latest iPhone Pro | Latest Pixel or Galaxy S | New OS API behaviour changes |
| Smallest supported screen | iPhone SE class | Compact 5.5 inch device | Clipped buttons, unreachable CTAs |
| Low end hardware | Oldest supported iPhone | 2 to 4 GB RAM Android Go class | Slow start, jank, out of memory kills |
| Oldest supported OS | Minimum iOS target | Minimum API level | Missing APIs, deprecated calls |
| Large format | iPad | Tablet or foldable | Stretched layouts, resize crashes |
9. Verify layout on notches, cutouts, rounded corners and safe areas
- Why it matters: Content hidden behind a dynamic island, a camera cutout or a home indicator makes essential controls untappable.
- Failure in production: The “Continue” button sits under the gesture bar on one device family and that cohort never converts.
10. Test rotation, split screen, foldables and window resizing
- Why it matters: A configuration change destroys and recreates views. Unsaved state disappears and poorly handled resize crashes the process.
- Failure in production: A user unfolds their phone mid form and loses everything they typed.
11. Test accessibility and system display settings
Largest dynamic type or font scale, bold text, dark mode, high contrast, reduce motion, screen reader (VoiceOver and TalkBack) on the primary journey.
- Why it matters: A large share of users run non default text sizes. It is also an accessibility obligation in a growing number of markets, including the European accessibility rules now in force.
- Failure in production: At 200 percent text scale labels overlap and the price is unreadable, so users cannot tell what they are buying.
12. Test upgrade installs and data migration
Install the currently live store version, create data, then install the release candidate over the top. Repeat from two versions back.
- Why it matters: Fresh installs pass while upgrades crash because of a database schema or stored preference change. Existing users are your most valuable users.
- Failure in production: The update ships, loyal users lose their local data or crash on launch, and one star reviews arrive within hours.
Category 3: Network and offline behaviour (checks 13 to 16)
13. Run the app fully offline, from launch
- Why it matters: Reviewers and users open apps in lifts, planes, basements and on trains. An app that shows a white screen offline reads as broken.
- Failure in production: Cached content is available but the app blocks on a network call at startup and shows nothing.
14. Test on a throttled, high latency connection
Simulate 2G or a 500 ms latency, 1 percent packet loss profile. Check every loading state, timeout, and retry.
- Why it matters: Fast office WiFi hides the absence of loading indicators and sane timeouts.
- Failure in production: The user taps “Pay” three times because nothing visibly happened, and the backend receives three requests.
15. Switch networks mid request
Start an upload or sync, then move from WiFi to mobile data, enable airplane mode for ten seconds, and come back.
- Why it matters: Real sessions change transport constantly. Sockets die, tokens expire, and requests need to be idempotent.
- Failure in production: A half uploaded file is stored as a corrupt record, or the queue retries forever and drains the battery.
16. Verify offline queue and conflict resolution
Make changes offline on two devices for the same account, then bring both online.
- Why it matters: Silent data loss is the hardest bug class to recover trust from, because users only notice long after it happened.
- Failure in production: Device B overwrites device A, the user loses notes, and your support team cannot restore them.
Category 4: Performance, memory and battery (checks 17 to 21)
17. Measure cold start on your slowest supported device
- Why it matters: Startup time is the first quality signal a user gets, and Play Console tracks excessive slow cold starts as a technical quality metric that can affect store visibility.
- Failure in production: A four second splash on low end hardware pushes early drop off well above your benchmark.
Working targets: cold start under 2 seconds on mid range hardware, under 3 seconds on your slowest supported device, first meaningful content visible before any animation finishes.
18. Profile scrolling and animation for dropped frames
- Why it matters: Jank is perceived as cheapness. Long image lists and heavy shadows are the usual culprits.
- Failure in production: The feed stutters on the devices most of your users own, even though it is smooth on the design team’s phones.
19. Run a long session soak test
Use the app for 30 to 45 minutes, navigating in and out of heavy screens repeatedly, and watch memory.
- Why it matters: Leaks only show under sustained use. The OS then kills your app and the crash report looks random.
- Failure in production: Users report the app “closing by itself” and the stack traces point nowhere useful.
20. Check battery, background activity and thermal behaviour
- Why it matters: Location polling, permanent sockets and aggressive background sync get your app flagged in system battery reports, and users uninstall based on that screen alone.
- Failure in production: Your app appears in the top three battery consumers after a day of normal use.
21. Audit app size and download footprint
- Why it matters: Install conversion drops as size grows, especially over mobile data and in markets with limited storage.
- Failure in production: Users abandon the download, or cannot install because the device is full. Ship an Android App Bundle, strip unused assets, and check the actual delivered size, not the archive size.
Category 5: Security, privacy and data (checks 22 to 26)
22. Request every permission just in time, with context
- Why it matters: Both stores reject permission requests that are unjustified or unexplained, and iOS requires a clear purpose string for each one.
- Failure in production: A camera prompt on first launch is denied by most users and the core feature becomes unreachable, with no path to re enable it.
Also test the denied path: what does the app do when the user says no, and can they recover from settings?
23. Inventory every SDK and what it actually collects
- Why it matters: Your privacy declarations must cover third party collection too. Apple also requires privacy manifests and valid signatures for commonly used third party SDKs, and a missing manifest blocks the upload.
- Failure in production: The build is rejected at upload, or worse, an analytics SDK collects an identifier you never declared and you face a compliance problem.
24. Verify tracking consent and the ATT flow
- Why it matters: On iOS, tracking across apps without the App Tracking Transparency prompt is a rejection and a policy breach. In the EU you also need a lawful consent flow before any non essential tracking fires.
- Failure in production: Attribution SDKs fire before consent, which exposes you to regulatory risk and inflates your reported conversions.
25. Confirm transport security and no secrets in the binary
Proxy the traffic. Confirm HTTPS everywhere, certificate validation is not disabled, and no API keys, private keys or credentials are hardcoded. Decompile the release build and search.
- Why it matters: A key in a shipped binary is public. Rotating it means an emergency release plus a store review wait.
- Failure in production: Someone finds your third party API key and burns through your quota or your budget.
26. Test local data storage, session expiry and logout
Check that tokens live in the Keychain or Keystore rather than plain preferences, that logout clears caches and cookies, that session expiry is handled gracefully, and that sensitive screens are protected from screenshots and the app switcher snapshot if required.
- Why it matters: Shared and second hand devices are common. Residual sessions leak data between users.
- Failure in production: A user logs out, the next person opens the app and still sees cached account data.
Category 6: Store compliance and submission readiness (checks 27 to 32)
27. Provide working review credentials and a reviewer note
Create a dedicated review account with realistic data, no OTP requirement, no expiry, and no rate limits. Add a short note describing the happy path in numbered steps. If the app needs hardware, a specific region or a physical device, say so and attach a demo video.
- Why it matters: “Cannot access the app” is one of the fastest and most common rejections, and each round trip costs you days.
- Failure in production: Your launch date slips by a week for a reason that had nothing to do with your code.
28. Test the app as a reviewer would, from a different region
- Why it matters: Reviews happen from other countries. Geofenced content, region locked payments and currency formatting all change behaviour.
- Failure in production: The reviewer sees an empty catalogue because your content is restricted to one market, and the app is rejected as non functional.
29. Complete privacy and data disclosures so they match reality
Apple privacy details on the product page, Google Play Data safety section, plus a live, reachable privacy policy URL. Cross check them line by line against the SDK inventory from check 23.
- Why it matters: Play actively enforces mismatches between declared and observed data collection, and an inaccurate declaration can get an app removed after it is already live.
- Failure in production: An enforcement email arrives weeks after launch and your app is delisted until you fix it.
30. Ship account deletion inside the app
- Why it matters: If users can create an account in the app, both stores require an accessible way to delete that account and its data, not just a support email. This is a hard requirement, not a recommendation.
- Failure in production: Straight rejection, or removal on a later policy sweep. Make the path discoverable within settings, and confirm what is deleted versus retained.
31. Validate purchases, subscriptions and restore flows in sandbox
Test buy, cancel, upgrade, downgrade, restore purchases, expired subscription, refunded purchase, grace period, and interrupted payment. Confirm digital goods use in app purchase where the rules require it, and that pricing, renewal terms and links to terms are displayed before purchase.
- Why it matters: Payment rules and subscription disclosure requirements are among the most strictly enforced sections of both policies.
- Failure in production: Paying users cannot restore entitlements on a new device and you refund revenue you already recognised.
32. Audit build settings, metadata and store listing assets
- Correct bundle ID, version and build number increment, release signing, and no debug entitlements.
- Target SDK and API level that meet the current store requirement. Both platforms raise the minimum every year, so verify the requirement in App Store Connect and Play Console on the day you submit rather than trusting last year’s number.
- Screenshots that match the shipped build on every required device size, no device frames that break the rules, no marketing claims the app cannot deliver.
- Accurate age rating questionnaire, category, contact details, support URL, and trader or verified developer information where required.
- New Play developer accounts may need a closed testing period with a minimum number of active testers before production access, so plan that in weeks ahead, not days.
- Failure in production: An otherwise perfect build sits in “waiting for review” limbo, or gets rejected for a metadata detail that took two minutes to fix.
The one page version you can copy into your tracker
| # | Category | Check | Blocker? |
|---|---|---|---|
| 1 | Functionality | Primary journey end to end, clean and upgrade install | Yes |
| 2 | Functionality | All auth paths including reset and logout | Yes |
| 3 | Functionality | Form validation and duplicate submit protection | Yes |
| 4 | Functionality | Interruption and state restoration | Yes |
| 5 | Functionality | Push, deep links and app links in all app states | No |
| 6 | Functionality | Empty, loading and error states on every screen | Yes |
| 7 | Functionality | No placeholders, debug menus or staging endpoints | Yes |
| 8 | Compatibility | Analytics based device matrix executed | Yes |
| 9 | Compatibility | Safe areas, notches and cutouts | Yes |
| 10 | Compatibility | Rotation, split screen, foldables, resize | No |
| 11 | Compatibility | Accessibility: text scale, contrast, screen reader | No |
| 12 | Compatibility | Upgrade install and data migration | Yes |
| 13 | Network | Full offline launch and navigation | Yes |
| 14 | Network | Throttled and high latency connection | Yes |
| 15 | Network | Network switch mid request, idempotent retries | Yes |
| 16 | Network | Offline queue and sync conflicts | No |
| 17 | Performance | Cold start measured on slowest device | Yes |
| 18 | Performance | Scroll and animation frame rate | No |
| 19 | Performance | 45 minute soak test for memory leaks | Yes |
| 20 | Performance | Battery, background work and heat | No |
| 21 | Performance | Download size and delivery optimisation | No |
| 22 | Security | Just in time permissions, denied path handled | Yes |
| 23 | Security | SDK inventory and privacy manifests | Yes |
| 24 | Security | Tracking consent and ATT prompt | Yes |
| 25 | Security | HTTPS everywhere, no secrets in the binary | Yes |
| 26 | Security | Secure storage, session expiry, clean logout | Yes |
| 27 | Compliance | Working demo account and reviewer notes | Yes |
| 28 | Compliance | Tested from another region or locale | Yes |
| 29 | Compliance | Privacy details and Data safety match reality | Yes |
| 30 | Compliance | In app account deletion available | Yes |
| 31 | Compliance | Purchases, subscriptions and restore in sandbox | Yes |
| 32 | Compliance | Build settings, target SDK, metadata and assets | Yes |
Release sign off: who owns what
- QA lead signs off checks 1 to 21 with evidence attached.
- Lead developer signs off checks 22 to 26 plus build configuration in check 32.
- Product owner or founder signs off checks 27 to 31, because these are business decisions as much as technical ones.
- Nobody submits while a blocker is open. That rule is the whole value of the checklist.
Three mistakes that waste the most time
- Testing the wrong devices. If your matrix does not come from your analytics, you are testing someone else’s user base.
- Automating before stabilising. Automate the regression suite once the journeys are stable. Automating a moving target produces flaky tests that everyone learns to ignore.
- Treating store compliance as paperwork. Account deletion, privacy declarations and payment rules are product features with engineering cost. Scope them at the start of the project, not the week of submission.
FAQ
How long should a pre submission mobile app testing checklist take?
Plan one to two days of focused work for a mid sized app on a frozen release candidate, plus extra time if you need a staged closed testing period on Google Play. If it is taking a week, the build was not ready for QA.
What are the most common reasons apps get rejected?
Crashes on untested devices, reviewers unable to log in, privacy declarations that do not match the SDKs in the build, missing in app account deletion, payments for digital goods routed outside the store, permissions requested without justification, and metadata or screenshots that do not match the app.
Do I still need manual testing if I have automated tests?
Yes. Automation is excellent for regression on stable paths and terrible at judging whether a layout is usable at 200 percent text scale, whether an error message makes sense, or whether an interruption left the app in a confusing state. Use both: automate the repetitive checks, keep human testing for judgement, exploratory work and real device conditions.
How many devices are enough for mobile app testing?
Five well chosen physical devices covering newest OS, oldest supported OS, smallest screen, low end hardware and one large format device will catch most issues. Add cloud device farms to widen coverage on the specific models your analytics show are popular, and always keep your crash reporting device breakdown open when deciding what to add.
Should I test on simulators or real devices?
Simulators and emulators are fine for early functional work and layout iteration. Anything involving performance, battery, camera, biometrics, push notifications, network transitions or thermal behaviour needs real hardware. Every check in the performance and network categories above should be run on physical devices.
What should I do if my app is rejected anyway?
Read the exact guideline number cited, reproduce the reviewer’s steps on the same OS version, fix only what was cited, and reply in the resolution centre with a clear description of the change plus a screen recording. Do not resubmit silently with unrelated changes, since that usually extends the review cycle.
Need a second pair of eyes before you submit?
Running this checklist against your own build is always harder than running it against someone else’s. If you want an independent pre launch audit, a device matrix built from your real analytics, or help fixing the issues this checklist surfaces, the team at abdesigner.net can take your release candidate through all 32 checks and hand you a prioritised report before you press submit.