Mobile app pre-launch checklist for Android and iOS

Launching a mobile app means passing two store reviews, surviving real devices and keeping users on day one. This checklist walks through everything to verify before you submit, from builds and beta testers to store policies, in-app purchases, crashes and the listing itself, with links to detailed guides for each step and a full pre-launch task your AI beta tester can run.

Who it’s for

  • Founders and product managers submitting a first app to the App Store or Google Play
  • Developers preparing a major release of an existing app
  • Agencies handing an app to a client for launch
  • Teams who had an app rejected and want to avoid a second round

Updated 2026-10-25.

How to use this checklist

Work through the sections in order. The first ones are about getting a testable build in front of people; the middle ones are about the store policies that cause most rejections; the last ones are about launch day. Each section links to a detailed guide.

1. Builds and testing tracks

  • Release builds for both platforms from the same commit, with version and build numbers that follow the store rules (iOS build numbers must increase; Android versionCode must increase).
  • Builds uploaded to TestFlight and a Google Play closed testing track. New personal Play developer accounts need a closed test that meets Google's minimum tester and duration requirements before they can apply for production access, so start early and check the current policy text.
  • Clean-install and upgrade-from-the-previous-version paths both work, keeping data and sessions.
  • Debug settings, test endpoints, logging and the dev menu are off in release.

2. Beta testers and feedback

3. Devices and coverage

4. Store policy requirements

These are the items that most often send an app back for another review round. Verify each against the current policy text, because both stores update their rules.

  • Account deletion: apps that let users create an account must let them delete it, in the app on iOS, and on Android with a path that also works from outside the app. Details in in-app account deletion requirements.
  • Sign in with Apple: required on iOS in most cases when you offer third-party or social login; see when Sign in with Apple is required.
  • Privacy disclosures: App Store privacy labels and the Google Play Data safety form match what the app and its SDKs actually collect. A mismatch is a common Play rejection.
  • Permissions: every permission has a purpose string (iOS) or a declared, justified use (Android), is requested in context, and the app still works when denied. Tracking prompts on iOS appear before any tracking.
  • Content and age rating: the questionnaire answers match the app, including user-generated content moderation and reporting if you have it.
  • Metadata: screenshots show the real app, the description does not promise features that are missing, and the privacy policy and support URLs load.
  • Full lists of common failures: App Store rejection reasons and Google Play rejection reasons.

5. In-app purchases and subscriptions

  • Digital goods go through StoreKit and Play Billing, not an outside payment flow.
  • Every product is configured, approved and attached to the build; prices and trial terms shown in the app match the store.
  • Purchase, cancel mid-flow, restore purchases on a fresh install, upgrade and downgrade between tiers, and expiry handling all tested with sandbox or license tester accounts. Guide: in-app purchase testing.

6. Stability

  • No crash on a clean install launch, on first login, or on returning from the background.
  • Rotation, permission denial, low memory, slow and offline networks, incoming calls and returning from the camera or a share sheet.
  • Crash reporting (and ANR tracking on Android) wired up in the release build and verified with a test crash. Guide: mobile app crash testing.
  • A regression pass of the core flows on the final build, not the one before it.

7. Store listing

  • App name, subtitle or short description, and keywords with no competitor names or unsupported claims.
  • Screenshots for every required device size, made from the current build.
  • Privacy policy URL, support URL and marketing URL all live and matching the app.
  • Review notes with the demo login, how to reach gated features, and anything a reviewer might misread.

8. Launch day and the first week

  • Staged rollout on Google Play and phased release on the App Store, so a bad build reaches a fraction of users first.
  • Analytics and crash dashboards open, with someone watching for the first 48 hours.
  • A support channel listed in the app and the store, with a reply template ready.
  • A rollback plan: the previous build ready to resubmit, and a way to disable a broken feature remotely if you have feature flags.

Example pre-launch finding

Title: Account deletion absent; Settings only offers "Log out"
Environment: iPhone 14, iOS 18.1, build 1.0.0 (24) and Pixel 7, Android 14,
build 1.0.0 (24)
Severity: Critical (blocks store approval; both stores require account
deletion for apps with account creation)

