App Store Review Guidelines: What Causes Rejection and How to Pass

Introduction

App store review guidelines decide whether your app reaches users or returns with a rejection. Know them, and you reduce wasted development cycles, review delays, and revenue loss. This guide breaks down the rules from Apple and Google into actionable checks you can run before you submit. It focuses on the exact metadata items and technical checks that cause the most failures, plus concrete remediation steps.

Why this matters

A single metadata or compliance mistake can add days to your timeline. You want predictable review outcomes. Treat the review process like QA. Build a checklist. Measure against it. This reduces rejection risk and speeds approvals.

Quick overview: Apple vs Google at a glance

Apple and Google share goals. Both protect users and their platforms. They differ in emphasis and process.

• Apple enforces UI, privacy, and content policies strictly. You must be explicit about permissions, data use, and subscription behavior.
• Google enforces content, ad, and permission transparency plus Play-specific policies like target audience and advertising ID usage.

Key operational differences

• Review time: Apple averages a few days, but complex apps can take longer. Google can be faster, but Play Protect scans for policy violations and may flag apps later.
• Rejection handling: Apple returns a single rejection report with notes. Google may remove apps from the store or issue a policy message. Both allow appeal and resubmission, but Apple gives more structured reviewer notes.

Top 12 reasons apps get rejected, with examples and fixes

Use this prioritized list to triage problems before submission. I list cause, quick example, and exact fix.

1. Privacy and data collection noncompliance

• Example: App requests contacts permission but does not explain why in the privacy string or manifest.
• Fix: Provide a clear purpose string for every permission, update your privacy policy, document data flows, and supply test accounts if data is gated.

2. Misleading metadata or screenshots

• Example: Screenshots show features that require login, but your listing claims the feature is available without signup.
• Fix: Keep screenshots accurate to the first-run UX. If a feature is behind login, show the login screen and label screenshots accordingly.

3. Broken or misleading in-app purchase flow

• Example: Purchase fails, or subscription terms are not transparent in the app and metadata.
• Fix: Ensure IAP products exist in the store console, implement fail-safe client logic, and show clear pricing and terms before checkout.

4. Lack of required documentation for restricted content

• Example: Health or financial apps that claim to provide medical or financial advice without disclosure or licensing proof.
• Fix: Add an in-app explanation, link to credential verification, and upload supporting documentation in the review notes.

5. Background execution or improper use of system APIs

• Example: Using background location when not needed, or starting VoIP services improperly.
• Fix: Remove or limit background APIs, justify usage in submission notes, and comply with platform-specific API contracts.

6. Payment policy violations

• Example: Selling digital content outside the store billing system.
• Fix: Use platform billing for digital goods, and use external payment only for allowed services like physical goods.

7. Ads and ad SDK misuse

• Example: Ads display on sensitive screens like login or payment confirmation, or ad SDK collects excessive data.
• Fix: Remove ads from sensitive flows, update SDK to latest compliant version, and declare ad networks in metadata where required.

8. Privacy policy missing or not accessible

• Example: No privacy policy URL or the policy is not reachable from the app store listing and app.
• Fix: Host a public privacy policy, add the link to store listing and inside the app, and match the policy language to actual data practices.

9. Unsafe or inappropriate content for declared audience

• Example: App targets children but includes ads or user-generated content without moderation.
• Fix: Implement age gating, remove age-inappropriate content, and use restricted ad networks or COPPA-compliant flows.

10. Incomplete review instructions or test accounts

• Example: Reviewer cannot access core functionality because your demo account is expired or credentials are missing.
• Fix: Provide a fresh test account in the review notes, include device and OS constraints, and outline required steps to reproduce.

11. Crashes and stability failures

• Example: App crashes on first run on common device models.
• Fix: Run crash analytics, fix top crash stack traces, and provide a build optimized for review with logging disabled.

12. Intellectual property or trademark violations

• Example: Using copyrighted content without license or using competitor brand names in metadata.
• Fix: Remove infringing content, secure licenses, and use neutral language in metadata.

Metadata that passes the first time: exact checklist

Treat metadata like a legal document. Reviewers look for clarity and accuracy.

Required metadata checklist - run this before upload

• App name and subtitle: No claims that imply false functionality. No trademark misuse.
• Description: Describe core functionality only. Avoid keyword stuffing. Use plain language.
• Screenshots and preview: Match the experience on first launch and show the onboarding if core features require login.
• Privacy policy URL: Public, reachable, and consistent with actual data practices.
• Permissions: Each permission has a clear purpose string inside the app and is justified in submission notes if not obvious.
• Support URL and contact: Valid link and active email.
• IAP products: Created and in the same store account as the app. Prices match in-app text.
• Age rating and content categories: Correctly set for target audience.
• Demo credentials and instructions: Active credentials and step-by-step reproduction in the review notes.

