App Store Metadata for Indie Devs: Title, Subtitle, Keywords

The three App Store metadata fields that actually decide whether anyone finds your app are the title (30 characters, strongest ranking weight), the subtitle (30 characters, second strongest), and the hidden keyword field (100 characters, medium weight) [1][3]. Get these three right and your app becomes searchable for the queries that matter. Get them wrong and you're invisible, no matter how good the product is.

Most metadata guides are written for marketing teams at studios with AppTweak dashboards and a full ASO manager. This one is for the solo developer staring at App Store Connect for the first time, with nothing but a free keyword tool and a submission deadline.

Why do these three fields decide discoverability?
How should you format your app title?
What belongs in the 30-character subtitle?
How do you pack the 100-character keyword field?
What about promotional text and the description?
What 2026 changes should indie devs know about?
What is the indie dev metadata workflow?

Why do these three fields decide discoverability?

Apple's search algorithm runs in two phases. Phase one is eligibility: can your app even appear for a given query? The answer comes from scanning your title, subtitle, and keyword field. If the search term does not exist (or cannot be formed) from words in those three fields, your app is invisible for that query.

Phase two is ranking: among all eligible apps, where do you sit? That is decided by downloads, conversion rate, reviews, and retention. But phase two only matters if you pass phase one. You cannot rank for a keyword you are not eligible for.

Here is the part most indie devs miss: Apple does not index your long description for search. Not a word of it. You can write 4,000 characters of beautiful copy and it will do exactly nothing for your rankings [1]. Your entire search surface lives in 160 characters: 30 + 30 + 100. That is why metadata optimization is the highest-leverage thing a solo developer can do, and why getting it wrong is so costly.

The App Store ranking factors guide covers the full hierarchy of signals including velocity and reviews. This post focuses on the three text fields you fully control.

How should you format your app title?

You have 30 characters for the app name [1]. Words here carry the strongest ranking weight of any metadata field [3]. Every character counts.

The most common mistake is burning all 30 characters on the brand name alone. If you are not a household name, "FocusFlow" by itself is wasted space. Use this format instead:

BrandName: Primary Keyword

Good: FocusFlow: Pomodoro Timer (25 characters)
Good: Sprout: Plant Care Reminders (28 characters)
Bad: FocusFlow (9 characters, 21 wasted)
Bad: FocusFlow Productivity App (the word "app" is a banned keyword anyway)

Rules Apple actually enforces [1]:

Maximum 30 characters including spaces and punctuation
No prices and no promotional copy ("Free", "Best", "New")
No category names ("Productivity", "Games")
No emojis or trademarks you do not own
First-come, first-served: Apple rejects duplicate names

The keyword you place at the very start of your title carries slightly more weight than the rest [3]. If you had to choose between FocusFlow: Pomodoro Timer and Pomodoro Timer by FocusFlow, the second version is technically stronger for the "pomodoro timer" query. Most developers pick brand-first for readability, which is the right tradeoff for conversion. Just know you are making the choice.

One more thing: punctuation matters. Apple treats a colon or dash as a keyword separator. FocusFlow: Pomodoro Timer indexes as three distinct words that Apple can recombine into phrases. Without the punctuation, some tools report slightly weaker phrase assembly. Keep the colon.

What belongs in the 30-character subtitle?

The subtitle is another 30 characters and carries the second strongest ranking weight after the title [3]. It appears directly below your app name in search results, which means it does double duty: it is both a search input to the algorithm and a conversion element for humans scanning results.

The winning formula: high-volume keywords the title could not fit, phrased as a readable mini-sentence. Think "what your app does, for whom" in the shortest possible form.

Good subtitles pulled from apps that rank [3]:

Duolingo: Learn Languages, Math & Music
Tripadvisor: Hotels, Restaurants, Tours
PayPal: Savings, cash back, pay later

Bad subtitles (and why):

The best productivity app ever (zero keywords with search volume)
#1 habit tracker in the world ("#1" and "world" are unsearchable)
The only app you'll ever need (every word is filler)

All three bad examples share one problem. They contain no words anyone actually types into the search bar. That is 30 characters of pure waste on prime real estate.

Subtitle rules [3]:

30-character maximum, spaces and punctuation count
Do not repeat words already in your title
Do not use competitor names or trademarks
No promotional language ("Free", "On Sale")
Readable English mini-sentences outperform comma-separated keyword lists in most cases

The Free Subtitle Optimizer drafts keyword-rich subtitles that stay inside the 30-character budget. For character-accurate counting that matches how App Store Connect counts bytes (especially with special characters), the Free Character Counter is faster than Xcode.

How do you pack the 100-character keyword field?

The hidden keyword field is where indie devs leave the most performance on the table. You get 100 characters, users never see them, and Apple uses them as the third input that determines which search queries your app is eligible for [2].

The strict formatting rules [2]:

Separate with commas, no spaces. Write tracker,habit,daily,goal,routine not tracker, habit, daily. Every trailing space is a wasted character.
Single words only, not phrases. Apple automatically combines individual words from your title, subtitle, and keyword field to form multi-word search phrases. habit,tracker with "daily" in the subtitle generates "habit tracker", "daily habit", "daily habit tracker", and other permutations automatically.
Never repeat words already in your title or subtitle. Apple already indexes those fields. Repeating a word wastes characters without adding a single new eligibility.
Skip plurals in English. Apple automatically ranks you for the plural when you use the singular. "tracker" covers "trackers" for free.
Skip "app", "free", category names, articles, and prepositions. All banned or redundant [2].
No special characters. Dashes, ampersands, and periods get replaced with spaces during indexing, which breaks your word count.

