App Store rejection checker

Reference

The 8 most-cited rejection guidelines

• 2.1 — App Completeness: Placeholder text, "coming soon", broken features, missing demo login, beta language. The single most common rejection cause.
• 2.3.7 — Metadata: Pricing in description, URLs in description, OS-name keyword stuffing in title/subtitle, irrelevant keywords.
• 3.1.1 — In-App Purchase: Using a payment system other than Apple's IAP for digital goods, referring users to your website to buy a subscription.
• 4.0 — Design: Cloned/copied UI, low-quality interface, unsupported promotional claims like "best app" or "#1".
• 4.3 — Spam: Duplicate apps, copy-pasted listings across multiple submissions, repackaged content, spam-shaped keyword stuffing.
• 5.1.1 — Privacy: Missing privacy policy URL, missing privacy nutrition label, data collection without disclosure. Also covers PrivacyInfo.xcprivacy requirements.
• 5.1.2 — Data Use: Misleading privacy nutrition label, collecting more data than disclosed, selling data without explicit consent.
• 1.4 — Health: Health & Fitness and Medical apps without medical disclaimers, making clinical claims, scaring users.

Apple's full guidelines: developer.apple.com/app-store/review/guidelines. Google Play's: play.google.com/console/about/policy.

FAQ

Quick answers

What are the most common reasons Apple rejects apps?

Guideline 2.1 (App Completeness — placeholder text, broken features, demo accounts not provided), 4.0 (Design — copying existing apps, low-quality UI), 5.1 (Privacy — missing privacy policy, missing data declarations), and 3.1.1 (In-App Purchase — using a different payment system for digital goods) account for the majority of rejections. This checker scans your metadata for the patterns that trigger each.

Does this checker guarantee approval?

No tool can guarantee approval — Apple's review is human and contextual. This checker catches the metadata-level mistakes most often cited in rejection emails: banned phrases, missing privacy info, beta language, pricing in description, age-rating mismatches. It won't catch issues with your actual binary (crashes, broken flows, missing demo credentials) — only what review can see in your listing.

What is the difference between Apple and Google Play rejections?

Apple rejects more aggressively on guidelines 2.1 (completeness), 4.3 (Spam — copying competitor apps), and 5.1 (Privacy). Google Play rejects more often on metadata policy violations (impersonation, misleading screenshots) and policy categories (financial, health, kids). This checker flags issues for both stores.

Why does my description trip the 'beta' flag?

Apple bans the word 'beta', 'test', 'preview', 'demo', or 'coming soon' in production app metadata under Guideline 2.1. They want shipped apps to be feature-complete. If you have legitimate beta-testing language elsewhere, move it to TestFlight metadata, not the App Store listing.

Should I include pricing in my app description?

No. Apple Guideline 2.3.7 prohibits including specific prices, sale terms, or 'Free' / 'Paid' language in your app description because pricing is shown elsewhere on the listing and changes don't trigger a description update. Mentioning a subscription tier ('$9/month') in the description is a frequent rejection cause.

Does this tool send my metadata anywhere?

No. The entire check runs locally in your browser using deterministic rules. Your title, subtitle, keywords, and description never leave the page. No signup, no logging.