Apple’s own two pages disagree about the keyword field

The keyword field is the strangest thing on an App Store listing. It is the only metadata you write that no user will ever see, it is smaller than a single tweet, and almost everything written about it online has no source.

So this post separates three piles: what Apple documents, what this site measured against the live API, and what circulates as received wisdom with nothing behind it. The first pile is smaller than you would expect and more specific than you would expect.

What Apple documents

Two Apple pages carry nearly all of it, and both were fetched for this post.

App Store Connect's platform version information reference gives the size:

"You can provide up to 100 bytes of content."

Apple's App Store search page gives it differently:

"Keywords are limited to 100 characters total, with terms separated by commas and no spaces."

Bytes on one page, characters on the other. Both were fetched for this post on 20 August 2026, and both say what they say. This is not a distinction without a difference: in English a character is a byte and the two readings agree, but in Japanese, Greek or Arabic one character costs two, three or four bytes, and the two pages then describe fields of very different size.

Nothing public resolves it. Plan against the smaller reading — 100 bytes — and if you are writing for a non-Latin storefront, treat any character count above that as optimistic until the field saves without truncation. A source that states one of these as simply the answer has not read the other page.

That second quote settles a formatting question too. Terms are "separated by commas and no spaces", and Apple adds: "You can use spaces to separate words within keyword phrases. For example: Property,House,Real Estate." A space inside a phrase is legitimate. A space after a comma is the waste.

The same page gives the other caps: description "Limited to 4000 characters", promotional text "can't be longer than 170 characters", and What's New also limited to 4,000. Name and subtitle are 30 characters each, from the app information reference.

The search page gives the rest, and it is more explicit than its reputation suggests:

"Search results are based on a number of factors, including text relevance (matches for your app's title, subtitle, keywords, and primary category), as well as user behavior (downloads, ratings and reviews, and more)."

Four text fields named: title, subtitle, keywords, primary category. The description is not among them. Apple also says, on the same page, "Your primary category and optional secondary category are indexed by our search algorithm" — which makes the category a search decision as well as a browse one.

And this, which is usually presented as a community discovery:

"Don't repeat any words any words included in your app name, subtitle, or category."

That is Apple's own instruction, typo and all, on Apple's own page. The no-repeat rule is documented, not folklore.

Immediately after that sentence, Apple lists four things to avoid in order "to maximize the number of words that fit in this character limit". Three of them get traded as insider knowledge; the fourth is a formatting rule:

"Plurals of words you've already included, such as 'climbs' and 'climb,' as these are considered duplicates."

"Generic terms that are too broad for your app or category, such as 'app' or 'game.'"

"Filler words like 'the' and 'to,' as these don't add any additional value."

"Special characters, such as (such as # or @), unless they're part of your brand identity."

All four are documented. Apple publishes no exhaustive stop-word list and describes no stemming algorithm — but it names the plural and filler behaviours and gives an example of each, which is more than the folklore version of this advice usually carries.

The doubled "such as" in that last bullet is Apple's own, and it is the second duplication of that kind on the page — both confirmed in the raw markup, not only in a rendered copy.

Apple adds the intent behind keyword choice too: "Choose keywords based on words you think people may use to find an app like yours." And one clean negative, rarer than it sounds: "promotional text doesn't affect your app's search ranking so it should not be used to display keywords."

What nobody can do, including this site

You cannot read a competitor's keyword field. Not with a tool, not with a scrape, not with a clever inference.

Apple's public iTunes API does not expose it, and this is worth being precise about because "not exposed" and "empty" are different claims. Re-verified for this post on 20 August 2026, directly against itunes.apple.com on both the lookup and search endpoints:

