Banned Keywords on iOS: What Apple Won't Allow in Your Listing

October 17, 2026

Banned Keywords on iOS: What Apple Won't Allow in Your Listing

Banned Keywords on iOS: What Apple Won’t Allow in Your Listing

iOS listing with keyword compliance analytics

Apple does not publish a list of banned words for the App Store. It publishes rules, and those rules ban categories of terms: trademarks you don’t own, other apps’ names, pricing claims, references to rival platforms and anything irrelevant to what your app does. Break them and you risk a rejection, or a quieter outcome: keywords removed from your listing with no explanation.

This guide covers what the App Review Guidelines say, which terms trip them most often, how to audit your own metadata before you submit, and how to build a keyword set that holds up over time. It is written for developers and marketers who manage an App Store listing. It is not about the word filters on a user’s iPhone or Tumblr’s in-app search blocks, which are different topics.

Apptenium
apptenium.com
Keep Your App Store Keywords on Track
Apptenium combines keyword tracking, ASO scanning, and AI-powered recommendations to help you monitor app visibility and listing performance.
Explore Apptenium

TL;DR

  • There is no official banned-word list. Guideline 2.3.7 bans trademarked terms, popular app names, pricing information and irrelevant phrases used to game search.
  • Naming Android, Google Play or other platforms in your metadata violates Guideline 2.3.10.
  • Non-compliant keywords are often stripped silently, so a rank drop can be your only warning.
  • The safest approach is accurate, benefit-led metadata: describe what the app does, not what ranks.
  • Audit your name, subtitle and keyword field before every release, and again after any visibility drop.

Table of Contents

Is there a list of banned keywords on iOS?

No single list exists, and any site selling you one is guessing. What Apple gives you is a rule. Guideline 2.3.7 tells developers to choose a unique app name, assign keywords that accurately describe the app, and avoid packing metadata with trademarked terms, popular app names, pricing information or other irrelevant phrases just to game the system.

That makes “banned” a matter of context. The word “photo” is fine for a photo editor and a problem for a mortgage calculator. The word “Instagram” is fine in a sentence nobody indexes and a problem in your keyword field. The test is always the same: does this term accurately describe your app, and does it belong to someone else?

There is also a practical layer. Apple may modify keywords at any time without notification, so a term that survived last year’s review can disappear today. Compliance is a habit, not a one-time check.

The metadata fields the rules apply to

Guideline 2.3.7 covers your app name, subtitle and keywords. The character limits shape how much room you have to make mistakes:

Field Limit Visible to users Search weight
App name 30 characters Yes Strongest
Subtitle 30 characters Yes Second
Keyword field 100 characters No Medium

The 30/30/100 limits and their relative ranking weight are well documented by ASO practitioners, and Apple’s own guidelines confirm the 30-character cap on app names. Because the keyword field is hidden, it is where developers are most tempted to cut corners. It is also where silent removals are hardest to spot, since no customer sees the text.

The rules on accurate metadata extend beyond those three fields. The description, promotional text and What’s New notes should also describe your app honestly, and the platform-reference rule below applies to all of them.

The metadata fields the rules apply to — overview diagram

Categories of terms that cause trouble

Instead of hunting for a list, learn the categories. Almost every metadata problem falls into one of these.

Trademarks and brand names you don’t own

Adding a well-known brand to your keyword field because users search for it is the classic violation. If your app lets people share photos to a social network, naming that network as a keyword is exactly what the guideline targets. Describe the function (“photo sharing”) and leave the brand out.

There is a legitimate gray area: a brand name used descriptively in your description text, such as “works with your existing account”, may be acceptable where it is factual. Keep it out of the name, subtitle and keyword field unless you hold the rights.

The guideline names “popular app names” explicitly. Stuffing a rival’s title into your keywords may feel like smart targeting, but it is the shortcut reviewers look for first. Use competitor names for research, not for your listing. A competitor-intelligence workflow, such as the one in Apptenium’s market and competitor tools, shows you which terms rivals rank for so you can find the underlying generic phrases to target instead.

Pricing words

“Free”, “discount”, “sale” and similar terms are covered by the pricing-information clause. Price-related terms and competitor names are common trigger points for both automated and manual review flags. Your price is already displayed on the product page by Apple, so a keyword adds nothing legitimate.

