The App Store keyword field: how to use all 100 characters
The keyword field is the least visible part of your App Store listing and one of the most important. Users never see it. It lives in App Store Connect, one field per localization, and it feeds Apple's search index directly. You get exactly 100 characters, and how you spend them decides which queries your app can even appear for.
Most of the field gets wasted the same way every time: spaces after commas, plural forms, words that are already in the app name, and filler like "the" and "app". This post covers the exact rules, then fills all 100 characters in one worked example, then shows the secondary-locale trick that gives you a second 100-character field for the same storefront.
What Apple actually indexes for search
On the App Store, only a handful of text fields feed keyword search ranking:
- App name — up to 30 characters. The strongest signal.
- Subtitle — up to 30 characters. The second-strongest signal, right under the name.
- Keyword field — up to 100 characters, hidden from users, the subject of this post.
Apple also picks up a few extras: in-app purchase display names, in-app event titles, and — since mid-2025 — text inside your screenshots via OCR. But the core three are name, subtitle, and the keyword field.
The description is not indexed for search on the App Store. You can write your target keyword ten times in the description and it changes nothing for ranking. (This is the opposite of Google Play, where the long description is indexed — one of the biggest differences between the two stores.) Which is why the 100-character keyword field carries so much weight: it's the only place to put ranking terms that don't fit in the 30-character name and 30-character subtitle.
The rules that decide what fits
Every rule here is about spending 100 characters well.
- Commas separate terms, and commas count. The field is 100 characters total, including the separators. Ten terms means nine commas eating nine of your characters.
- No space after the comma. Write
budget,tracker,expense, notbudget, tracker, expense. Each of those spaces after a comma is a wasted character that buys you nothing. - Spaces inside a phrase are allowed and still count. A multi-word term like
net worthis fine, but the space between the words counts toward your 100. - Use the singular. Apple matches the plural automatically. Add
trackerand you rank for "trackers" too. Writingtrackersjust spends an extra character for nothing. - Never repeat a word from your app name or subtitle. Apple already indexes those. There's no keyword density bonus for saying it twice — a repeated word is a wasted slot.
- Drop filler and "app". Words like "the", "a", "for", "with", and "app" carry no search value. "app" and your category name are matched for free, so don't spend characters on them.
- No competitor names or trademarks. Apple's review guideline 2.3.7 tells you to "assign keywords that accurately describe your app" and not to "pack any of your metadata with trademarked terms, popular app names, pricing information, or other irrelevant phrases just to game the system." Apple "may modify inappropriate keywords at any time." A competitor's brand in your keyword field is a metadata rejection waiting to happen.
You don't need spaces or capitalization to build phrases. Apple combines individual words across the name, subtitle, and keyword field into multi-word queries on its own. If "budget" is in your name and "planner" is in your keyword field, you have a shot at ranking for "budget planner" without ever writing that phrase. So the keyword field is a bag of single words, not a list of finished phrases.
A worked example: filling all 100 characters
Say you're shipping a habit tracker. Here's the listing:
- App name (≤30):
Streaks: Habit Tracker - Subtitle (≤30):
Build routines and goals daily
The name and subtitle already cover: streaks, habit, tracker, build, routines, goals, daily — plus "app" and your category, which are free. None of those words should appear in the keyword field. That leaves the field for everything else a habit-app searcher might type.
Here's a keyword field that lands on exactly 100 characters:
reminder,planner,checklist,journal,ritual,chore,productivity,motivation,discipline,self control,diet
Count it: eleven terms, ten commas, and one intra-phrase space in self control. That
adds up to 100 characters exactly — no room left, none wasted. Every term is a singular noun,
none repeats the name or subtitle, and there isn't a single space sitting after a comma. If you
had written reminders, planner, checklists with plurals and post-comma spaces, you'd
blow past the limit and index fewer real terms.
A quick way to check your own field: paste it into any character counter (App Store Connect shows the count live). If you're over 100, the terms past the limit simply don't get indexed — they're not truncated cleanly, they just fall off the end of your ranking signal.
The es-MX trick: a second 100 characters for the same storefront
A single storefront doesn't index only one locale. The US App Store indexes your English (US) keyword field and a secondary locale's keyword field in parallel. For the US, Spanish (Mexico) — es-MX — is the classic second slot. Fill the es-MX keyword field and those terms become searchable in the US store too.
Done right, this roughly doubles your indexable keyword space — from 100 characters to about 200 — for the same audience. The catch is that it only helps if the second field holds distinct terms. Two rules make this precise:
- Each word counts once. If a word appears in both the en-US and es-MX keyword fields, the duplicate does nothing. Copy-pasting the same list into es-MX buys you zero extra reach — it just burns the second field.
- Words are not combined across locales. Apple forms multi-word phrases within a single localization, not across two. So if "bus" lives only in en-US and "metro" only in es-MX, you can rank for each word but probably not for the phrase "metro bus".
The practical move: put your primary 100 in en-US, then fill es-MX with a completely different
set of single words — the terms you couldn't fit the first time. For the habit tracker above,
es-MX might carry gym,water intake,meditation,mindfulness,sleep,focus timer,calendar,progress,quit,streak counter
— none of which repeat the en-US field or the name and subtitle. Same storefront, twice the
indexable surface, no guideline risk because every term still honestly describes the app.
This holds beyond es-MX. A US storefront can index several parallel locales, so the same principle expands your semantic reach further — as long as each field stays distinct.
The five ways the field gets wasted
- Spaces after commas. The single most common leak. Ten of them is ten characters gone.
- Plurals. Apple matches them from the singular. The extra "s" is pure waste.
- Repeating the name and subtitle. No bonus, just a spent slot.
- Filler words and "app". Zero search value.
- Duplicating en-US into es-MX. Throws away a free second 100 characters.
Where this fits in the listing — and in Mokbi
The keyword field is one field in a listing that also needs a 30-character name, a 30-character subtitle, a description, a feature graphic, and screenshots — each one localized per store. Doing that by hand across even a few languages is where most of the time goes, and where the es-MX trick usually gets skipped because nobody wants to write a second keyword field from scratch.
Mokbi is a full store-listing publisher, not just a screenshot editor — screenshots are one step in a flow that runs Screenshots → Feature graphic → Store text → Translate → Publish. Its AI drafts the whole listing (title, subtitle, keywords, and description) from your app, then translates the entire listing into 50 languages. Because it writes and localizes the keyword field per storefront, the es-MX field gets filled with real, distinct terms instead of a copy-paste — the doubling actually happens instead of staying a footnote.
What to read next
- App subtitle vs promotional text
- Localizing your listing across App Store storefronts
- The pre-submit ASO checklist
Sources: Apple's App Store search and Review Guidelines (2.3.7) docs; aso.dev on cross-localization; and AppTweak's iOS keyword field guide.