Here is a worked example for a habit tracker app:

Title: Sprout: Daily Habit Tracker (27 chars)
Subtitle: Build routines, reach goals (27 chars)
Keyword field: streak,morning,productivity,wellness,mindful,journal,reminder,planner,adhd,discipline (86 chars)

Words already used in the title and subtitle ("sprout", "daily", "habit", "tracker", "build", "routines", "reach", "goals") are deliberately absent from the keyword field. The 86 characters of the keyword field expand eligibility to dozens of new search phrases: "daily productivity", "morning journal", "adhd planner", "habit streak", and so on. Apple assembles the phrases automatically.

Notice the keyword field prioritizes moderate-volume expansion terms the title and subtitle could not afford. A weak keyword field is full of words already present in the metadata. A strong one is a set of non-redundant additions.

The Free Keyword Researcher returns search volume and difficulty scores for any seed keyword, which is how you identify which expansions are worth the characters.

What about promotional text and the description?

These two fields matter for conversion, not for search ranking. Most indie devs get this backwards.

Promotional text (170 characters) appears at the top of your description. It is the one field you can update without submitting a new app version, which makes it the right place for seasonal messages, event announcements, and A/B tested value props [1]. Promotional text is not indexed for search, so do not waste it on keywords. Use it to speak directly to the user: "New this month: daily streak challenges" or "30-day money-back guarantee".

The full description (4,000 characters) is also not indexed by Apple's search algorithm. This catches every developer coming over from Google Play, where the description IS the primary keyword surface. On iOS, your description exists purely to convert users who are already looking at your product page. Write for persuasion, not for keyword density.

If you're shipping cross-platform, the play store vs app store differences guide covers how the two description fields work on opposite principles and what that means for your copy strategy.

The practical split:

Title, subtitle, keyword field: Write for the algorithm.
Promotional text and description: Write for the reader.

Blur the two jobs and both suffer.

What 2026 changes should indie devs know about?

Three shifts are worth tracking for anyone submitting metadata in 2026.

AI-generated tags from your metadata. Apple has been testing AI-generated category tags built from your app's existing metadata, including title, subtitle, keywords, description, and screenshots. These tags currently affect browse placements inside the App Store, not search rankings directly. The practical effect: sloppy metadata no longer just hurts your search visibility, it also hurts the algorithm's ability to categorize your app correctly for discovery surfaces. Every field you leave weak is one more signal the system cannot read.

Screenshot text is now part of your metadata surface. Since the 2025 algorithm update, Apple's OCR reads text in your screenshots and uses it as a discovery signal that reinforces your primary metadata. The screenshot SEO keyword strategy guide covers exactly how to align screenshot captions with your title and subtitle keywords. The short version: pick 3 to 5 core keywords and repeat them across the title, subtitle, first-screenshot caption, and (carefully) the keyword field.

Localization multiplies your keyword budget. Each App Store localization gives you a fresh 30 + 30 + 100 character allocation. If you only ship English (US) metadata, you're leaving dozens of additional keyword slots unused. English (UK) is the cheapest second locale: different enough that you can target new keywords, close enough that you rarely need translation work.

What is the indie dev metadata workflow?

Here is the step-by-step process that works without an enterprise ASO tool:

Step 1: Pull 20 to 30 candidate keywords. Start with App Store autocomplete (type each idea into the search bar and note every suggestion) and competitor titles in your category. The Free Keyword Researcher returns search volume and difficulty scores for each candidate. Aim for terms with volume above 20 and difficulty under 60.

Step 2: Rank candidates by winnability. For each keyword, estimate traffic potential (search volume x your expected CTR). Drop anything where the top three results are Meta, Google, or Apple first-party apps. You will not outrank them.

Step 3: Assign keywords to fields by weight.

Title (30 chars): your one or two highest-volume winnable keywords plus brand
Subtitle (30 chars): two or three secondary keywords phrased as a readable mini-sentence
Keyword field (100 chars): every remaining non-redundant expansion, comma-separated, no spaces

Step 4: Draft, then character-count. Apple counts spaces and punctuation toward your limit. Use the Free Character Counter to verify every field fits before you paste into App Store Connect. Getting rejected for a 31-character subtitle because you forgot a trailing space is the most preventable waste of time in the submission flow.

Step 5: Submit, wait, measure. Metadata changes only apply on your next version submission. Track your rank for each target keyword weekly for the first month. Drop whatever did not move and reallocate those characters in the next update.

Step 6: Update every 90 days. The App Store is not static. Competitors shift. New apps enter your category. Review your metadata quarterly and rotate in keywords from the candidates you dropped in step 2.

Most indie devs skip steps 5 and 6 entirely. They treat metadata like a submit-and-forget task, then wonder why their ranks erode over the following year. The developers who compound their ASO wins are the ones who show up every 90 days and make small, deliberate changes.

Ship Metadata That Actually Converts

Metadata decides whether anyone finds your app. Screenshots decide whether they tap "Get" once they do.

The math is simple. A beautiful app with sloppy metadata is invisible. A visible app with sloppy screenshots is a traffic leak. Both problems need to be solved before you see meaningful downloads, and both are fully within your control on day one of the launch.

AppScreenshotStudio generates finished screenshot sets that match the tone of your metadata. You describe what the app does, we produce App Store-compliant screenshots with captions aligned to your target keywords. No design decisions required, and no wasted conversion on the part of the funnel that metadata alone cannot fix.