apple app review guidelines: A practical checklist to pass

Introduction

apple app review guidelines shape every decision you make before submitting an app. Ignore them and you will waste weeks on resubmissions. Follow them precisely and you cut review time and avoid rejection cycles. This guide gives a practical, field-tested checklist, the top rejection reasons and exact metadata patterns that clear review the first time.

apple app review guidelines: what the App Store actually enforces

Apple publishes a long list of rules. The reality is simpler. During review Apple focuses on a small set of signals that determine approval or rejection:

• Safety and legal compliance. User privacy, data handling, and any regulated content.
• Functionality and stability. Does the app run, or does it crash or hang on launch.
• Metadata accuracy. Screenshots, descriptions, and features must match the shipped experience.
• Business model integrity. In-app purchases, subscriptions and paid features must be implemented and disclosed properly.
• Content and moderation. User-generated content must be moderated and reportable.

Treat these five areas as your primary success criteria. If they are clean, the rest is administrative.

Quick rule of thumb

If you and one engineer can reproduce a rejection within 10 minutes from the review notes, the problem is fixable quickly. If it requires a policy interpretation, prepare a short, structured explanation and evidence to attach to your review notes.

Top 6 rejection reasons and how to fix them

These are the highest-frequency failure modes we see across hundreds of audits. Each entry has an immediate fix you can implement before submission.

1) Broken or gated functionality on first launch

Problem: The reviewer cannot reach core functionality because login is blocked, server endpoints fail, or a required backend flag is off.

Fix: Ship a demo account or a fully unlocked demo mode that reproduces core flows without account creation. Put credentials in the review notes and verify on a clean device. Include environment details: build number, test account, and any feature flags.

2) Misleading metadata or screenshots

Problem: Screenshots or the description promise features that are not present in the build.

Fix: Match screenshots to the actual UI at the same device size. If you use localized screenshots, ensure the localized build shows the same language. Use a consistent callout for in-app purchases and avoid promotional text that implies platform-level functionality.

3) Privacy and data-collection gaps

Problem: Missing purpose strings for permissions, or sending user data to analytics without clear disclosure.

Fix: Implement explicit permission strings in Info.plist for every permission. Add a privacy policy link in App Store Connect and include a short privacy summary in the app description. For any third-party SDK, document the data flows and prepare a note for review explaining what is sent and why.

4) In-app purchase and subscription implementation errors

Problem: Purchases fail, sandbox receipts do not validate, or subscription upgrade/downgrade behavior is broken.

Fix: Test all purchase flows in sandbox and include a debug account that has test purchases. Verify receipt validation works on the server if you use server-side validation. Provide a clear description of how the in-app purchase appears in the app and in the App Store Connect setup.

5) User-generated content moderation missing

Problem: Apps with chat, forums, or uploads have no reporting or moderation controls.

Fix: Add a visible report button and a moderation workflow. Include a brief moderation policy in the app and describe the policy in review notes. If you use automated moderation, explain thresholds and escalation rules.

6) Accessibility and regional legal problems

Problem: Required legal notices, age gates or local law compliance is missing for regulated categories like gambling or health.

Fix: Implement age verification or certification flows, and include evidence if you have licenses. Where regional laws require in-app disclosures, include them in the first-time onboarding flow and in-app settings.

Metadata that passes review: field-by-field checklist and templates

Apple enforces metadata accuracy. Treat metadata as part of the product that must match the binary. Below are the fields you must prepare and the acceptable patterns.

Core metadata fields and limits (current common limits):

• App Name: up to 30 characters. Use a single clause: Brand or Brand - Core Feature.
• Subtitle: up to 30 characters. Use this for your unique value proposition in three to five words.
• Promotional Text: up to 170 characters. This can be updated without a new binary. Put timely offers or callouts here.
• Description: long form, explain benefits and key features. Lead with the three main user outcomes in the first 1-2 sentences.
• Keywords: up to 100 characters. Use comma-separated tokens, avoid duplicates and punctuation.
• Screenshots: Provide device-specific screenshots. 6.5-inch and 5.5-inch screenshots are the minimum for most categories. Include at least one portrait and one landscape if your app supports both.

Example metadata templates

• App Name: "BrandName - Task Manager"
• Subtitle: "Simple to-do lists and reminders"
• Promotional Text: "New: collaborative lists and offline sync. Try shared lists today."
• Description start: "Simple to-do lists for teams and individuals. Create tasks in seconds, assign teammates, and sync across devices with offline support."

Rules for screenshots and previews

• Do not add device frames or text overlays that are not present in the app UI. If you use overlays, they must accurately describe the feature shown.
• If an App Preview video shows a flow, make sure the live app replicates it exactly. Any mismatch is grounds for rejection.