References to other platforms

Guideline 2.3.10 asks you to keep metadata focused on the iOS experience. Mentioning Android, Google Play or other mobile platforms in your listing gets flagged, and Apple’s suggested fix is a generic line such as “available on multiple platforms”. One open-source review checklist spells out the typical offenders: Android, Google Play, Google Play Store, Samsung, Galaxy Store and similar. It applies to every metadata field, including the description and release notes, not just keywords.

Irrelevant high-volume terms

Adding “weather” to a podcast app because it has traffic is the textbook case of an irrelevant phrase. Apple’s rules exist to keep search results useful. When metadata is stuffed with terms that don’t match the app, it degrades results and becomes an easy target for manual review.

Trend and technology labels

A name like “AI-Powered Tracker” ages quickly. Technology-stack labels date fast and can make unverifiable claims, which puts them in the 2.3.7 danger zone. Lead with the user benefit instead, for example what the tracker helps someone do.

Rejection versus silent removal

There are two ways a violation shows up, and they feel very different.

A rejection. Your build is returned with a note citing the guideline, usually 2.3.7 for keyword abuse. This is annoying but clear. You fix the metadata and resubmit.

A silent strip. Reviewers often enforce 2.3.7 by removing non-compliant keywords rather than rejecting the whole submission. You get no message. The only symptom is that rankings for certain terms slide or vanish.

The second case is more damaging because it is invisible. If you track keyword positions, a sudden drop on a cluster of terms that share a trait (all brand names, all price words) is a strong hint of a policy cause rather than a competitor move.

Rejection versus silent removal — overview diagram

How to audit your metadata before you submit

