App Store Guidelines: How to Pass Review the First Time in 7 Steps

app store guidelines drive almost every submission decision. If you treat them as legal puzzles you will waste time. Treat them as practical requirements and you will cut review cycles in half.

This guide gives a zero-fluff, tactical path to pass Apple and Google reviews on the first submission. It includes a 7-step checklist, the top rejection triggers to fix, exact metadata limits, and reviewer-note templates you can copy and paste.

app store guidelines - 7-step review checklist

Follow these 7 steps in order. They are intentionally sequential. Fixing metadata before you stabilize the build wastes time.

1. Build a release candidate with stability metrics
   • Crash-free target: 99.5% or higher during a 72-hour internal test. Use Firebase Crashlytics or Sentry. Reject builds that show reproducible crashes.
   • Core flows automated tests: 80 percent of main user flows covered. Focus on onboarding, sign-in, payment, and core feature paths.
2. Prepare required artifacts and documentation
   • Privacy policy URL, support URL, marketing URL where needed.
   • Demo account credentials or a TestFlight note that bypasses sign-in.
   • Export compliance and content ownership documents if you use proprietary codecs, maps, or health data.
3. Harden permissions and explain usage
   • Only request permissions you actually use. Add clear purpose strings in the app and matching explanations in the App Store review notes and Play Console privacy section.
4. Audit metadata against hard limits
   • App Store app name max 30 characters. Display name shorter than 30 is safer.
   • Google Play title recommended under 50 characters.
   • Subtitle (App Store) max 30 characters. Short and specific.
   • 3 to 10 screenshots per device size for iOS; Google Play allows up to 8 screenshots and one feature graphic (recommended 1024x500).
5. Add reviewer notes and test credentials
   • Include step-by-step reproduction steps and a demo account. If payment or region locks exist, leave a reviewer bypass.
6. Run a dry run submission with internal testers
   • Upload to TestFlight or internal testing track. Let a fresh pair of eyes follow the reviewer notes exactly. Fix gaps in the notes.
7. Submit and monitor
   • After submission, watch the Resolution Center and Google Play Console comments for the first 24 hours. Be ready to respond with logs, videos, or a rebuilt binary.

Top app rejection reasons and how to fix them

Both Apple and Google reject apps for similar root causes. Fix the root cause, not the symptom.

Functional failures and stability

Symptom: reviewer reports crash on launch or on a common flow. Fixes:

• Reproduce the exact OS version and device class the reviewer mentions and attach logs. Most reviewers use current stable OS builds, but test back one major version.
• Provide a crash log and a short explanation in the Resolution Center. If crash is device-specific, offer alternate device access or a video showing the fix.

Incomplete reviewer access

Symptom: app requires login and reviewer cannot complete flow. Fixes:

• Always include a test account: username, password, and exact steps. If the app requires rate-limited onboarding, provide a bypass or flags in build.
• For region or carrier locks, supply a build that disables the check or give a reviewer account on allowed carriers.

Metadata and content violations

Symptom: rejected for inappropriate keywords, trademark misuse, or misleading description. Fixes:

• Remove trademarked terms you do not own from title and subtitle.
• Do not mention rankings, download counts, or "App Store" and "Google Play" in the app name or promo text.
• Keep promotional claims supported by evidence. For example, if you say "reduces anxiety", include clinical study citations in review notes when applicable.

Privacy and data collection issues

Symptom: lacking a privacy policy, improper use of device identifiers, or no purpose strings. Fixes:

• Provide a reachable privacy policy URL before submission.
• For iOS, include NSCameraUsageDescription, NSPhotoLibraryUsageDescription, and any other required keys in Info.plist with clear purpose text.
• For tracking, implement App Tracking Transparency prompt correctly and declare tracking in App Store Connect.

Payments and subscriptions

Symptom: in-app purchase bypass or external payment prompts. Fixes:

• Use platform billing for digital goods and subscriptions. Apple and Google both require their in-app payment systems for in-app digital content.
• If you offer physical goods or person-to-person services, use your own payment processor and explain the distinction in review notes.

User-generated content and moderation

Symptom: app allows UGC without filters or reporting tools. Fixes:

• Implement content moderation workflows: pre-moderation for high-risk categories or reactive moderation plus reporting, blocking, and appeals.
• Document the moderation flow and response time frames in reviewer notes. Provide examples of flagged content and moderator actions.

Metadata compliance checklist with exact rules and examples

This is the working checklist you should run before uploading screenshots or text.

1. App name
   • App Store: max 30 characters. Example: "Focus Notes" not "Focus Notes - The Best Productivity App Ever".
   • Google Play: keep it under 50 characters for better display.
2. Subtitle / Short description
   • App Store subtitle max 30 characters. Use immediate benefit: "Task timers and focus sessions".
   • Google Play short description recommended 80 characters.
