How to Write an App Name, Subtitle, and Keyword Field That Work Together

The App Store does not rank an app because its keyword field is full. It tries to return a relevant result for a real search.

That makes the central job of keyword optimization surprisingly simple to state:

Describe the right product, for the right person, in the language that person is likely to search—without promising something the app cannot deliver.

Apple says search results use text relevance from the app title, subtitle, keywords, and primary category, together with user behavior such as downloads, ratings, and reviews. It also shows names, subtitles, ratings, and up to three screenshots or previews in search results. Metadata can earn eligibility, but the visible result still has to earn the download.

This guide turns research into a coherent iOS metadata system. It does not promise a ranking, and it does not rely on undocumented tricks such as keyword-order weighting or screenshot-text indexing.

Start with a user and a job, not a keyword tool

Write one sentence before collecting terms:

This app helps [specific user] achieve [specific outcome] by [credible mechanism].

A hydration app could serve athletes monitoring training, office workers who forget to drink, or people following a care plan. “Water” is related to all three; the intent, proof, and product requirements are not.

Build seed phrases from five angles:

The table is a starting point, not metadata. Its purpose is to prevent a tool’s suggestions from redefining the product.

Collect language from several evidence sources

No single source tells you what to target. Combine sources and preserve where every idea came from.

• App Store search suggestions and related results
• language in relevant competitors’ names, subtitles, screenshots, and reviews
• your own support tickets, interviews, sales conversations, and reviews
• Apple Ads search terms from discovery traffic
• product analytics that reveal which features retained users actually use
• third-party popularity, competition, and rank estimates

Treat third-party metrics as estimates. A term repeated by activated users is a different kind of evidence from a generated synonym with a large score.

A practical working sheet includes:

Reject a term when the app would disappoint the person who searched it. Irrelevant traffic can increase impressions while weakening conversion and user quality.

Choose a focused intent cluster

Group candidates before comparing scores:

• Direct solution: the person knows the type of app they want.
• Problem: the person describes the pain, not the category.
• Outcome: the person searches for a desired result.
• Feature: the person needs a specific capability.
• Audience or context: the query includes a role, condition, event, or situation.
• Alternative: the person wants to replace an existing workflow.

Choose one primary cluster that the current product can own credibly. A second cluster can support it when both describe the same core job. Five disconnected clusters usually produce an unreadable name, generic screenshots, and weak relevance.

Popularity and competition matter only after relevance. A smaller, specific term can be more useful than a broad term that the app cannot plausibly win or convert. There is no universal popularity threshold or guaranteed rank position that makes a keyword “good.”

Give every metadata field a different job

Apple’s current search guidance identifies the title, subtitle, keyword field, and primary category as text-relevance inputs. Do not treat them as four copies of the same list.

App name: identity plus the clearest intent

The app name is visible in search results and on the product page. Apple currently limits it to 30 characters.

A useful name usually combines a recognizable identity with the clearest category, mechanism, or outcome the app can support. It should still sound like a product name when spoken aloud.

Weak:

Nova — AI Smart Powerful Tools

More specific:

Nova: Focus Timer

The second example is not automatically optimal. It is simply easier for a person and a search system to interpret. Do not attach a keyword phrase that misstates the product, copies a competitor’s mark, or turns the name into punctuation-heavy fragments.

Subtitle: add meaning the name does not contain

The subtitle is also limited to 30 characters. Use it to add the outcome, audience, or differentiator that the name could not carry.

If the name already says “Focus Timer,” repeating “Timer for Focus” spends visible space without adding a reason to choose the app. A subtitle such as “Plan deep-work sessions” adds mechanism and outcome.

Read the name and subtitle as one two-line message. It should be natural, accurate, and understandable without the private field.

Private keyword field: extend relevant coverage

Apple allows 100 characters total and tells developers to separate terms with commas and no spaces, except when a space is needed inside a phrase. Apple also recommends avoiding words already present in the app name, subtitle, or category; duplicate plurals; generic words; filler words; and special characters that are not part of the brand.

Use the field for relevant roots and combinations that do not fit naturally in visible metadata.

Before submission:

1. Combine the name, subtitle, category, and private field in one view.
2. Highlight repeated words and roots.
3. Remove competitor names, unauthorized trademarks, irrelevant terms, and unsupported claims.
4. Remove marginal words before sacrificing readability in the visible fields.
5. Validate the final character count and punctuation in App Store Connect.