Steps to reproduce:
1. Create an account with email and password.
2. Open Settings > Account.

Expected: An option to delete the account, with a confirmation and a clear
statement of what is removed.
Actual: Only "Log out" is available. Support page mentions emailing to
delete, which does not satisfy the in-app requirement on iOS.

Evidence: screenshots of Settings > Account on both platforms.

Common pre-launch misses

  1. Account deletion missing or hidden behind an email request.
  2. Social login without Sign in with Apple.
  3. Data safety or privacy labels that do not match the SDKs in the build.
  4. Demo account missing or expired when the reviewer tries it.
  5. Crash on first launch of a clean install because of a missing production config.

Manual pre-launch checks vs an AI beta tester

Humans own the judgment calls: whether the listing is persuasive, whether the app is worth paying for, how it behaves on their networks and in their routines.

An AI beta tester like betatest.ing runs the systematic part of this list on your uploaded builds, on iPhones and on Android emulators or devices. Its Store readiness tests cover the App Store review checklist, the Google Play policy checklist, Sign in with Apple and account deletion, in-app purchases in sandbox, permission and tracking prompts, and the store listing. It walks every screen and flow, files bug reports with steps to reproduce, severity, annotated screenshots and recordings, and ends with a scored report. Run it on the release candidate, fix what it finds, and send the same build to your human testers and then to review. It never makes real purchases, and test logins are encrypted and never shown to the AI.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Run a full pre-launch pass on my mobile app using the uploaded builds (the .ipa on an iPhone and the .apk/.aab on Android). It is [WHAT THE APP DOES AND WHO IT IS FOR]. The app offers [ACCOUNT, LOGIN AND PURCHASE OPTIONS, E.G. EMAIL AND GOOGLE LOGIN, A MONTHLY SUBSCRIPTION]. On each platform: install from clean, go through first launch, onboarding and every permission and tracking prompt (deny at least one), sign up or sign in with the saved test login, and use every main screen and flow. Store readiness: check that an account can be deleted in the app, that Sign in with Apple is offered on iOS if other third-party logins are, that purchases use the store's billing and show price and terms (use the sandbox or test account only, never a real purchase), that restore purchases works, and that privacy policy and support links open. Stability: background and return, rotate where supported, and look for crashes or frozen screens. Note placeholder text, broken images and anything that does not match the store listing description I provide: [SHORT STORE LISTING DESCRIPTION]. Log each issue as a finding with the platform, steps to reproduce, severity and an annotated screenshot, record any flow that breaks, and end with a report that scores store readiness, stability, onboarding and layout per platform with the top fixes before submission.

Fill in your details

Here, or later in the chat with your tester.

  • [WHAT THE APP DOES AND WHO IT IS FOR] One sentence about the app and its users
  • [ACCOUNT, LOGIN AND PURCHASE OPTIONS, E.G. EMAIL AND GOOGLE LOGIN, A MONTHLY SUBSCRIPTION] How users sign in and what they can buy, so the tester knows which policy checks apply
  • [SHORT STORE LISTING DESCRIPTION] Paste the first lines of your store description so the tester can compare it with the app

What the AI beta tester checks

  • Clean install and first launch on both platforms
  • Permission and tracking prompts, including deny
  • In-app account deletion
  • Sign in with Apple alongside other third-party logins
  • In-app purchases, price display and restore in sandbox
  • Privacy policy and support links
  • Every main flow with the test account
  • Backgrounding, rotation and crash behavior
  • Placeholder content and mismatch with the store listing
  • Layout on small and large screens

What you get

  • Findings tagged by platform with steps to reproduce and severity
  • Annotated screenshots and recordings of each issue
  • A store readiness list of blockers to fix before submission
  • A scored report per platform with the top fixes

How to run it with betatest.ing

  1. Add your app as a project in betatest.ing and upload the release .ipa and .apk or .aab.
  2. Add a test login and sandbox purchase details if the app has accounts or purchases.
  3. Send the pre-launch task, or pick the Store readiness tests one by one.
  4. Fix the blockers, upload the release candidate and re-run before submitting to review.

