The Mobile App Pre-Submission Checklist (iOS and Android, 2026)

Submitting a mobile app is not like shipping a web project. You can't hotfix a typo and re-deploy in 30 seconds. Every mistake costs a review cycle, which is 24 to 72 hours of waiting. Apple rejects around 15% of submissions. Google Play's rejection rate is lower but their automated bans are harder to reverse.

This is the checklist to run through before you hit submit. Same checklist works for both platforms. Each item has a specific failure mode attached.

Apple App Store (iOS)

1. Privacy policy URL is set in App Store Connect

Required field. Must be a public HTTPS URL that returns HTML (not a PDF, not a Google Doc requiring login). The URL must be live and reachable by Apple's review team.

Failure mode: instant rejection under Guideline 5.1.1.

2. Privacy policy link is visible inside the app

Not just in the App Store listing. Inside the actual binary. Typically placed in Settings, Help, or an About screen. Reviewers will look for it in under 30 seconds.

Failure mode: rejection under Guideline 5.1.1.

3. Privacy policy matches what your app actually does

If your policy says you collect email but the app also captures photos, location, or contacts, you're rejected. Audit your actual data collection, then write the policy to match. Read Apple rejected your privacy policy for the full breakdown.

Failure mode: rejection under Guideline 5.1.2.

4. App Privacy nutrition labels filled out

App Store Connect has a "Data Types" section. You declare what your app collects. This shows up on your listing. Must match your privacy policy exactly.

Failure mode: mismatch with actual data collection triggers rejection.

5. App Tracking Transparency implemented (if tracking)

If your app tracks users across apps and websites owned by other companies, you must use ATT and prompt the user with a system dialog. Check your SDK configuration carefully. Facebook SDK, TikTok SDK, and many ad networks enable tracking by default.

Failure mode: rejection under Guideline 5.1.2 or 5.1.5.

6. Permission prompts have clear purpose strings

When your app asks for camera, location, microphone, or contacts, iOS shows a system dialog with the text from your Info.plist. Apple checks that the text clearly explains why the app needs the permission.

Wrong: "This app needs location."

Right: "We use your location to show nearby restaurants on the map."

Failure mode: rejection under Guideline 5.1.1(i).

7. Subscription terms visible and clear

If your app has subscriptions, Apple requires specific disclosures on the purchase screen: price, billing period, auto-renewal, how to cancel, link to your terms. All of this has to be visible before the user taps buy.

Failure mode: rejection under Guideline 3.1.2.

8. Account deletion option inside the app

Since June 2022, Apple requires any app that lets users create an account to also let them delete that account from within the app. Not just a contact email. A real button that deletes the account.

Failure mode: rejection under Guideline 5.1.1(v).

9. Sign in with Apple (if offering third-party login)

If your app uses Google, Facebook, or Twitter sign-in, Apple requires you to also offer Sign in with Apple as an option. Missing this triggers rejection.

Failure mode: rejection under Guideline 4.8.

10. Screenshots accurately represent the app

No mockups. No features you haven't shipped. No "coming soon" text. Screenshots must show actual app screens.

Failure mode: rejection under Guideline 2.3.3.

11. Review notes explain anything that could confuse a reviewer

If your app requires a login, provide a test account in the Review Notes field. If your app has location-specific features, explain what to do. If there's a code path that only activates under certain conditions, flag it.

Failure mode: "We were unable to review" rejection, wasted cycle.

12. Metadata is clean

Name, subtitle, keywords, description. No misleading claims ("the best app ever"). No competitor names in keywords ("like Instagram"). No placeholder text.

Failure mode: metadata rejection.

Google Play (Android)

13. Privacy policy URL valid and reachable

Same rule as Apple. Must be HTTPS, HTML (no PDFs), no login required, live and reachable.

Failure mode: "Privacy Policy link invalid or missing" rejection.

14. Data Safety form completed