Localization best practices

• Localize all visible metadata for a locale if screenshots or UI change per locale. If you localize screenshots but not metadata, reviewers will treat that as inconsistent.
• Use localized test accounts in review notes when UI differs by region.

Submission workflow to minimize rejections

Follow this reproducible workflow before you press Submit for Review. It reduces back-and-forth and fixes 70 percent of preventable rejections in our audits.

1. Internal prerelease QA checklist

• Build runs on a fresh device with no prior installs.
• Test flows with the lowest permitted network bandwidth and with no network connectivity.
• Verify permissions and Info.plist purpose strings show at the correct time.

2. Metadata freeze and verification

• Finalize metadata in App Store Connect before uploading the build.
• Take screenshots from the final build on the exact device model you claim in the metadata.

3. Attach a structured review note

Include a short set of review notes that contains:

• A step-by-step path to reach main features, including test account credentials.
• Feature flags and environment (staging or production) used during review.
• Any third-party dependencies or regional behaviors.

4. Run a compliance scan

Use both static and runtime tools to confirm you are not referencing private APIs, and that transport security and ATS rules are respected. This is where linking to an ASO Tools review helps. See ASO Tools (/aso-guide/aso-tools) for recommended scanners.

5. Submit and monitor

After submission, monitor App Store Connect for reviewer questions. Respond quickly and attach screenshots or short videos if the reviewer reports a mismatch.

If you get a rejection: appeals, expedited review, and resubmission

Rejections fall into two buckets: technical and policy. For technical issues, fix the build and resubmit. For policy issues, you must either modify the app to comply or prepare a concise rebuttal.

Appeal checklist

• Read the rejection reason carefully. Reviewers may cite a general policy section. Identify the exact failing line in your app and address that.
• Provide evidence. Screenshots, a short video, server logs, and a structured explanation of why your app complies.
• Use the Resolution Center politely. Lead with a one-sentence summary of your fix, include the build number, and attach the evidence.

When to request expedited review

Apple grants expedited reviews in narrow circumstances, such as critical bug fixes for a live app or time-sensitive legal updates. Prepare proof of customer impact and business impact. Expedited review requests are not guaranteed.

Ongoing compliance and monitoring

Passing review once is not enough. Policies change and your app evolves. Treat compliance as a maintenance task.

Continuous compliance checklist

• Add policy checks into your release checklist and gate releases on them.
• Run automated privacy and security scans during CI. Tie results to pull request approvals.
• Periodically audit third-party SDKs for data collection and keep a ready explanation for reviewers.

Reporting and performance monitoring

• Keep a small audit trail for moderation actions and user reports. This is useful for appeals and for demonstrating compliance to Apple.
• Monitor crash rates and startup performance after each release. Apple reviews crash trends on some submissions.

Integrate ASO work with compliance

Metadata and creatives change your visibility and can trigger fresh reviews. Coordinate Creative Optimization (/aso-guide/creative-optimization) with your compliance calendar so screenshot updates, localization pushes, or A/B tests do not introduce unexpected policy exposure.

Also align store metadata with product changes and App Growth (/aso-guide/app-growth) campaigns to ensure the messaging matches the binary being reviewed.

Closing and next steps

The practical path to consistent approvals is straightforward: make the app demonstrably functional, ensure metadata matches the binary exactly, and document everything for the reviewer. Use a demo account, include clear review notes, and run a short compliance checklist every release.

If you want a fast, objective evaluation, get a free audit from AppeakPro. We run a policy and metadata scan and return a prioritized list of fixes within 48 hours. Start with a free audit at /#audit and create an account at /signup to see continuous monitoring and automated checks in your pipeline.

AppeakPro helps you stop guessing and start shipping with confidence. Schedule the free audit and remove the guesswork from your next App Store submission.

Frequently asked questions

What is the single fastest fix to avoid rejection?

Provide a working demo account or unlocked demo mode and include credentials in the review notes. This prevents most rejections caused by gated or server-dependent functionality.

Do I need to include a privacy policy to pass review?

Yes. You must include a privacy policy link in App Store Connect. Also implement clear permission purpose strings in Info.plist explaining why you request each permission in the app.

How should I handle screenshots for different locales?

Localize screenshots only if the localized UI matches. Otherwise provide the same screenshots across locales. If you localize, attach localized test credentials for review.

Can I appeal a policy rejection?

Yes. Use the Resolution Center to appeal. Prepare concise evidence, such as videos, logs, or legal documents, and explain exactly how the app complies with the cited policy.

How often should I run a compliance audit?

Run a full compliance audit before every production release and a lightweight scan for each feature branch merge. Also audit third-party SDKs quarterly.