What the App Store subtitle does, and the risk in changing it

What the subtitle is for

Apple’s own documentation describes the subtitle as intended to summarize your app in a concise phrase, and recommends using it — rather than the app name — to explain your app’s value in greater detail. It advises avoiding generic phrases like “world’s best app” in favor of naming actual features or typical uses (see Sources). Its character limit matches the title: 30 characters.

Apple’s search documentation also states that search results factor in “text relevance” — matches against your app’s title, subtitle, keywords, and primary category. In other words, the subtitle isn’t just descriptive copy; it’s a separate field that participates in search text matching alongside the title.

How ASO Lens scores subtitle length

ASO Lens’s scoring logic (src/core/scoring/rules/metadata.ts) scores subtitle length (counted by code point) with 20+ characters as full marks, 10–19 as partial, 1–9 as a lower partial score, and an empty subtitle as zero. That 20-character threshold isn’t something Apple states directly — it comes from a third-party ASO ranking-factors writeup (AppTweak) as its source, and is ASO Lens’s own heuristic. When the subtitle simply couldn’t be fetched (as opposed to genuinely being empty), that case is scored zero with no recommendation attached, since “unknown” and “missing” aren’t the same thing.

Should title and subtitle keywords overlap?

With 30 characters in the title and 30 more in the subtitle, you have 60 characters combined — and whether to repeat the same keyword in both, or split distinct terms across them to cover more ground, is a tradeoff without one universal answer. Here’s both sides, with what backs each.

• The case that duplication wastes space. ASO Lens’s keyword-coverage logic (src/core/keywords/coverage.ts) builds dictionary entries from the title, subtitle, and keywords field, then matches each tracked keyword against that dictionary. When the same term exists as a dictionary entry in both the title and the subtitle at equal length, the matching logic resolves the tie in the title’s favor (SOURCE_PRIORITY). That means a keyword already covered by the title gains no additional coverage credit from also appearing in the subtitle, under ASO Lens’s own coverage model. In that specific sense, the claim that duplication can waste limited character space is backed by the code. ASO Lens’s scoring also directly rewards having no overlapping non-generic keywords between title and subtitle — 5 points for zero overlap, fewer for one, zero for two or more — treating overlap itself as something to avoid.
• The case for favoring certainty. On the other hand, some reason that putting an important keyword in both fields hedges against unexpected differences in how the search algorithm actually weighs or displays each field — insurance against one field not matching the way you expect. Whether that insurance actually pays off is not something this codebase or the verified primary sources here confirm as of this writing. It’s presented here only as a line of reasoning, not a verified claim.

Separately, Apple’s search documentation states — in the context of the keywords field, not the title/subtitle pair specifically — not to repeat words already used in the app name, subtitle, or category inside the keywords field. That’s not a statement about title/subtitle overlap itself, but it is one concrete example of Apple’s own stated principle that repeating the same word across multiple metadata fields can be an inefficient use of limited character space.

Changing it carries a risk

Once a title or subtitle has been live long enough to accumulate ranking for the keywords it matches, that ranking is tied to the exact text currently in place. Changing the text can break matches for keywords you were already ranking for, putting some of that accumulated ranking at risk. ASO Lens treats this as more than a warning — it quantifies it.

The tracked-keyword risk calculation (src/core/keywords/titleSubtitleRisk.ts) counts how many currently-ranking tracked keywords (those within the top 200) are matched by coverage from the title or the subtitle. That count feeds a diagnosis signal (src/core/diagnosis/signals/creativeTesting.ts) that flags Title/Subtitle as the higher-risk surface to change. This signal fires when the product page has enough traffic and Page Download Rate (the rate at which product-page visitors go on to download) has room to improve — in that situation it points first at testing “creative” surfaces instead: screenshots, the app icon, and promotional text, which Apple’s Product Page Optimization can A/B test without a new build or review, unlike Title/Subtitle.

The practical read here: when the number of currently-ranking tracked keywords that depend on Title/Subtitle coverage is small (or zero), there’s less existing ranking tied to the current text, so a change carries comparatively less risk. When that number is large, more ranking is at stake — which is exactly when it makes sense to test the lower-risk creative surfaces first, and treat a Title/Subtitle change as a decision that deserves more caution.

Summary

The subtitle is a 30-character field, but Apple itself lists it as one of the fields search text relevance matches against. Overlapping it with the title is treated as wasteful by ASO Lens’s own coverage model and scoring, while a case for favoring certainty through duplication also exists — neither is a settled answer. And changing the title or subtitle is a decision with a real cost: it risks the ranking you’ve already built up. Checking how many tracked keywords currently depend on that text — and weighing the change against that number — is the reasoning this codebase actually supports.