Direct answer
Apple's 100-character keyword field is the only listing surface users never see, which makes it pure index space β every character should carry a term that title and subtitle could not fit. The working rules are mechanical: separate terms with commas and no spaces, never repeat a word already present in the title or subtitle, skip plurals when the singular is covered, and drop free filler words like "app" and "free" that Apple already accounts for. Beyond mechanics, the field is a portfolio decision: it should hold the keyword-cluster variants and long-tail phrases from research, not leftover brainstorm words. Teams waste this field by duplicating visible metadata, by leaving it unchanged for a year, or by treating it as a dumping ground with no connection to what the listing actually promises.
Mechanical rules that free up characters
| Rule | Why | Example |
|---|---|---|
| Comma-separated, no spaces | Spaces after commas waste characters | budget,expense,tracker not budget, expense, tracker |
| No words from title/subtitle | Apple indexes those fields already | Title has "habit" β drop it from the field |
| Singular or plural, not both | Apple matches close variants | recipe covers recipes in most cases |
| Drop "app", "free", "iphone" | Apple adds or ignores these | Reclaim 4β10 characters instantly |
| Individual words over phrases | Apple combines words across the field | meal,plan can match "meal plan" and "plan meal" |
Recommended flow
1. Start from the keyword clusters, not a blank field
The field exists to catch cluster variants and long-tail terms that lost the fight for title and subtitle. If research produced clusters with owner fields, the keyword field's content is already implied.
2. Strip everything Apple already indexes
Concatenate title and subtitle, and delete every word that appears in them from the keyword draft. Then apply the mechanical rules above. Most teams recover 20β30 characters this way.
3. Spend recovered characters on new intents
Freed characters should carry query intents not yet represented: a use-case term, a problem phrase, a competitor category label. New intent beats a third variant of an existing one.
4. Localize the field per market, not per language
The keyword field is set per locale, and locales cross-pollinate in some storefronts. Research which locales feed which storefronts before assuming one Chinese field covers every Chinese-speaking market.
5. Review the field at every metadata change
Whenever title or subtitle changes, words move between indexed surfaces. A subtitle edit that adds "planner" means the keyword field should give that slot to something new.
Common failure modes
The field duplicates the visible metadata
The most common waste: brand name, title keywords, and subtitle phrases repeated where they earn nothing. The field's value is exactly the terms that are not visible elsewhere.
The field never changes
Rankings move, seasons change, features ship. A keyword field untouched for a year is a research budget spent once and never reinvested.
Nobody can say why a term is there
When the field is a fossil record of old brainstorms, review becomes impossible. Every term should trace back to a cluster, a competitor observation, or a measured query.
Keyword field checklist
- Comma-separated, no spaces, within 100 characters.
- Zero overlap with title and subtitle words.
- No "app", "free", "iphone", or duplicate singular/plural pairs.
- Every term traces back to a researched cluster or observed query.
- Each locale's field was built for its market, not machine-translated.
- The field was re-reviewed after the latest title or subtitle change.
Operating rule
If removing a term from the keyword field would change nothing you can name, the term is not earning its characters β replace it with an intent you are not yet covering.
Why this matters in App Store Helper
App Store Helper generates the keyword field from the same project that holds the title and subtitle, so overlap stripping and character budgeting happen against the live metadata rather than a copy in a spreadsheet. Bilingual projects keep each locale's field separately reviewable while sharing one keyword strategy.