Run this checklist for every release. It takes about twenty minutes and saves a resubmission cycle.

  1. Export your current name, subtitle and keyword field. Put them in a single document so you read them together.
  2. Flag any proper noun. Every capitalized brand, product or company name needs a reason to be there. If it isn’t yours, remove it.
  3. Search for price language. Look for free, cheap, discount, sale, deal, offer, premium and any currency symbol.
  4. Search for platform words. Look for Android, Google Play, Windows and other competing ecosystems.
  5. Check relevance, term by term. Ask whether a user who searched this term would be satisfied by your app within the first screen.
  6. Check claims. Superlatives and technology claims you can’t verify (“best”, “#1”, “AI-powered” when the feature is minor) invite scrutiny.
  7. Count characters. Keep the name within 30 characters and the subtitle within 30. Confirm the keyword field fits 100 characters without wasted commas or repeated words.
  8. Compare against your last ranking snapshot. If a term was ranking and now isn’t, check whether Apple removed it.

The same discipline applies to the rest of your launch. A pre-launch QA sign-off checklist is a useful companion here, because metadata review fits naturally beside functional testing before you press submit.

A quick worked example

Say you ship a budgeting app and your draft keyword field reads: free,budget,mint,expense tracker,android,best money app,ai.

  • “free” is pricing information. Remove it.
  • “mint” is a competitor’s name. Remove it.
  • “android” references another platform. Remove it.
  • “best money app” is a vague superlative and duplicates words already indexed from your name. Replace it with a specific benefit term.
  • “ai” is a trend label that adds little unless it describes a real, central feature.

What’s left is “budget” and “expense tracker”. That frees about half the field for accurate terms such as “bill reminder”, “savings goal” or “spending plan”, assuming the app really does those things.

Building a keyword set that survives review

The principle underneath every rule is simple: describe the app’s unique value to the user rather than chasing keywords. That doesn’t mean ignoring search volume. It means choosing terms in the right order.

  1. Start with what the app does. List the jobs a user hires it for, in their words.
  2. Group terms into clusters. A cluster is a set of phrases around one intent, such as “track spending” and “expense log”.
  3. Check ranking difficulty and relevance together. A term you can rank for but that doesn’t match your app will convert poorly and invite flags.
  4. Avoid repeating words across fields. Words in your name and subtitle are already indexed, so repeating them in the keyword field wastes characters.
  5. Write for installs, not just impressions. A relevant term that brings a user who installs and stays is worth more than a broad term that brings a bounce.

Evergreen phrasing also helps. Benefit-based metadata is less likely to be flagged during routine review updates than trend-based wording, and it needs fewer emergency edits.

Our perspective: treat compliance as part of ranking

Most teams file policy compliance under “legal” and keyword research under “growth”. We think that split causes the problem. A keyword that Apple strips is a keyword you never actually had, so it was never part of your ranking strategy in the first place.

In our experience building tools for app marketers, the most common pattern is not deliberate abuse. It is drift. A name gets a competitor term during a campaign, a price word slips into the keyword field for a promotion, and nobody reviews it again. Months later, visibility is down and the cause is buried in a field no customer can see.

That is why we built Apptenium around one view of your listing, your keyword positions, your competitors and your performance data. When you can see a cluster of rankings fall at the same moment you changed metadata, you diagnose in minutes instead of weeks. And when every scan produces copy-ready fixes, the compliant option is also the fastest one.

Our advice: schedule a metadata audit as a recurring task, the same way you schedule dependency updates. Keep a record of what each field said and when it changed. Compliance work compounds, because a clean, accurate listing is easier to improve than one patched over from several rushed releases.

— Mike

Check your listing with Apptenium

If you want a faster first pass, Apptenium’s scanner reads your listing metadata and returns AI-powered suggestions you can copy straight into App Store Connect. You can start with the free tools, including the scanner and word frequency analysis, which show you which words dominate your listing and where repetition is wasting space.

The Free plan includes a limited number of scans each month. The Pro plan is $9.99 per month and adds unlimited scans and premium features, along with keyword tracking, competitor intelligence and performance reporting. See the pricing page for the full comparison.

What about words users block on their own iPhones?

Some readers searching this topic mean something else: blocking words or sites on a personal device. That is a user-level setting and has no connection to App Store metadata rules. On an iPhone, Screen Time lets you restrict content under Content & Privacy Restrictions. According to Apple’s guide to blocking apps, downloads and websites, you can add specific website URLs to a Never Allow list under Web Content. Parents who want to manage a child’s device can start with Apple’s parental controls setup page.

Developers, note the distinction: you answer to App Review for what your listing says, while users decide what appears on their own devices.

Common mistakes that cost rankings

  • Treating the keyword field as private. Reviewers can see it, and it counts as metadata under the rules.
  • Copying a competitor’s keyword list. You inherit their risk and their positioning, and you may target terms that don’t fit your app.
  • Putting temporary promotions in permanent fields. “Free” in a launch week often stays for a year.
  • Ignoring the description. It doesn’t carry the same search weight as the name, but misleading claims there still fall under accurate-metadata rules.
  • Reading a rank drop as a market shift. Check for a policy cause first, then compare against rivals.

A simple release routine

Put this on your calendar and you will rarely think about banned terms again.

  1. Before each submission, run the audit checklist above.
  2. After each release goes live, record keyword positions for your top terms.
  3. One and two weeks later, compare. Investigate any cluster that dropped together.
  4. Each quarter, review competitors’ positioning to find fresh generic phrases, using a competitor intelligence view rather than copying their names.

FAQ

Does Apple publish a list of forbidden keywords for apps?

No. Apple publishes the App Review Guidelines, and Guideline 2.3.7 describes categories to avoid: trademarked terms, popular app names, pricing information and irrelevant phrases. Whether a specific word is a problem depends on whether it accurately describes your app and belongs to you.

Can I use a competitor’s name as a keyword?

No. Popular app names are called out in Guideline 2.3.7, and competitor names are a common trigger for review flags. Use competitor research to find the generic phrases they rank for, then target those phrases instead.

Why did my app lose rankings without a rejection?

Reviewers often remove non-compliant keywords instead of rejecting the build, so you may never get a notice. Check your name, subtitle and keyword field for brands, price words and platform references, and compare your keyword positions before and after your latest release.

Can I mention Android in my App Store description?

It is risky. Guideline 2.3.10 asks that metadata stay focused on the iOS experience, and Apple’s suggested alternative is a generic phrase such as “available on multiple platforms”. Remove platform names from every metadata field.

Sources

← Back to Guides · Home