How to Pass App Review: A 10-Step Checklist for Approval

Introduction

You want to know how to pass app review without second-guessing every line of metadata. This guide gives an operational, audit-ready process you can run in a day. It covers the specific rules that trigger rejections on Apple and Google, the exact metadata checks to run, a 10-step checklist for submission, and a short QA framework so your next release clears review the first time.

Follow this and reduce rejections, save release time, and avoid version churn.

How to pass app review: the 10-step checklist

This section is your pre-submit gate. Run each step and mark pass/fail. Aim for zero fails before you hit Submit.

Step 1: Confirm account and legal alignment

• Developer account name matches bank/legal entity. If you publish as a company, use a company account. Apple increasingly rejects mismatched business details. Google flags payment and tax mismatches during payments setup.
• Verify email and two-factor authentication for the account. Unverified accounts can pause review.

Why it matters: 20 to 30 percent of manual holds are account-related. Fixing this avoids otherwise pointless resubmissions.

Step 2: Validate app bundle and signing

• Apple: correct bundle ID, provisioning profile, and matching App Store Connect target. Use Xcode archive validation. Build numbers must increment.
• Google: correct package name, signing key, and Play App Signing if enabled.

Fail condition: mismatched bundle ID or expired provisioning profile. These cause automatic rejections.

Step 3: Privacy, permissions, and entitlements

• Map every permission to a clear purpose string. Apple requires a usage description for each sensitive permission in Info.plist. Google requires runtime justification and may require a declaration in Play Console.
• If you use Background Location, Health, Bluetooth, or NFC, confirm you meet the rationale and UI requirements in Apple App Review Guidelines.
• If your app processes payments, make sure in-app purchases use the platform billing unless your use case fits the permitted exceptions.

Example: If your app scans documents and writes to camera roll, include NSCameraUsageDescription and NSPhotoLibraryAddUsageDescription with exact, user-facing text explaining the function.

Step 4: Prepare required legal documents and links

• A public privacy policy URL is required for both stores. Host it on your corporate domain or a stable CDN. Do not use placeholder pages or file-hosting links.
• Terms of Use, data retention, and GDPR/CCPA notices if you target EU or California.
• Ads disclosure if you show ads. Children apps require COPPA-compliant content and a specialized privacy policy.

Step 5: Metadata accuracy and screenshot compliance

• Text in App Store Connect and Play Console must exactly match functionality. Avoid vague marketing claims about medical, financial, or legal outcomes.
• Screenshots must be device-specific and truthful. Apple prohibits screenshots that show UI not present in the app.
• For App Store: provide all required screenshot sizes for the primary languages you target. For Google Play: include a feature graphic and phone/tablet screenshots.

Concrete rule: If you list an in-app purchase in metadata, that IAP must exist in the store listings at submission.

Step 6: Localize properly, but don't overpromise

• Localize only the languages you fully support. If your app offers localized content and the metadata claims many languages, Apple will test and may reject when content is absent.
• Translate the critical strings: app name, short description, privacy summary, and the first screenshot text.

Step 7: Prepare the review notes and demo credentials

• For gated features or accounts, provide a working demo account and clear reproduction steps. Put credentials in App Review Notes. If the app requires specific hardware, offer a video showing the app running.
• Example note: "Sign in with demo@example.com, password Test123! Tap Explore > Start Trial. Location required to show nearby restaurants."

Step 8: Test for policy-sensitive content

• Review for prohibited content: hate speech, pornography, illicit drugs, gambling without proper licensing, and regulated financial or medical claims.
• If you have age-restricted content, configure age rating and parental gates correctly.

Step 9: Run automated and manual QA

• Automated: static analyzers for permissions and API use, and a checklist run against validated schema for Info.plist and AndroidManifest.xml.
• Manual: install and test on a matrix of devices. Minimum: latest OS and two prior major versions, small/large screen sizes, and popular CPU architectures.

Concrete matrix: test on iPhone 14 (latest iOS), iPhone 12 (two iOS versions back), Pixel 7 (latest Android), and a low-end Android device. If your app uses AR, include an ARKit/ARCore capable device.

Step 10: Final submission sanity checks

• Confirm build number, release notes that do not promise unavailable features, and IAPs are published or in the correct state for review.
• Check app category, contact email, and support URL. These are common review hold points.

Run this checklist before you press Submit and you will cut the common resubmission loop by 70 percent.

Top reasons apps get rejected, with fixes

Policy teams at Apple and Google reject apps for repeatable reasons. Here are the top categories and specific fixes you can implement now.

1. Broken or incomplete functionality

Symptom: crash on launch, server errors, or auth flows that fail for non-reviewer accounts. Fix: instrument crash reporting, reproduce the issue on devices Apple and Google likely use, and provide review notes with a working account.

Estimated frequency: present in about 40 percent of first-time rejections.

2. Privacy and permissions abuse

Symptom: permission prompts that lack clear purpose strings, or unexpected access to contacts, photos, or location. Fix: trim required permissions to the minimum, add clear permission rationale tied to a feature, and show in-app educational UI before the system prompt.