Do not reorder the list because someone claims the first term receives a universal ranking bonus. Apple’s current search guidance does not document keyword-order weighting. Put important terms first if it helps your team review the field, but do not present the order as a proven algorithm rule.

Categories: choose accuracy, not a shortcut

The primary category is indexed and determines important browsing and filtering placements. Apple also indexes the secondary category. Choose the most accurate options for the product; selecting an irrelevant category can cause review problems and attract the wrong comparison set.

Games can choose the Games category and up to two subcategories. The ASO for games guide covers the additional game-specific discovery surfaces.

App Tags: review what Apple inferred

App Tags are currently supported in the United States. Apple says they are based on US English metadata, AI, and human curation, and may appear in search results and on the product page. Developers can deselect inaccurate tags in App Store Connect.

Tags are a reason to make the metadata specific and truthful. They are not a new field to stuff. Review them after a metadata change and remove tags that misrepresent the essential product qualities.

Promotional text and description: persuade accurately

Apple explicitly says promotional text does not affect search ranking. Use it and the description to explain the current product, proof, limitations, and timely changes—not to hide a keyword list.

Make the search result continue the promise

Search eligibility is only the first step. A person may see the name, subtitle, rating, icon, and up to three screenshots before opening the full page.

Check the result at thumbnail size:

• Does the name identify the product?
• Does the subtitle add a meaningful reason to care?
• Does the first screenshot show the outcome or mechanism the query implies?
• Can the installed app fulfill the promise quickly?

Do not copy the same phrase into every asset. Preserve the same user need. If the metadata targets “invoice scanner,” the screenshot should make capture and extraction evident, and onboarding should not begin with an unrelated collaboration pitch.

When one default page cannot serve distinct intents, use a custom product page for a genuinely different audience or use case. Apple now lets approved custom pages appear for assigned keywords, so each assignment should have a unique, relevant destination.

Localize research instead of multiplying keywords

Apple says users can search with localized keywords where the App Store supports that language, and the displayed localization can depend on storefront, device language, available localizations, and the primary language.

That does not justify a universal “10x your keywords” promise. Adding a localization creates responsibility for its name, subtitle, keyword field, screenshots, product experience, support, and measurement.

For each important market:

1. verify the product and support experience are ready;
2. research local phrasing and competitors;
3. have a native reviewer inspect the whole page;
4. record Apple’s display and fallback behavior;
5. measure acquisition and downstream quality by territory where possible.

Use the App Store localization guide for the full workflow.

Use Apple Ads as research, not proof of organic rank

Apple Ads discovery can reveal searches that triggered an ad. A relevant query that converts and activates can become a candidate for organic metadata or a dedicated custom page.

Keep the inference modest: paid search terms show paid demand and behavior under that campaign. They do not prove an organic ranking change.

A useful loop is:

1. isolate discovery traffic;
2. review the actual search terms;
3. exclude irrelevant terms;
4. move promising terms into controlled exact-match groups;
5. compare tap, download, activation, and purchase quality;
6. promote only credible terms into the metadata backlog.

The Apple Ads guide explains campaign structure, negatives, and measurement.

Measure a metadata iteration honestly

Capture the baseline before release:

• exact metadata and screenshots by localization
• version and release date
• relevant search visibility or rank observations
• product-page views and conversion
• source and territory mix
• downloads, ratings, and review themes
• activation, retention, trial, or purchase guardrails
• paid campaigns, featuring, pricing, product releases, and other confounders

Write the hypothesis before editing. For example:

Replacing a broad productivity phrase with “study timer” will improve relevance for exam-focused searches without reducing product-page conversion or first-session completion in US English traffic.

Change a coherent, limited cluster. If the name, subtitle, keywords, screenshots, pricing, and onboarding all change together, record the result as a combined release rather than crediting one word.

There is no universal number of days that makes a result valid. Use enough time to cover normal weekly patterns and enough relevant traffic to make the decision useful. Small apps should combine longer observation windows with qualitative review, not react to one day of movement.

Final metadata checklist

• One user and one primary search job are explicit.
• Every target term is relevant to the current product.
• Name and subtitle read naturally together.
• The private field extends rather than repeats visible metadata.
• Category and US App Tags accurately describe the app.
• Competitor brands and prohibited or misleading terms are absent.
• The first screenshots continue the search promise.
• Each localization has local evidence and a native review.
• The previous state, hypothesis, release date, and guardrails are saved.
• Unconfirmed algorithm claims are not treated as rules.

Primary references

• Apple: App Store search
• Apple: App information fields
• Apple: Manage App Tags
• Apple: Localize app information