The App Store keyword field: 100 characters without waste

Of all the fields in App Store Connect, the keyword field gets the least attention. Nobody sees it on the product page, it never comes up in a design review, and it is usually typed in late at night before the first submission by whoever has the login. Then it stays exactly like that for two years.

That is a shame, because it is one of the few places where you tell the App Store directly which searches you want to appear in. It is also small. You get 100 characters, and the keyword strings I inherit from new clients often spend most of them on words that do nothing. What follows is the routine I use to fix that: what Apple actually says, the habits I add on top, and a worked example with the arithmetic shown.

What Apple says, at the time of writing

Apple's guidance sits in two places: the product page section of its developer site and the App Store Connect help on version information. Read together, they say this:

• The field holds 100 characters. The App Store Connect help phrases the limit as 100 bytes, which changes nothing for plain English letters and may matter for accented or non-Latin scripts.
• Separate terms with commas and put no spaces before or after them. Spaces inside a phrase are fine; Apple's own example is Property,House,Real Estate.
• Your app name and company name are already searchable, so repeating them in the list wastes space.
• Skip plurals of words you already have in singular form, category names, the word "app", duplicate words, and special characters such as # or @ unless they belong to your brand.
• Don't use trademarked terms, celebrity names, competing app names or terms that aren't relevant to the app. App Review Guideline 2.3.7 says the same about metadata in general, and Apple calls improper keyword use a common reason for rejection.
• Promotional text doesn't affect search ranking, so keywords placed there achieve nothing.

One practical detail matters more than it looks. Keywords belong to the app version, so unlike promotional text, which you can edit whenever you like, a new keyword string only goes live with your next submission. Every change is slow to ship and slower to measure. That alone is a good reason to get the string right on paper before it goes anywhere near a build.

The habits I add on top

Apple doesn't document how its search engine combines words, so everything in this section is a working assumption. Most ASO practitioners I know work this way, and so do I, but none of it is a store rule.

Write single words, not phrases

The store appears to match words across the name, subtitle and keyword field, so two separate entries can do the job of a phrase. Look at the cost: bedtime story and bedtime,story are both 13 characters. Splitting the phrase costs nothing, and it leaves each word free to combine with words elsewhere in your metadata. I only keep a phrase when the words make no sense apart.

Treat the subtitle like the name

Apple's help names only the app name and company name as already searchable. ASO people generally assume the subtitle is indexed as well, and I write keyword strings on that assumption. If a word is in your subtitle, it doesn't go in the keyword field.

Pick one form of each word

Apple's guidance tells you to drop plurals when the singular is already there. I default to the singular, keep it consistent across the string, and spend the saved characters on a new word. The same thinking applies to near duplicates such as "relax" and "relaxing": choose one.

Leave rivals out, including the clever versions

Misspelling a competitor's name to sneak it in is still using it, and so is a rival's trademarked feature name. It is the fastest way I know to turn a routine update into a rejection. The harder cases are ordinary words that are also the name of a large app in your category. That is a judgment call for whoever owns the legal risk, and I would rather flag it than make it quietly for a client.

A worked example: a fictional meditation app

Hushbay is invented for this piece. It is a meditation and sleep app in the Health & Fitness category, published by Hushbay Labs. Apple allows 30 characters each for the name and the subtitle. Hushbay's name is Hushbay: Meditation & Sleep (27 characters) and its subtitle is Guided breathing for anxiety (28 characters). Here is the keyword string it shipped with:

meditation, sleep, anxiety, breathing, bedtime story, bedtime stories, health, app, stillpond, relax

That is exactly 100 characters. App Store Connect accepts it without complaint, which is part of the problem: a full field looks like a finished field. Stillpond, for the record, is the invented name of a rival app.

So 81 of the 100 characters add nothing, and one entry could get the update rejected. The remaining 19 characters bring in three new words: bedtime, story and relax. Here is the rewrite:

mindfulness,relax,stress,insomnia,nap,focus,mantra,bedtime,story,rain,noise,body,scan,yoga,nidra,zen

Also 100 characters, but now 16 distinct words, none of them repeated from the name or subtitle. Combined with the name and subtitle, the listing can now plausibly match searches such as "sleep story", "rain sleep", "breathing for stress" or "body scan meditation", on the assumption about combining words above.

Where did those words come from? Not from a brainstorm. I would pull them from three sources: the words users write in reviews and support emails, the app's own content (it has body scan and yoga nidra sessions, so those terms are honest), and the keyword suggestions in Apple Search Ads, which come with a rough popularity indicator. Apple's own guidance points at the trade-off you then face: a popular term like "meditation" brings traffic but fierce competition, while a narrower term like "nidra" is searched less but is easier to rank for. A young app usually does better collecting the narrow terms first.

If you struggle to pick ten words that describe the app at all, the keyword field is not where the problem is. That is a positioning question, and our guide to finding the angle before you promote an app is a better place to start.

Localization: more fields, not free ones

Every localization you add has its own keyword field, along with its own name and subtitle. That is real extra room, but only if you write for the people who will read and search in that language. Translating the English list word by word rarely works.

I run into this constantly with Portuguese. Portugal and Brazil are separate App Store localizations, and the vocabulary drifts: people in Portugal write "insónia", people in Brazil write "insônia", and one Portuguese list pasted into both serves one of them badly. Accented letters are also where the bytes wording in Apple's help might start to matter, so check the counter App Store Connect shows you rather than trusting a plain character count from a text editor.

You will also read confident claims that adding one particular extra localization gives you a hidden second keyword field in a big storefront. Apple doesn't publish how localizations feed search in each country, so I treat those claims as hypotheses to test carefully, not as rules. And I never add a language to a product page that the app itself doesn't speak.

Before you submit: a checklist

1. Paste the name, subtitle and keyword string into the ASO character counter and confirm the keyword field is at 100 characters or fewer, with no word repeated across the three fields.
2. Search the string for a comma followed by a space and delete every one of those spaces.
3. Strike out every word that appears in the app name, subtitle, developer name or category.
4. Remove plurals where the singular is already present, and near duplicates where one form will do.
5. Read each entry and ask whether someone who types it would actually want this app. If not, cut it, because irrelevant terms are both prohibited and pointless.
6. Check for brand names, including misspellings, rivals' feature names and celebrity names.
7. Write the final string, the version number and the date into a log before you press submit.

That last step is the one most teams skip, and it is the one that pays off later. Because keywords ship with versions, you get one change per release at best, and the effect shows up in rankings over weeks, not days. I change a part of the string at a time, never all of it, so I can tell afterwards which words moved anything. There is more on store listings in the app marketing and ASO track.

Keep that log in a plain text file next to your release notes, one line per version. The next time someone asks why the app ranks for "rain" but not for "sleep sounds", you will have an answer with a date on it.