How App Store search actually indexes your app
When a user types a query on the App Store, Apple searches a combined index built from three fields:
- App name (30 characters, per locale)
- Subtitle (30 characters, per locale)
- Keyword field (100 characters, per locale, not user-visible)
All three contribute to whether your app matches a search. The description is not indexed for search. It matters for conversion once a user reaches the product page, but adding a keyword to the description won't help you rank for that keyword. Apple confirmed this change with iOS 14 and has not reversed it since.
Ranking within the matched set depends on factors Apple doesn't publish, but at minimum: how closely the query matches your name/subtitle/keywords (exact matches in the name rank above exact matches in the keyword field), the historical conversion of your app for that query, the app's overall download velocity, and category signals.
Implication: the 100 characters in your keyword field work in concert with your name and subtitle. Treat them as one budget of about 160 characters (30 + 30 + 100) of total keyword space per locale, not three separate fields.
The three rules that matter
Rule 1: No spaces after commas
The keyword field is a 100-character budget, and every character counts — including spaces. Compare:
health, fitness, nutrition, workout, tracker (46 characters)
health,fitness,nutrition,workout,tracker (42 characters)
The second form frees up 4 characters. Across 10-12 keywords that compound into meaningful extra budget for additional terms. Strip spaces around every comma.
Rule 2: No plurals — Apple stems automatically
Apple's search index performs stemming, matching related word forms from a single
stored term. If your keyword field contains runner, users searching for
runners, running, and in most cases run will
match. Duplicating both the singular and plural (runner,runners) wastes
characters.
Same principle applies to most conjugations and inflections in English: include the base form only. This is less reliable in languages with heavier morphology (German, Russian, Finnish); for those locales you may need to include more forms, but test via App Store search suggestions to see what Apple groups together.
Rule 3: No duplicates with name or subtitle
Because Apple combines all three fields for indexing, a word that already appears in
your name or subtitle doesn't need to appear in the keyword field. If your app is
HabitTrack with subtitle Daily habit tracker for iPhone, adding
habit,tracker,daily,iphone to the keyword field is pure waste — those
tokens are already indexed from the name and subtitle.
Your 100 keyword-field characters should hold terms that are not in your name or subtitle: synonyms, adjacent concepts, niche variants, translations of key terms for bilingual storefronts, long-tail modifiers.
Partial matching and compound words
Apple's index handles some partial matching, but the behavior is inconsistent enough
that you shouldn't rely on it for key revenue-driving terms. For English compounds
(bookkeeping, sleeptracker, podcast), Apple's
search does not reliably split the compound into its components. If users search for
both book and bookkeeping and both matter, you need both in
your indexed fields.
For CJK languages (Chinese, Japanese, Korean) and other non-space-separated languages, Apple does tokenize internally — you don't need to add every possible character combination. The character density of CJK means 100 characters go dramatically further: a Chinese keyword field can cover what would take 300+ English characters.
Keyword localization is search-critical
Each locale has its own 100-character keyword field, and the keyword field of a given locale is used only when the user searches on that locale's storefront. French users on the fr-FR storefront see matches based on the fr-FR keyword field, not the en-US one.
Two consequences:
- Keywords that matter in your primary market need to be translated — or better, researched — in every locale you care about ranking in.
- You cannot rely on English keywords to work for non-English users. A French user searches in French.
Don't just translate. Translated keywords often miss the actual search terms users type, especially brand-adjacent or colloquial ones. A French-speaking user looking for a fitness app types sport or musculation, not aptitude physique. Research the locale's actual search terms — typing into the App Store on a French-configured device surfaces Apple's own autocomplete suggestions.
For apps that support both English and another language in the same market (for example, en-CA alongside fr-CA for Canada, or en-IN alongside hi-IN for India), fill the keyword field separately for each locale.
Keyword research without expensive tools
Paid ASO tools (Sensor Tower, AppFigures, MobileAction, data.ai) offer keyword difficulty scores and search volume estimates. They are useful at scale but not required for most apps. The free signals Apple gives you are:
App Store search suggestions
Open the App Store on an iPhone configured for the locale you care about. Type a seed term and observe the autocomplete suggestions. Apple's suggestions are ranked by actual search volume — the first suggestion is more searched than the fifth. Collect these for every seed term relevant to your app.
Repeat across multiple seed terms to build a picture of your locale's search
landscape. If sleep tracker suggests sleep tracker for apnea,
sleep tracker watch, sleep tracker free, those are volume
signals about what users type after the base term.
Competitor keyword analysis
Find the top 5 apps that show up for your target searches. Read their name, subtitle, and description carefully. Patterns you'll notice: which adjectives they lead with, which use cases they list, which features they emphasize. Their indexed fields are your competitive landscape.
AppConsul's keyword tools (Pro) and the free keyword field optimizer help structure this exercise: paste your current keyword field and your name and subtitle, and see which keywords are duplicated (waste) and which terms are missing from both fields.
Google Trends for category-level demand
For categories rather than specific terms, Google Trends (trends.google.com)
reveals seasonal patterns and regional intensity. If searches for tax
calculator spike in February through April in the US but September through
November in Australia, adjust your promotional text and keywords accordingly in
each locale.
Long-tail vs head-term strategy
Head terms are short, high-volume, high-competition (fitness, photo editor, todo list). Long-tail terms are longer, lower volume, much lower competition (sleep apnea tracker, receipt scanner for freelancers, habit tracker widget).
Which to target:
- New apps, small categories, lower budget: lean hard on long-tail. Ranking #1 for receipt scanner for freelancers drives real installs; being #47 for receipt scanner does not.
- Established apps with proven conversion: start pushing head terms. Your conversion rate and install velocity give you a ranking edge new apps can't match.
- Most apps most of the time: a mix. Lead the subtitle with a head term (Receipt scanner), pack the keyword field with long-tail modifiers (freelancer,expense,tax,mileage,invoice,category).
A worked example
Take a hypothetical iOS app: a sleep-tracking app that uses the iPhone's microphone to detect snoring, logs sleep stages, and exports data to Apple Health.
Bad keyword field (wastes characters on plurals and duplicates):
sleep, sleeps, tracker, trackers, snore, snoring,
apnea, health, sleeping, trackers, tracking (108 chars — over limit)
Better: assume the name is NightLog and subtitle is Sleep tracker
with snore detection. The name and subtitle already cover sleep,
tracker, and snore. The keyword field then needs to carry
adjacent and complementary terms:
apnea,cpap,snoring,insomnia,dream,rem,cycle,nap,
bedtime,wind down,alarm,white noise,breathing (94 chars)
This version assumes stemming handles snore vs snoring,
strips comma-spaces, avoids duplicating the name/subtitle terms, and adds 13 related
terms that extend reach into adjacent queries.
Monitoring what actually works
App Store Connect's Search panel under App Analytics shows queries users searched that led to your product page impression. This is directly attributable keyword data — which searches made your app appear, how many times, and how many people tapped through. Use it as ground truth over any third-party estimate.
If a term in your keyword field generates zero search impressions after 30 days, that term is either: too low volume, not matching users' actual search language, or matching a query where your app ranks so low it never appears. Swap it.
Conversely, if analytics surfaces a query you are ranking for but don't target (because the name or subtitle happens to match), consider reinforcing it.
What breaks the keyword field
- Competitor names. Using trademarked competitor app names in the keyword field triggers 2.3.7 rejections and, for registered marks, takedown requests.
- Price or ranking claims. "
free,best,top" — if you're clearly trying to rank for these as superlatives, reviewers can pull it. - Categories you don't belong to. "
game,rpg,puzzle" on a productivity app is misleading metadata (2.3.7). - Contact info or URLs. These don't work as keywords and waste characters.
- The word "app". Every app is an app. Searchers don't add "app" to their queries — they search for weather, not weather app. Don't burn characters on it.
Frequently asked questions
Does Apple index the description for search?
No, not since iOS 14. Name, subtitle, and keyword field only.
Spaces after commas?
No. Strip them. Spaces count against the 100-character budget.
Plurals?
No. Apple stems. Include the singular form only in most cases.
Words from my name or subtitle?
No. Apple combines all three fields for indexing — duplicating wastes characters.
Does the field work across locales?
Each locale has its own independent 100-character field, used only for that locale's storefront. Localize, don't share.
Does Apple break compound words?
Inconsistently in English, more reliably in CJK. Don't rely on it for key terms — include both forms if both are valuable.
Can I use competitor names?
No. Trademark violations trigger rejections or takedowns.
Keyword fields across every locale in one place.
AppConsul's metadata editor surfaces your name, subtitle, and keyword field side-by-side per locale with duplicate detection and live character counts, so the three-rule mistakes above never ship.
Try AppConsul →