App Store keywords: how to fill the keyword field

Which fields App Store search reads#

Apple says your app is searchable on the App Store by its name, subtitle, keywords and company name. Its App Store search page adds categories: results are based on a number of factors, including text relevance, which it defines as matches for your title, subtitle, keywords and primary category, and user behavior such as downloads, ratings and reviews. The same page says the primary and optional secondary categories are indexed.

What is missing matters too. Apple's list of searchable fields doesn't name the description: Apple says the description will be used for web engine search results once you release your app, which means search engines on the web. And the search page says promotional text doesn't affect your app's search ranking, so it should not be used to display keywords.

So the keyword field is for words that are true of the app but have no room, or no natural place, in the name and subtitle. For those two lines, see how to write the App Store title and subtitle.

Bytes or characters#

Apple's pages disagree on the unit. The App Store Connect reference says you can provide up to 100 bytes of content. Apple's search and product page guides say 100 characters. For plain English the two agree, because each unaccented letter, digit, comma and space takes one byte. In other scripts they part ways. Apple doesn't say which encoding it counts, or whether App Store Connect enforces bytes at all. The table shows what 100 bytes would hold in UTF-8; the field in App Store Connect is the final word.

An example in Japanese. This line for a habit tracker is 40 characters, well under 100: 習慣化,リマインダー,チェックリスト,ルーティン,目標管理,継続記録,セルフケア. In UTF-8 it is 108 bytes, 34 kana and kanji at 3 bytes each plus 6 commas at 1 byte, so if Apple counted UTF-8 bytes it would be 8 bytes over. Paste it into App Store Connect before you cut a term; if the field refuses it, dropping セルフケア (self care) brings it to 34 characters and 92 bytes. Every term here is at least three characters, because Apple describes keywords as each greater than two characters; Apple doesn't say how that applies to Japanese, where many words are two kanji.

Russian takes 2 UTF-8 bytes a letter: трекер привычек (habit tracker) is 15 characters and 29 bytes. Check every non-English localization in App Store Connect before you submit; if you can't, staying within 100 UTF-8 bytes is the safe side. The site's keyword field counter counts characters and adds a note when a line passes 100 UTF-8 bytes.

What to leave out of the field#

Apple's search page asks for terms separated by commas and no spaces, with spaces allowed inside a phrase. Its own example is Property,House,Real Estate. Together with the product page guide, it lists what wastes the field:

• A space after a comma. It costs a byte and adds no word.
• Words already in the app name, subtitle or category. Apple asks you not to repeat them, and its App Store Connect reference adds the company name.
• Plurals of words you already have. Apple's example is climb and climbs, which it calls duplicates.
• The word app, the word game, and names of categories.
• Filler words such as the and to.
• Special characters such as # or @, unless they are part of your brand. Apple says they don't carry extra weight.

Then come the terms Apple rejects. Its search page calls improper use of keywords a common reason for App Store rejections, and App Review Guideline 2.3.7 opens with the rule:

Apple's lists name unauthorized trademarked terms, celebrity names and other protected words; terms not relevant to the app; competing app names; and inappropriate or offensive terms. The App Store Connect reference puts the competitor rule plainly: names of other apps or companies aren't allowed. And Guideline 2.3.7 ends with a warning that Apple may modify inappropriate keywords at any time or take other steps to prevent abuse.

Two smaller points. The reference describes keywords as each greater than two characters, without saying what happens to a shorter one. And Apple doesn't document whether a two-word search matches when one word sits in the subtitle and the other in the keyword field. Once a version is live, search the phrase on an iPhone in that storefront and see whether the app appears. That is one place in one list at one time, not a rank on every phone.

Choosing the words without invented volumes#

Neither store publishes how many people search for a word, so any search count a tool shows is its own estimate. Collect candidates from what people already type and say instead:

1. Read your reviews. Copy the words people use for what the app does, in their words, not yours. A review that says the reminders keep it going gives you reminder.
2. Type into the store's search bar. Apple says search hints appear once someone types, and they can inspire a search. Type the start of each candidate on an iPhone set to the storefront you care about, and note the completions.
3. Read rivals' names and subtitles. They are public and searchable, so they show the words a category competes on. Take the generic words. Never take the names.
4. If you run Apple Ads, open its Search Terms tab: the search terms for which your own campaigns got impressions, taps and installs. A term with fewer than 10 impressions shows only as low volume. Apple Ads also scores search popularity on its own relative scales: 1 to 5 in the Apple Ads dashboard, and 1 to 100 in its API. Neither is a search count; search popularity explains the scales.
5. Filter the list. Keep a term only if it is true of the app, not already in the name, subtitle or category, and not the name of another app or company. Keep one form of each word.

Then weigh popular terms against specific ones. Apple frames the choice this way on its search page:

