App Store Review Pre-Flight: A 9-Minute Checklist Before You Hit Submit

Nine checks. One per minute. Run before you click Submit in App Store Connect or the Google Play Console. The nine checks below catch roughly 80 percent of the rejections that come back in real submission cycles — not every rejection, but the ones that matter most and happen most often.

Use this as your App Store review rejection checker right before you submit. Each check maps to a specific Apple guideline or Google Play policy; each has a clear fail condition; each fits in one minute on a submission that is already in reasonable shape. If a check fails, fix the issue before submitting — the 9 minutes you invest saves the 24–72 hours you would lose in a rejection cycle.

Pair this with the full 80+ rejection reasons index for depth, the 60+ item ASO pre-submission checklist for the broader audit, and the ASO playbook for indie developers for the release-cycle strategy.

The 9 checks at a glance

Nine checks, mapped to the guideline or policy each one catches.

Check 1 — App launches cleanly on a real device (1 min)

Install the latest build on a real iPhone or Android device. Launch it cold — not from Xcode, not from Android Studio — and tap through the first core flow. If it crashes, Apple will reject under guideline 2.1. Google will flag it in the pre-launch report.

Test on the lowest OS version you support, not just your daily driver. A crash on iOS 17 that doesn’t reproduce on iOS 18 is a rejection in 24 hours. App Store Review tests on a rotating mix of devices and versions; yours needs to survive the least favourable combination.

This is the single most common rejection reason on Apple — see the full rejection reasons index under the Binary section.

Check 2 — Demo account works + credentials in reviewer notes (1 min)

If your app requires sign-in, open the App Store Connect submission form and verify three things:

1. The demo account username exists in your production database.
2. The password field is filled in correctly.
3. Any 2FA codes, test payment details, or special URLs are in the App Review Notes field.

Test the demo account one more time in Airplane Mode to rule out network dependencies the reviewer won’t reproduce. A non-working demo account is the fastest-resolvable rejection reason and also the one most teams don’t catch before submission.

Check 3 — Support and Privacy Policy URLs return 200 (30 sec)

Open both URLs in a fresh browser tab. Any 404, 5xx, or parked-domain response rejects under Apple guideline 1.5 and Google’s User Data policy. Apple tests these URLs automatically during review; checking them yourself costs you 30 seconds.

Confirm the Privacy Policy URL actually points at a privacy policy — not the homepage, not the Terms of Service, not a login-gated page. Apple rejects policies that are locked behind authentication.

Check 4 — Metadata matches the shipped app (1.5 min)

Compare what App Store Connect shows against what the app ships:

• Title and subtitledescribe the current app, not a feature you removed or haven’t shipped. Verify character limits with the keyword character counter and the subtitle helper.
• Description matches the current feature set. Outdated feature lists are a common rejection under 2.3.7.
• Screenshotsmatch the shipped UI. Replace any that show an older design or a feature you’ve since removed.
• No placeholder text— search the description for “Lorem Ipsum,” “TODO,” or “Your description here.”

Check 5 — Privacy Manifest + App Privacy label match (1.5 min)

iOS only. Enforced since May 2024.

1. Confirm PrivacyInfo.xcprivacy is in the binary and covers every required-reason API your app or any bundled SDK uses.
2. Every third-party SDK must ship its own manifest. Update SDKs that don’t, or vendor a manifest into the framework bundle.
3. Open App Store Connect → App Privacy. Confirm the labelled data categories match what your code actually collects.

A Privacy Manifest missing for a required-reason API is a submission-blocking rejection under guideline 5.1.1. Cross-check against the Binary section of the App Store rejection reasons index for the exact phrasing.

Check 6 — Keywords field passes the safety net (1 min)

Run the following safety net against your iOS keywords field:

• 100 characters or fewer — check with the counter.
• No spaces after commas.
• No competitor names (rejects under 5.2 — see the rejection reasons index).
• No Apple-owned terms (iphone, ipad, ios, app store).
• No duplicates of title or subtitle words — wastes characters.
• No category names (you already rank in your category).

Full rules in the Apple App Store keywords field deep-dive.

Check 7 — Account deletion flow is in-app (30 sec)

If your app lets users create an account, it must let them delete it inside the app — not by emailing support, not via a web form only. Enforced since June 2022 under Apple guideline 5.1.1(v).

Tap through Settings → Account → Delete Account. Confirm the flow actually removes the account from your production database, not just flags it as inactive. Reviewers sometimes verify by creating a test account and deleting it.

Check 8 — Payments route through StoreKit / Play Billing (1 min)

For digital-content purchases:

• iOS must use StoreKit (unless you have the US Reader entitlement or an EU DMA carve-out — rare for indie apps).
• Android must use Play Billing.

Physical goods, real-world services, and enterprise use cases are exempt from IAP on both stores. A single external purchase link for digital content rejects under Apple 3.1.1 or Google’s Payments policy.

Check 9 — Binary-level checks pass (1 min)

The checks that are expensive to verify manually but easy to automate:

• iOS target SDK. New apps must build with iOS 18 SDK or later.
• Android target API. New apps must target API 35 (Android 15) as of August 2025.
• 16 KB page-size alignment. Android apps targeting API 35+ must support 16 KB pages as of November 2025.
• Debuggable flag off in the Android release AAB.
• Encryption export compliance declared via ITSAppUsesNonExemptEncryption in Info.plist.
• No private API usage strings in the iOS binary.

Push My App’s Pre-Flight Scanner runs every check in this section automatically against your .ipa, .apk, or .aab — pointing at the exact file or manifest key that would trip a rejection. See the IPA vs APK vs AAB deep-dive for the fuller context, and the App Store vs Google Play listing requirements for the cross-store rule comparison.

What this checklist does not catch

Three categories of rejection this 9-minute pass does not cover:

1. Review-time judgement calls.“Is this app fundamentally duplicative of an existing template?” (Apple 4.3) and “Does this content deserve the age rating claimed?” (Apple 1.1). These require Apple to form an opinion; no pre-flight catches them.
2. Post-launch re-scans on Google Play. Play Protect continues to scan apps after launch and can suspend an already-live app for a policy violation surfaced weeks later. You can reduce your exposure with the full ASO pre-submission checklist.
3. Content-rating mismatches per market. A content rating that passes the US App Store can fail the German or Japanese storefront under local content laws. Verify per-market if you ship to sensitive regions.

Frequently asked questions