• Four named apps checked individually; the two endpoints returned identical key sets for each.
• A broader sample of 133 app objects across six search terms.
• Every object carried either 43 or 44 keys — 43 universal, plus an optional sellerUrl present on 115 of the 133.
• subtitle, keywords and promotionalText appeared in none of them. Not as empty strings: the keys do not exist.
• A raw-body scan for those names as JSON keys returned zero hits. (A naive substring search does hit "subtitle" and "promotional" — inside description and release-notes prose, in apps that mention subtitles as a feature or promotional terms in subscription boilerplate. Those are false positives, and worth knowing about if you ever run the check yourself.)

The consequence is worth stating plainly, because products are sold on the opposite claim: any tool that offers you a competitor's keyword field is showing you a guess. What is genuinely observable is which searches an app appears in, which is a different and more honest measurement — that is what a rank check does.

For the same reason, Appstro's listing kit starts those three fields blank behind a "not available from the public API" badge rather than prefilling them from the description. An invented subtitle is worse than an empty box.

The mechanical rules, which are arithmetic

Some of the field's rules are not judgement calls at all. They are ways of spending the field on nothing.

Spaces after commas. note,todo,list and note, todo, list index identically. The second spends two extra characters on whitespace, and over a dozen commas that is more than a tenth of the field gone. Spaces within a phrase are a different thing and are explicitly allowed — Apple's own example is Property,House,Real Estate.

Repeated words. Apple indexes a term once. A field containing photo,photo editor,photo filter pays for "photo" three times and is indexed for it once. The same applies across fields, per Apple's own no-repeat instruction — a word already in your name or subtitle does not need repeating here.

Empty slots. A trailing comma, a leading comma, or ,, each spends a character and indexes nothing.

Special characters. A # or an @ spends a character and buys nothing, and Apple names them in the same avoid-list. The exception it allows is a character that is genuinely part of your brand.

Other companies' brands. Do not put them in. Apple rejects for it, and this is the one mechanical-sounding rule that is really a review risk.

These are the checks Appstro validates, and it validates only these — plus the caps themselves. Whether your keywords are the right keywords is not something a character counter can know, and a score that pretended otherwise would only teach people to write for the checker. The keyword density counter does the same narrow job for a description: it counts, it does not grade.

What is folklore

A first draft of this post listed plurals and filler words here. That was wrong, and it is worth saying so rather than quietly deleting it: Apple documents both, on the search page quoted above. If you have read elsewhere that plural handling is unknowable, check that page.

What genuinely is not documented on any Apple page fetched for this post:

• A complete stop-word list. Apple names "the" and "to" as examples of filler. It does not publish the full set.
• The stemming rules. Apple says plurals of an already-included word count as duplicates. It does not say how word forms are matched in general, so "climbs/climb" is the extent of it.
• Field weighting. The claim that the name outranks the subtitle which outranks the keyword field is practitioner consensus, and it may well be right. Apple says only that these are among the factors — not their order or their weights.
• Search volume. There is no public App Store search-volume figure, from Apple or anyone else. Nobody being honest about the App Store sells you one. What Apple's autocomplete does provide is an ordering of suggestions, which is a proxy for relative popularity and not a volume — Appstro's keyword research uses it that way, and returns nothing rather than a mid-range guess when a term never appears.

Labelling these as folklore is not the same as saying they are wrong. It means that if you build a strategy on them, you are building on practice, not on documentation, and you should know which one you are standing on.

What this cannot tell you

• Not which of Apple's two figures governs the field. Bytes and characters both appear on Apple's own pages. Plan against the smaller.
• Not how many people search a term. No source has this.
• Not what a competitor put in their field. See above; the data does not exist publicly.
• Not whether a change will move your rank. Apple names the factors, never the function. Rank movement after an edit is an observation, not an attribution.
• Not whether your keywords match what people mean. A field can be mechanically perfect and semantically useless.

The work

Get the mechanical waste out first, because it is free: strip the spaces, remove words already in your name and subtitle, drop the duplicate stems, kill the stray commas. Then spend what you recovered on a term you have actually seen in Apple's own autocomplete, and check where you rank for it before and after. Everything else on this page is someone's opinion, including some of Apple's.