Tips

  • Do the store policy section first; those items cost a full review cycle each.
  • Keep a demo account alive for reviewers and refresh it before every submission.
  • Use staged and phased rollouts so the first bad crash reaches a fraction of users.
  • Re-test the approved store build on launch day; it is not always the build you tested.

Mobile app pre-launch checklist: FAQ

What should I check before launching a mobile app?

Release builds on both platforms, a beta with testers beyond your team, store policy items such as account deletion, Sign in with Apple and privacy disclosures, in-app purchases in sandbox, a crash pass, the store listing, and a launch-day plan with staged rollout and monitoring. This page covers each section with links to detailed guides.

How long does it take to get through app store review?

It varies by store, app and time of year, and both companies publish guidance. Plan for at least one rejection round on a first submission and leave buffer before any announced launch date; check the stores' current guidance for typical times.

What causes most app store rejections?

On the App Store: crashes and bugs, missing account deletion, missing Sign in with Apple, purchases outside StoreKit, and metadata or privacy label problems. On Google Play: Data safety mismatches, missing account deletion paths, unjustified sensitive permissions, target API level and billing issues. See the rejection guides linked above.

Do I need both Android and iOS beta tests?

Yes, if you ship to both. Even with a shared codebase, permissions, navigation, store policies and purchase flows differ, and each store reviews its own build.

Can an AI beta tester run this checklist?

It runs the systematic parts on your uploaded builds: Store readiness tests for account deletion, Sign in with Apple, IAP in sandbox, permissions and tracking prompts and the store listing, plus full flow, layout and stability passes, with bug reports, screenshots and recordings. Judgment calls, real-world conditions and the final review stay with you and the stores.

What is a staged or phased rollout?

Google Play's staged rollout and the App Store's phased release deliver a new version to a percentage of users first, so you can halt it if crash rates rise. Use them for every launch and major update.

Should I submit the same build I beta tested?

Yes. Any change after the beta means a new build and a shorter regression pass of the core flows. Submitting an untested build is the most common way a 'small fix' becomes a rejection.

How do I prepare the demo account for reviewers?

Create a dedicated account with realistic data that shows every gated feature, make sure it does not expire or require a code sent to your phone, put the credentials in the review notes on both stores, and check it still works right before you submit.

Related beta testing guides

  • Mobile app beta testing — Mobile apps reach testers through store testing tracks, run on hardware you do not control, and get interrupted constantly. This guide covers how to distribute a mobile beta, what to test that is specific to phones, and how an AI beta tester fits alongside your human testers.
  • Android app beta testing — Android beta testing means getting a test build onto many different phones and finding what breaks before the public release. Here is how Google Play testing tracks work, what to test that is specific to Android, and a task your AI beta tester can run from your uploaded build or Play link.
  • iOS app beta testing — TestFlight is how almost every iOS app gets into beta testers' hands before the App Store. This guide explains how TestFlight testing works, what to check on iPhone that differs from Android, and how to run an AI beta test on a real iPhone from an uploaded .ipa build.
  • App Store rejection reasons — Most App Store rejections are not about taste. They cite a small set of guidelines: the app crashed, a login had no demo account, a purchase bypassed in-app purchase, a social login lacked Sign in with Apple, or there was no way to delete an account. This guide lists the common rejection reasons by guideline number, what reviewers actually check, and a review-readiness task your AI beta tester can run on the build before you press Submit.
  • Google Play rejection reasons — Google Play rejections tend to be about declarations more than design: a Data safety form that does not match what the app collects, a missing account deletion link, an undeclared sensitive permission or an outdated target API level. This guide lists the common rejection and removal reasons, what to fix for each, and a Play policy check your AI beta tester can run on the build before you submit it for review.
  • Free tool: Beta testing checklist generator — An interactive checklist for websites, SaaS, mobile apps, stores and extensions. Progress saved, Markdown export.

More in guides