App Store Metadata Guidelines: What Reviewers Check and Fix

Introduction

The phrase app store metadata guidelines determines whether your app ships or sits in review. Get the fields, claims, and permissions wrong and you get delays or rejections. Get them right and you speed to approval and better conversion. This guide gives exact limits, the most common rejection reasons, a repeatable 5-step metadata audit, and concrete fixes you can apply today.

Core app store metadata guidelines to follow

Start with platform limits and strict rules. Metadata is not just marketing copy. Review teams treat it as product truth. Inaccurate or misleading metadata is the single fastest route to rejection.

Apple App Store - hard limits and critical rules

• App name: 30 characters. Use your brand and one descriptive keyword. No keyword stuffing.
• Subtitle: 30 characters. Use a clear benefit line, not a slogan.
• Promotional text: 170 characters. Editable without resubmission, used for timely messages.
• Keywords field: 100 characters. Comma-separated, no spaces after commas is fine. Do not repeat words present in your app name or subtitle unless strategic.
• Description: up to 4,000 characters. This does not affect App Store search ranking, but reviewers read it for claims and compliance.
• Screenshots: provide device-specific screenshots that accurately show in-app UI in the device frames you claim to support. Do not show simulated functionality that does not exist.
• Privacy policy URL: required if the app collects user data. Must be reachable and describe data collection in plain English.
• Permission purpose strings: required for each sensitive permission you request, exactly in the Info.plist. The reviewer reads these strings to validate intent.
• No misleading claims: avoid false accuracy claims such as medical or legal guarantees unless you provide proof and required certifications.

Apple-specific tips:

• Include a demo account and reproduction steps in App Review notes if your app requires sign-in.
• Attach a short video if functionality is not obvious from screenshots.
• If using encryption, declare it and provide the export compliance information.

Google Play - hard limits and critical rules

• App title: 50 characters.
• Short description: 80 characters.
• Full description: 4,000 characters.
• Graphic assets: follow Play Console pixel specs per device. Screenshots must be real in-app captures.
• Advertising ID: only use it for advertising and ad measurement. Respect the Google Play policies for user data and consent.
• Play Billing: all digital goods and subscriptions must use Google Play Billing unless you qualify for an exception.
• Target API level: apps must target the current API level per Play policy; older targets can trigger rejection or warnings.
• Safety and permissions: declare sensitive permissions and provide a privacy policy. If your app handles user content, follow the UGC policy and moderation rules.

Google-specific tips:

• Use Play Console store listing experiments to validate language and screenshots before a full rollout.
• Keep short and full descriptions honest and tightly aligned with in-app behavior.

Top rejection reasons and how to fix them

These are the issues that cause most delays. Fix them pre-submission and cut review time.

1. Metadata mismatch - what reviewers see is not what the store claims

• Problem: Screenshots or description promise features that are not available in the binary.
• Fix: Update screenshots to reflect current UI. If a feature requires server side enablement, add a note in App Review explaining how to access it and include credentials.

2. Missing or unclear permissions justification

• Problem: You request camera, microphone, location, or health data without clear purpose strings or use cases.
• Fix: Add precise purpose strings in Info.plist for iOS and runtime permission prompts for Android. In metadata, explain why data is needed and how it is used.

3. Payment and in-app purchase violations

• Problem: Bypassing Google Play Billing for digital goods, or ambiguous pricing metadata.
• Fix: Implement Play Billing for Android digital goods and add clear purchase flow screenshots and terms.

4. Privacy policy absent or unreachable

• Problem: Privacy policy URL returns error or is overly generic.
• Fix: Host a reachable policy page that maps to your data flows. Mention analytics, ad networks, and third-party SDKs.

5. Misleading claims or medical/legal promises

• Problem: Claiming therapeutic or diagnostic benefits without clearance.
• Fix: Remove unverified medical claims, or provide supporting certification and documentation in the review notes.

6. Incomplete submission notes for restricted features

• Problem: Apps with login or device-specific hardware fail because reviewers cannot access key features.
• Fix: Provide test accounts, detailed steps, and any server-side flags the reviewer needs to enable.

7. Content and copyright violations

• Problem: Using copyrighted content in screenshots or descriptions without rights.
• Fix: Replace with licensed content or obtain written permission and cite it in review notes if needed.

8. Ads and monetization policy violations

• Problem: Ads shown prior to user consent or targeted without permission.
• Fix: Implement consent flows, disclose ad networks in privacy policy, and ensure ads are not disruptive to the core user experience.

Metadata mapping framework - a 5-step audit you can run in 30 minutes

This is the repeatable checklist I use for every submission. It catches the top reasons for rejection and improves conversion.

1. Field validation - check limits and required fields