If your app is newer or smaller, Apple's own wording points toward the less common terms. A practical rule: when a broad word describes the app, put it in the name or subtitle, where shoppers read it too, and use the keyword field for the specific words around it.

Worked example: a habit tracker's keyword field#

An invented app, with invented evidence. Tallymoss is a habit tracker. It has a daily checklist, sends reminders, keeps streaks, has a Home Screen widget, charts progress, takes a one-line mood note, and tracks habits to quit as well as habits to build. Its English (U.S.) name is Tallymoss: Habit Tracker (24 characters) and its subtitle is Daily Routine & Goal Planner (28 characters).

In this example, reminder and widget come from reviews, todo and self care from the search hints, discipline and progress from rivals' subtitles, and chart from an Apple Ads search terms report. Each term is true of the app: the daily checklist works as a to-do list, and the mood note is a short journal. Streak is singular: Apple counts a plural of a word you already have as a duplicate, so one form is enough. Self care keeps its inner space because Apple allows spaces inside a phrase. The 9 spare bytes wait for the next true term on the list; a word that doesn't describe the app is not worth them.

The rewrite is not final. After it goes live, search the terms that matter most to you, and swap any the app never appears for with the next words on your list, one version at a time.

One field per localization, sometimes several per storefront#

Each localization has its own keyword field, and a new one does not start with yours: Apple says a new language takes the primary language's screenshots and properties, except the description and keywords. Apple explains how localized keywords are searched with French as its example:

Apple's localizations table lists the languages each country or region supports. The United States lists English (US) as its default and nine more, including Spanish (Mexico), Chinese (Simplified), Korean and Vietnamese. Japan lists Japanese and English (US). Switzerland lists German, plus English (U.K.), French and Italian.

By Apple's rule, then, an app on the U.S. store can be found through the keywords of each supported localization it has, not only English (U.S.). Two cautions before you treat a second localization as spare room. Each localization is also a listing people read: Apple says a localization displays to users whose language setting matches it, and the table makes Spanish (Mexico) the default language in Mexico, Argentina, Chile and Colombia. And Apple doesn't say how it weighs a match in a second language against one in the default language.

Write each localization for the people who read it, in their language, and check its count in App Store Connect. More in App Store localization.

Changing keywords, and custom product pages#

Keywords belong to an app version. Apple lists them among the platform version information, the properties of an app version, and when you create a new version the current version's metadata is copied to it. Apple's steps for a new version include uploading a new build and submitting it to App Review. So a keyword change ships with an app update.

Apple says App Review typically handles at least 50% of submissions in under 24 hours and 90% in under 48 hours. After an update, Apple says app information may take up to 24 hours to appear on the App Store. Note the day the new line is live, not the day you submitted it.

Custom product pages, up to 70 per app, can carry keywords too, with one limit: you assign them from your latest approved app version. A page with keywords appears in search for those terms in place of your default product page, once the page is approved and set to visible. In its WWDC25 session, Apple added that assigning keywords alone can go live without a new review.

Two rules follow. A term you want for a custom page must be among the version's keywords first, so plan the line with your pages in mind. And Apple recommends a unique set of keywords for each page, so two pages never compete for one term. See custom product pages for the rest.

What Apple doesn't tell you, and how to read a change#

Apple's pages leave out most of what you would want to measure:

• How terms are weighted. The search page names some of the factors, text relevance and user behavior, but gives no weights, and doesn't say whether a word counts for more in the name than in the keyword field.
• Which term brought a visit. In a WWDC26 lab, Apple confirmed that App Store Connect does not provide keyword-level data.
• How many people search for a term. App Store Connect shows no search counts, and Apple Ads gives only relative popularity: 1 to 5 in the Apple Ads dashboard, 1 to 100 in its API.
• The encoding behind the byte limit, and whether words in different fields combine into one search.

What you can read is App Store search as a source type in App Analytics: the impressions, product page views and downloads that came from search. It includes views and downloads from ads in search results, so a change in Apple Ads spend moves it too. To read a keyword change:

1. Write down the day the new line went live.
2. Take whole weeks before and after that day, so both windows hold the same weekdays.
3. Compare App Store search impressions and downloads, not total downloads.
4. Check whether browse traffic, ad spend or the season moved too.

This is a before-and-after read, not a controlled test: it says what followed, not why. A store test is not an option for this field: Apple's product page optimization tests visual assets such as the icon, screenshots and app previews, not keywords. If a term in your metadata doesn't show the app at all, see keyword in metadata not shown.

Where RocketASO fits#

RocketASO reads your App Store and Google Play reports, names the fix estimated to be worth most this week, and compares installs before and after it. It starts you with a draft of the copy or the keyword field, and nothing reaches the store until you approve it. Each read, at 7 and 14 days, is a before-and-after read, not a controlled test. To see where a public listing stands first, run the free ASO audit.