App Rejection Checker
Lint your app metadata for the phrases and patterns that trigger App Store rejections.
Metadata problems are among the most common — and most avoidable — App Store rejection reasons. Guideline 2.3 (Accurate Metadata) covers a family of mistakes reviewers catch constantly: competitor brand names dropped into your keywords, prices like “free” in the app name, unverifiable “best” and “#1” claims, mentions of Android on an iOS listing, leftover placeholder text, and names decorated with emoji.
Paste your app name, subtitle, keywords, or description above and this linter scans the text against those known rejection patterns, flagging each match with the reason it’s risky. A clean result is not a guarantee of approval — reviewers judge the whole app — but it removes the self-inflicted mistakes that waste a review cycle.
How to check your metadata for rejection triggers
- 1
Paste the metadata field you want to check — app name, subtitle, keyword field, promotional text, or description.
- 2
Run the scan to see every flagged phrase grouped by rejection category, from brand-name misuse to placeholder text.
- 3
Review each flag in context: some, like a factual comparison inside a description, may be acceptable — while a competitor name in your keyword field rarely is.
- 4
Rewrite the flagged phrases and re-run the check until the report is clean.
The metadata mistakes that get apps rejected
Guideline 2.3.7 requires metadata to be accurate and relevant, and Apple interprets it strictly. Using another company’s trademarked app name in your title, subtitle, or keyword field is treated as trademark misuse and keyword manipulation. Pricing information — “free”, “$0.99”, “50% off” — does not belong in the app name or screenshots because prices vary by storefront and change over time. Superlative claims like “best photo editor” or “#1 fitness app” are flagged as unverifiable unless you can cite the source directly.
Two quieter categories cause just as many bounces. Platform mentions — referencing Android, Google Play, or “also on Windows” in iOS metadata — violate the rule against promoting rival platforms. And placeholder text (“lorem ipsum”, “coming soon”, “TODO”, “test”) left in a description or What’s New field signals an unfinished submission; reviewers reject these on sight. Excessive emoji and decorative symbols in the app name round out the list, since Apple expects names to be names, not banners.
What to do when a flag isn’t clear-cut
Context matters. A factual interoperability sentence deep in your description (“imports your data from X”) is generally acceptable because it describes real functionality; the same brand name stuffed in the hidden keyword field is not, because its only purpose is to rank on someone else’s trademark. Similarly, “free trial” in the description accurately describing your offer is fine, while “FREE” in the app name is a pricing claim in a field where it is banned.
When in doubt, ask what a reviewer would conclude your intent is. Metadata exists to describe your app to users; anything whose main function is to game search or borrow another brand’s traffic invites rejection, and repeat metadata offenses can escalate to more serious account-level scrutiny. It costs less to lose one borderline keyword than to lose a week to a rejected build.
Frequently asked questions
Can I put a competitor’s name in my App Store keywords?
It is against Apple’s guidelines — 2.3.7 prohibits using other apps’ names or trademarked terms in your metadata, and trademark owners can also file complaints that get keywords stripped or apps removed. Rank against competitors by targeting the generic terms their users search, not their brand names.
Why is the word “free” a problem in an app name?
Apple treats pricing references in app names, subtitles, and screenshots as metadata violations because price is shown by the store itself, varies by country, and changes over time. Describe your free tier in the description instead, where factual pricing context is acceptable.
Are “best” and “#1” claims always rejected?
Unverifiable superlatives in metadata are a known guideline 2.3 trigger. If you have a citable basis — “App of the Day”, a named award, a specific chart position — reference it precisely. A bare “best weather app” claim has no source and reads as manipulation to a reviewer.
Does this checker guarantee my app won’t be rejected?
No. It lints text against known metadata rejection patterns, which removes a common class of avoidable mistakes. App review also evaluates functionality, design, privacy, payments, and content, none of which a text linter can see. Pair it with a full pre-submission checklist.
Can I mention Android or Google Play in my iOS app description?
Avoid it. Apple’s metadata rules disallow references to other mobile platforms in your App Store listing. Cross-platform availability belongs on your website, not in iOS metadata — and the same courtesy applies in reverse on Google Play.
Catch metadata risks before Apple does
Appalize runs compliance checks across every locale of your metadata automatically — brand terms, banned claims, and length limits — before anything is pushed to App Store Connect.
Related free tools
Pre-Submission Checklist
Run through every App Store submission requirement before you press “Submit for Review”.
App Name Character Counter
Check your App Store app name against the 30-character limit as you type.
Special Character Checker
Detect emoji, symbols, and invisible characters that put your metadata at rejection risk.
All-in-One Metadata Length Checker
Validate every App Store and Google Play text field against its limit in one screen.