Direct answer
The App Store title and subtitle work as one 60-character message unit, not two separate fields. The title (up to 30 characters) should carry the brand name plus the single strongest keyword phrase that describes what the app does. The subtitle (also 30 characters) should extend that promise with a second keyword angle or the clearest benefit statement, without repeating words already used in the title β Apple indexes both fields, and repeated words waste indexable space. Teams get this wrong when they treat the subtitle as a slogan, when they stuff unrelated keywords into the title, or when the title promise and the first screenshot argue for different things. A release-ready title and subtitle should read naturally, survive truncation in search results, and hand off cleanly to the keyword field and screenshot narrative.
What each field is responsible for
| Field | Character limit | Primary job | Common mistake |
|---|---|---|---|
| Title | 30 | Brand + strongest category keyword | Keyword stuffing that reads like spam |
| Subtitle | 30 | Second keyword angle or core benefit | Brand slogan with zero search value |
| Keyword field | 100 | Everything that did not fit above | Repeating title and subtitle words |
Recommended flow
1. Decide the one keyword phrase the title must own
Pick the phrase with the best balance of search volume and relevance to what the app actually does. If the app is a habit tracker, "habit tracker" belongs in the title; long-tail variants belong in the subtitle or keyword field.
2. Write the subtitle as a keyword-bearing benefit
The subtitle should answer "what do I get?" while carrying a second search phrase. "Daily routines that stick" carries meaning but no search value; "Daily habit & routine planner" carries both.
3. Remove every duplicated word across the two fields
Apple indexes title and subtitle words once. A word repeated across fields is a wasted slot that could have carried a new query. Audit the pair as one string.
4. Check truncation and readability
Search result cards truncate long titles. Front-load meaning so the first 20 characters still make sense alone, and read the pair aloud β if it sounds like a keyword list, conversion suffers even when ranking improves.
5. Align with the first screenshot before locking
The title makes a promise; the first screenshot must prove that same promise. If the title says "budget planner" and the hook screenshot leads with "track subscriptions", the listing splits into two arguments.
Common failure modes
The subtitle is a slogan
"Your life, organized beautifully" reads well in a brand deck and does nothing in search. Slogans belong in screenshots or the description, not in one of only two indexable 30-character fields.
The title changes every release without a reason
Title changes reset user recognition and can disturb existing keyword rankings. Change the title when positioning changes, not because a stakeholder wanted variety.
English and Chinese titles carry different promises
Bilingual listings often localize the words but not the strategy. Both language versions should own the equivalent keyword phrase and lead with the same value hierarchy.
Title and subtitle review checklist
- Title contains the brand plus one primary keyword phrase, within 30 characters.
- Subtitle adds a second keyword angle or concrete benefit, within 30 characters.
- No word appears in both fields.
- The first 20 characters of the title survive truncation with meaning intact.
- The first screenshot proves the same promise the title makes.
- Localized versions carry the same strategy, not just translated words.
Operating rule
If you cannot explain which search query the title targets, which query the subtitle targets, and why no word repeats between them, the pair is not ready to ship.
Why this matters in App Store Helper
App Store Helper drafts title and subtitle candidates from the same project positioning that drives keywords, description, and screenshot copy, so the 60-character message unit stays consistent with the rest of the listing. Character limits, duplicate-word checks, and bilingual parity live in one review surface instead of a spreadsheet.