Google's equivalent of Apple's privacy nutrition labels. Declare what data your app collects, what it's used for, whether it's shared, and whether it's encrypted in transit. Must match your actual behavior.

Failure mode: rejection or forced update delay.

15. Permissions requested are justified

Google Play Protect flags apps that request permissions they don't need. If your app asks for SMS or call log access, you must justify it and declare it in the Permissions Declaration form.

Failure mode: permission rejection, banned from Play Store.

16. Target SDK version current

Google requires apps to target a recent API level. As of 2026, that's API 34 or newer. Older SDK targets are blocked from submission.

Failure mode: can't upload.

17. App content rating set

Complete the content rating questionnaire honestly. Marking "none" on everything when your app has user-generated content triggers manual review and potential rejection.

Failure mode: rejection or forced age rating change.

18. Ads disclosure

If your app contains ads, you must declare this in the Play Console. Failing to do so is a policy violation.

Failure mode: policy violation, app removed from store.

19. COPPA compliance (if app is for kids)

If your app targets users under 13, Google has strict requirements for the Designed for Families program. Most indie apps don't need this. If you think you might, read the documentation carefully before submitting.

Failure mode: rejection, ban from Families program.

Both platforms

20. App icon is not the framework default

The default React Native, Flutter, Expo, or Capacitor icon. Apple and Google both catch this and reject.

21. Test on real devices, not just simulators

Apple and Google reviewers run your app on real hardware. Simulator-only testing misses performance issues, camera problems, push notification failures, and permission prompts that look different in production.

22. Crash-free baseline

If your app crashes on launch for the reviewer, you're rejected. Test the first launch experience from a fresh install, with no data, on a real device.

23. Offline state handled

Reviewers sometimes test in airplane mode. If your app white-screens or crashes without internet, that's a rejection.

24. Paywall visible to reviewers

If your app has a paywall, reviewers need to be able to see it without making a purchase. Use a sandbox account or provide review notes explaining how to access gated content.

Other required steps before launch

25. Deep links and universal links configured

If you want your app to open from web links, set up universal links (iOS) and app links (Android) before launch. Retrofitting is painful.

26. Push notification certificates and keys in place

If you plan to send push notifications, set up APNs (iOS) and FCM (Android) before launch. Test sending a real push to a test device.

27. App Store Connect / Play Console billing set up

You need a paid Apple Developer account ($99/year) and Google Play Developer account ($25 one-time). Don't wait until launch week to set these up. Google Play verification can take 24-48 hours.

28. Review notes drafted

Write a clear "how to review this app" note for both platforms. Include test credentials, feature walkthroughs, and anything unusual. This saves review cycles.

29. Response plan for rejection

You will probably get rejected on your first submission. Have a plan. Read the rejection email carefully. Fix the specific thing. Resubmit with a note explaining what you changed.

How to never get rejected

The best review cycle is the one you don't need. Run through this checklist before every submission, not just the first one. Apple's rules change each year and they enforce them retroactively on updates. A submission that passed in 2024 can get rejected in 2026 under the same guideline.

CalmLaunch's mobile app project type checks most of these automatically (the ones that can be scanned from your public assets and metadata) and flags the rest as manual items. See the eight launch categories for the full structure.

Common questions

What's the single most common rejection reason in 2026?

Privacy policy mismatch. The policy doesn't accurately describe what the app actually collects, shares, or tracks. Fixing this one thing cuts rejection rates in half for most indie apps.

How long does re-review take after a rejection?

Apple: 24-48 hours typically, sometimes same-day if you include a clear note about what you fixed. Google: similar, but initial submissions can take longer due to Play Protect scans.

Can I use a privacy policy generator for a mobile app?

As a starting point, yes. But the generated policy has to be customized to match your actual data collection. Generic policies that don't name third-party SDKs or describe actual permissions will trigger rejection.

Do I need a separate app for iOS and Android?

No. A single React Native, Flutter, or Expo codebase can ship to both platforms. But each platform has its own submission process, metadata, and review. Budget time for both separately.