Practical rules for screenshots and descriptions

• Show the onboarding flow in at least one screenshot if login gates key features.
• If a feature requires a subscription, show the subscription modal or a screen where pricing appears.
• Use one sentence per feature in the description and start with the main benefit.

Submission workflow that reduces rejections by design

Adopt a preflight workflow. This reduces human error and repeated resubmissions.

1. Release staging build to a private test list that mirrors the review environment.
2. Run the metadata checklist and scoring: 0 to 100, where anything below 85 needs remediation.
3. Capture a 30-second onboarding video and screenshots from baseline devices. Attach these to the submission notes.
4. Include a review readme: short notes explaining any nonstandard behavior, required credentials, and where reviewers can reproduce features.
5. Use feature flags to turn off complex integrations that might fail under review, like social sign-in or experimental payment flows.

Example scoring table you can use

• Permissions documented: 20 points
• Privacy policy reachable: 15 points
• IAPs configured: 15 points
• Screenshots accurate: 10 points
• Demo account provided: 10 points
• No crashes on first run: 20 points
• No IP or trademark issues: 10 points

Pass threshold: 85 points. This simple table forces you to check the high-risk items first.

Real examples: writeable copy that passes

Problem: Your subtitle says free but requires sign-up and paid upgrade immediately. That triggers misleading metadata.

Compliant alternative: "Free to download, optional subscription for premium features". This sets clear expectations.

Problem: Permission prompt just says Allow access. Reviewers flag this.

Compliant alternative: In-app purpose string and App Store permission text should be specific: "Allow access to Contacts to find your friends and invite them to the app".

Problem: Screenshots show a feature that only appears after connecting to a specific third-party service.

Compliant alternative: Replace the screenshot with one that shows the same feature with sample data, and caption it: "Feature shown with sample data - sign-in required".

Handling rejections efficiently

When you get a rejection, do this in order:

1. Read the rejection note fully. Often the final paragraphs show the exact clause violated.
2. Reproduce the issue locally and in a clean device profile.
3. Fix the root cause, not just the symptom. For example, if a reviewer could not access content, provide a fresh test account instead of changing the content visibility.
4. Add a short note in your resubmission explaining what you changed and why. If you had to disable a feature, say so and provide a timeline to restore it.

If you disagree with the rejection, use the built-in appeal channels. Prepare supporting evidence: logs, video, and legal documentation where appropriate.

Tooling and automation to stay compliant

Automate the obvious checks. These tools reduce human error and free you to focus on product.

• Use a metadata validator in CI to check for missing privacy policy, empty screenshots, or unsupported characters in localized names.
• Run an automated permission scan that verifies every requested permission has an associated purpose string.
• Use synthetic testers to run first-run flows on multiple OS versions to catch crashes before submission.

If your team uses ASO tools or creative systems, integrate this preflight into your release pipeline. For resources, see our pages on ASO Tools and Creative Optimization for pipeline templates and automation examples.

What reviewers care about, summarized

• Honesty: The store listing should match the app experience.
• Privacy: Transparent data collection and functional privacy policy.
• Functionality: No crashes and reproducible core flows.
• Payments: Proper use of platform billing for digital goods.
• Safety: Age-appropriate content and ad placement.

Get these five areas right, and you will pass most reviews.

Closing and action steps

Use this guide to build a repeatable pre-submission process. Score every build against the checklist. Include the review readme and test credentials in every submission. That removes guesswork from the process.

AppeakPro can scan your metadata and app readiness and point out the exact issues a reviewer will flag. Run a free audit at /#audit to get a prioritized list. If you want continuous compliance and faster releases, sign up at /signup and connect your app stores. We also cover deeper topics across Learn about ASO and ASO Expertise to help you optimize discoverability once your app is approved.

Make the review process predictable. Ship with confidence.

Frequently asked questions

What are "app store review guidelines"?

App store review guidelines are the rules and policies that Apple and Google use to evaluate whether an app is allowed on their stores. They cover privacy, content, payment rules, ads, and technical behavior.

How long does review usually take?

Typical review can take a few days for Apple and often faster for Google, but complex apps or policy issues can add several days. Preparing compliant metadata and test instructions shortens this time.

What should I include for reviewers to avoid rejections?

Provide a working demo account, clear reproduction steps, a reachable privacy policy, accurate screenshots, correct IAP configuration, and permission purpose strings. Add a short review notes explaining any special setup.

Can I appeal a rejection?

Yes. Both Apple and Google have appeals or contact channels. Prepare supporting evidence like logs, videos, or legal documents and explain why the app complies with the policy in question.

How can AppeakPro help with compliance?

AppeakPro runs an automated audit of your metadata and common compliance checkpoints, highlights high-risk issues, and gives prioritized fixes. Start with a free audit at /#audit or create an account at /signup for continuous monitoring.