• Confirm character limits: iOS name 30, subtitle 30, promo text 170, keywords 100; Android title 50, short description 80, full description 4,000.
• Verify privacy policy URL loads and is indexable.

2. Claim verification - align text with build

• Scan the description and screenshots. For every feature claim, verify the binary implements it.
• Mark any server-side gated features and prepare access credentials for review.

3. Permission and data flow proof

• Document every permission your app requests, the exact purpose string, and where in-app that permission is used.
• If you collect identifiers or personal data, map them in the privacy policy and note third-party processors.

4. Compliance cross-check

• Check Apple App Store Review Guidelines for content rules that apply to your category, e.g., health, kids, gambling.
• Check Google Play Developer Policies for ads, monetization, and device targeting.

5. Submission hardening

• Prepare an App Review note with 3 items: reproduction steps, demo credentials, and a short privacy summary.
• Attach a short screen recording if reviewers need to see key flows.

Run this checklist for each localization, not just the default language.

How reviewers scan listings - optimize the first 10 seconds

Reviewers and users judge your listing quickly. Optimize for clarity.

1. First screenshot and app name: priority one

• The first screenshot and the app name are the first signals. The screenshot should show the primary use case and match the name.

2. Subtitle or short description: clarify benefit

• Use these short fields to state the single most valuable outcome for the user.

3. Permissions and privacy: minimize friction

• Request only the permissions you need. If you must request sensitive data at install time, be prepared to justify it in the review notes.

4. Consistent visuals and language

• Match colors, fonts, and UI between screenshots and the actual app. Avoid marketing overlays that claim features the app does not have.

Example good vs bad

• Bad app name: PhotoEditorPro Edit Filters Photo Enhance Now

• Good app name: PhotoLab - Quick Photo Editor

• Bad short description: The best editor with all filters, boosts, hands-free modes, and one-click fix, guaranteed

• Good short description: One-tap photo fixes, essential filters, and fast export

The good examples are shorter, truthful, and focused on benefit.

Automating checks and tools to speed review

Use tooling to avoid manual misses. Integrate these checks into your release process.

1. Pre-submit checklist automation

• Add a pre-submit script that verifies character limits, checks that privacy policy URL returns 200, and validates the presence of demo credentials in release notes.

2. Visual validation

• Use screenshot comparison tools to ensure the screenshots you upload match the build. This prevents accidental mismatches when UI changes.

3. Policy scanning tools

• Run automatic scans for restricted keywords and common policy triggers. This catches phrases like gambling, medical claims, or targeted youth content before you submit.

See ASO Tools (/aso-guide/aso-tools) for automation options and integrations. For messaging and conversion tactics tied to metadata, check Creative Optimization (/aso-guide/creative-optimization). If you need the fundamentals, review Learn about ASO (/aso-guide/learn-about-aso).

When you get rejected - exact steps to recover fast

1. Read the rejection reason carefully. Copy and paste the exact wording to a checklist.
2. If unclear, reply in the resolution center asking for clarification. Keep your message factual and concise.
3. Fix the issue in the metadata or binary. Do not make additional unrelated changes that could create new review risks.
4. Re-submit with a short note describing the change and steps to reproduce. If you added a demo account, include credentials.
5. If the rejection persists, escalate with documentation: screenshots, privacy policy excerpts, and any third-party certifications.

A common error is resubmitting multiple changes at once. Make one fix per submission if you need a clean troubleshooting path.

Closing - ship with confidence

Metadata mistakes are easy to fix and costly to ignore. Use the 5-step audit, keep descriptions honest, provide reviewer access, and automate pre-submit checks. That removes 80 percent of the friction I see in reviews.

If you want a quick second opinion, run a free audit with AppeakPro at /#audit. We will scan your metadata fields, permissions, and common policy flags and return prioritized fixes. Ready to act now? Create an account at /signup and start the audit in minutes.

Frequently asked questions

Does the App Store description affect search ranking?

No. On Apple the keywords field, app name, and subtitle carry search weight. The description is visible to users and reviewers and should be accurate, but it does not influence App Store search ranking.

What are the exact character limits I must remember?

Key limits: iOS name 30, subtitle 30, promotional text 170, keywords 100, description 4,000. Android title 50, short description 80, full description 4,000. Always confirm current limits in App Store Connect and Play Console before submitting.

What should I include in App Review notes?

Include 3 items: steps to reproduce or use key flows, demo credentials or a test account, and a short note listing any server-side flags or region restrictions.

How do I handle permissions for privacy-sensitive data?

Request permissions only when needed, provide clear purpose strings for iOS, explain the use in the privacy policy, and show the permission prompt only in the context of the feature that requires it.