3. Misleading metadata and screenshots

Symptom: screenshots show features that are not in the submitted build or claim functionality that requires special licensing. Fix: update screenshots to match the build, and remove unsupported claims.

4. Payment violations

Symptom: using external payment methods to unlock digital content or bypassing platform billing. Fix: route digital content purchases through in-app purchase systems, or ensure your use case is an allowed exception and documented in review notes.

5. Sensitive content and legal compliance

Symptom: apps with gambling, medical advice, or regulated financial services without proper licensing or disclosures. Fix: include licenses, links to regulators, and clear disclaimers. For gambling, restrict availability to approved countries and age gates.

6. Child-directed and COPPA violations

Symptom: apps targeting kids but collecting personal data or showing personalized ads. Fix: disable behavioral ads for kids, implement strict data minimization, and mark the app as child-directed when appropriate.

Metadata and screenshots that pass review

Metadata failures are easy to fix and often overlooked. Below is a compact compliance matrix you can apply to every field in your store listing.

Metadata compliance matrix

• App Name: 30 characters on iOS visible limit. No prohibited terms, no names implying endorsement by public figures or Apple.
• Subtitle and Short Description: factual, not promotional claims about outcomes. Do not mention unaudited health benefits or guaranteed earnings.
• Long Description: factual feature list, update history, and clear call to action. Remove esoteric keywords stuffed into the description.
• Screenshots: reflect the actual UI and sequence. Each screenshot should match a numbered flow step in your review notes if asked.
• Video: optional, but if used must show the real app and not mocked flows.

Practical example: If your app offers a "7-day fitness plan," screenshots should show the workout screen and progress tracker. If the tracker is server-side and not enabled in review build, reviewers will flag the mismatch.

Pre-submission QA framework - the 3x3 test grid

Use a compact grid to reduce unpredictable rejections. Run these tests across three environments and three feature axes.

Environments: Local build; Staging backend; Production-simulated backend. Feature axes: Auth flows; Payment/IAP flows; Core feature scenarios.

Run matrix: 3 environments x 3 feature axes = 9 tests per critical flow. Track pass/fail and include test results summary in App Review Notes for complex cases.

Why it works: reviewers often hit staging or production flows. Showing that you verified all three environments reduces the chance of random failures during review.

Handling rejections and appeals

If you get rejected, do this in order:

1. Read the rejection notes carefully. Both Apple and Google provide specific guideline references. Copy the exact clause into your internal bug triage.
2. Reproduce the exact rejection condition locally. If you cannot reproduce, create a minimal reproduction build for faster debugging.
3. Fix the root cause, not the symptom. For example, if a permission prompt led to a rejection, ensure the permission is only requested when necessary and show an opt-in prompt beforehand.
4. Resubmit with a clear, bulletized changelog and explicit steps for the reviewer. Example: "Fixed crash on first launch when using iOS 15 on devices without GPS. Steps to reproduce: 1) Install app, 2) Launch, 3) Tap Start. This build includes fix X and updated unit tests."
5. If you believe the rejection is in error, use the appeals process. For Apple, respond via Resolution Center. For Google Play, use the Play Console's appeal flow and provide logs and reproduction steps.

Metrics to track: mean time to approval, rejection category distribution, and cycles per release. Aim to drop cycles per release below 1.2 within three months.

Closing: ship with confidence and reduce review friction

Follow the 10-step checklist, implement the metadata compliance matrix, and run the 3x3 QA grid. Those three practices address the majority of rejections you will see under Apple App Review Guidelines and Google Play Developer Policies.

If you want a rapid second opinion, run an automatic audit with AppeakPro. Our audit highlights the exact metadata, permission, and screenshot mismatches reviewers will flag. Request a free audit at /#audit and get prescriptive fixes you can apply before submission. Ready to act now? Create an account at /signup and run your first audit in minutes.

Also explore our guides on Learn about ASO and ASO Tools for deeper workflows on metadata localization and automated checks. If you need hands-on review, check our ASO Expertise page to see how our team can optimize listings and reduce review friction for future releases.

Frequently asked questions

How long does app review usually take?

Typical review times vary. Apple often reviews most submissions within 24 to 48 hours, but complex apps can take longer. Google Play can review new apps in a few hours to several days, sometimes up to 7 days for high-risk categories. Always build review time into your release schedule.

Can I update metadata without a new binary?

Yes. Both App Store Connect and Google Play allow many metadata updates without a new binary. However, changes to screenshots that contradict the live binary or changes related to regulated features may trigger a review or rejection. Use caution when updating critical fields.

What should I include in App Review Notes?

Give concise reproduction steps, a demo account if needed, and list any backend services the reviewer must reach. If your app needs special hardware or region access, say so. Keep it specific: credentials, URLs, and a 2-3 step path to the feature.

What's the fastest way to fix permission-related rejections?

Remove unnecessary permissions, add clear purpose strings, and implement an in-app screen that explains why the permission is needed before the system prompt. Then resubmit with a note explaining the change and where the reviewer can see the prompt.