3. Long description and keywords
   • Apple ignores a dedicated keywords field weightily, but the title and subtitle carry most weight. Avoid keyword stuffing.
   • Google uses the long description for ASO. Put the strongest keywords in first 25 words.
4. Screenshots and previews
   • Provide 3 strong screenshots that capture the first user journey. The first two are critical on all devices.
   • For iOS, include device-specific screenshots for iPhone 6.7-inch and 5.5-inch where appropriate.
5. App preview video
   • 15 to 30 seconds, device-recorded, shows core flow, no demo account or login. Host in App Store Connect or Google Play Console as required.
6. Privacy and contact info
   • Privacy policy URL, support email, and physical address if business account requires it.
7. Category and age rating
   • Pick the most specific category. Wrong category can get you rejected if your content contradicts it.

Policy-specific implementation playbooks

Below are concise playbooks for the most common policy pitfalls.

Payments and subscriptions

• Digital goods: use Apple In-App Purchase or Google Play Billing. Tag each subscription product with clear introductory pricing and auto-renew facts.
• Localize pricing and renewals language for each store country.
• Provide a cancel flow or clear cancel instructions in both app and metadata.

Privacy, data collection, and consent

• Minimize data collected. If you do not need it, do not ask.
• Document every data field collected, the storage location, retention period, and purpose. Keep this document in your repo and paste the summary into review notes.
• For sign-in with third-party services, disclose the identity provider and any data fetched.

User-generated content and moderation

• Implement three things: reporting, blocking, and a moderation backlog with SLA. State the SLA in review notes.
• If your app targets children, implement COPPA-safe flows and disable social features by default.

Ads and monetization

• Disclose ad networks and do not collect personal data without consent.
• Ads that impersonate system UI, prompt for downloads, or are misleading will be rejected.

Pre-submit testing and what to include in reviewer notes

Reviewer notes are your single best lever to avoid back-and-forth. Use them to remove ambiguity.

What to include:

• Exact steps to reproduce a core flow, with screenshots or time-stamped video.
• Test account: username, password, region, and any PIN codes.
• If certain features are behind feature flags, state how to enable them in this build.
• Known limitations and planned fixes if critical issues exist. Be short and honest.

Reviewer-note template (copyable):

Username: reviewer@example.com Password: Test1234 Steps to reproduce:

1. Open app, allow location when prompted.
2. Tap "Sign In" and use the account above.
3. Go to Dashboard - tap Start to trigger the core flow. Notes:

• This build uses mock payment for the region US. To test subscription flow, go to Settings - Subscriptions and tap Purchase. Contact support at support@example.com if needed.

After a rejection: triage, fix, and resubmit

1. Read the rejection message word for word. Identify whether it is a metadata issue, a functional bug, or a policy interpretation.
2. If it is metadata, change the metadata and resubmit. Do not resubmit a new binary unless required.
3. If it is functional, attach crash logs, steps, and a new build. Label the version clearly so the reviewer knows it is a fix build.
4. Use the Resolution Center to clarify misunderstandings. Provide short, factual replies and attach evidence.
5. If you disagree with the decision, escalate through the official appeals process in each console. Keep communications factual and reference the exact guideline number.

Closing and next steps

Get this checklist into your release process now. Save the reviewer-note template in your repo. Add the metadata limits to your content brief so creative teams do not overrun platform rules.

If you want a fast second opinion, run a free audit at /#audit with AppeakPro. We will flag the top 12 review risks and give prioritized fixes. To apply fixes and automate future submissions, create an account at /signup and connect your App Store Connect or Play Console for continuous checks.

For deeper ASO work that reduces rejections and improves visibility, see Learn about ASO (/aso-guide/learn-about-aso) and check our integrations in ASO Tools (/aso-guide/aso-tools). If you need a policy review before launch, our ASO Expertise team will draft reviewer notes and metadata that match the app store guidelines precisely.

Ship fewer rejections. Ship faster. AppeakPro helps you do both.

Frequently asked questions

How long do app store reviews usually take?

Typical review time is 24 to 72 hours for Apple and a few hours to several days for Google Play. Complex cases with policy checks can take longer.

Do I need to include a demo account for every submission?

Yes if your app requires login. Always include a demo account and clear steps. If the app is region-locked, provide an account that bypasses the lock or a special build.

Can I change metadata without a new binary?

Yes. Most text, screenshots, and promotional assets can be updated without uploading a new binary, but some changes like the app name may require a new binary review cycle.

What is the fastest way to recover from a rejection?

Triage the rejection type. Fix metadata issues and resubmit metadata. For functional issues, gather logs, attach a new build, and provide exact reproduction steps.

Do Apple and Google have the same rules for payments?

Both require platform billing for in-app digital goods and subscriptions. Physical goods and person-to-person services may use external processors but must be clearly described in metadata.