Jump to a section
Leave with a decision
Produce a coherent app name, subtitle and supporting keyword draft.
Start with the visual explanation, work through the example, then try the exercise on your app.
Give each metadata field a job
A fictional listing sketch. Layout is schematic, not a store screenshot.
ReceiptNest
Name: identify the app and its core category clearly.
Track expenses together
Supporting copy: explain the relevant benefit without repeating the name.
Who it helps and how
Description: develop the promise with real capabilities and specific use cases.
Research record
Keep the reason for each chosen phrase outside the published listing.
Work through it · fictional example
Make the promise specific before counting characters.
Trail Notes uses “Your outdoor companion” as its fictional subtitle. That line could belong to a weather app, a map or a hiking journal.
Why this changes the decision
The proposed subtitle names an action and a context. It should work with the app name rather than repeat it. Check that saving photos is available in the released experience. Then review field length and candidate overlaps; the length checker is a production aid, not the author of the message.
What to check before calling it a win
Read the name, subtitle and first screenshot together. Ask a fresh reviewer what the app does and who it serves. If their answer is navigation, the surrounding creative may still contradict the revised subtitle.
Your turn · a five-minute start
Make one useful decision for your app.
Rewrite one vague line using a user action and its context. Record why you changed it in the comparator.
What a useful answer looks like
A stronger line names something the user can actually do. Avoid adding an unsupported outcome just to sound more exciting.
Give each field a job
The name identifies the app and its principal use case. The subtitle adds a useful reason to consider it. The description explains the experience, capabilities and important conditions. The hidden keyword field supports discovery; it is not a place to disguise unsupported features. Decide the message first, then fit it into the applicable fields. Space is a constraint, not a target to fill at any cost.
Draft from the user’s decision
Ask what someone needs to understand before downloading. For a paid or subscription experience, do not create an impression that every capability is immediately free. A concise explanation of the core workflow is often more helpful than a list of abstract adjectives. Compare your text against the current app, not a roadmap. Record claims that need product-owner confirmation before publication.
Change metadata without losing the evidence
Keep a record that survives the next person editing the listing.
Baseline
Save the live text, locale and date before making changes.
Draft
Write the new message and note the reason behind each field.
Validate
Check store limits, product accuracy, spelling and duplicated ideas.
Compare
Record the release date and review the intended metric with traffic context.
Check limits carefully
Use the metadata checker to count the draft and inspect the current App Store Connect reference before submitting. Apple’s keyword documentation uses both a character description and a byte limit; non-ASCII text can make those counts diverge. The checker shows both instead of treating every visible symbol as one guaranteed unit. Verify the final localized text in the console.
Keep metadata and screenshots coherent
A title promising fast logging should lead to screenshots that demonstrate fast logging. If the first asset presents an unrelated capability, the listing asks visitors to resolve the contradiction. Make a message map: use case, claim, proof in the product, supporting asset. That map also helps a designer or translator make consistent choices.
Prepare a controlled release
Save the old fields, proposed fields, reason for each change and the submission date. Check every locale and any custom pages affected. Coordinate with the release owner so a creative test is not accidentally mixed with unrelated changes. After release, verify the public listing and interpret movements in context rather than assuming every fluctuation was caused by the copy.
An illustrative metadata draft
For the fictional Trail Notes hiking journal, each field should have a job. The name identifies the product; the subtitle adds a reason to care; the keyword field holds relevant candidates after research and overlap checks.
| Field | Illustrative draft | Review question |
|---|---|---|
| App name | Trail Notes: Hiking Journal | Does the main use case remain clear? |
| Subtitle | Keep a private hiking diary | Is the privacy claim supported by the product? |
| Keyword candidates | walks,outdoors,memories,log | Are these relevant, researched and worth including? |
These are teaching drafts, not proven keywords or a recommendation to publish without research. Check the current field limits and count the final text with the metadata tool. A word fitting inside a field does not make it a good target.
Review the whole message before publishing
- Read the name, subtitle and first screenshot together. Do they describe the same product?
- Remove claims your released app cannot support.
- Keep a copy of the old fields and record why each material change was made.
- Assign an approver who understands the product before the console update.
Your next steps
- Write one sentence explaining the main use case.
- Assign a job to each field and remove unsupported claims.
- Run the checker and verify the applicable console rules.
- Save the before/after draft and its reasoning.
Sources and platform guidance
Platform documentation checked 29 September 2026. Verify the applicable console settings before publishing.
Questions and answers
Does a passing length check mean the copy is optimized?
No. It only means the checked size constraint passed. Relevance, clarity and product accuracy still need review.
Should I copy competitors’ wording?
Use competing listings to understand intent and alternatives. Write an accurate, original explanation of your own product.
Work directly with Gabriel
Turn the keyword list into an actual listing.
Work directly with me on relevant keyword choices, your app name and subtitle, and screenshot priorities. You get drafts to review and reasons for the choices. The spreadsheet can finally stop pretending it is the deliverable.
Get my metadata reviewed →Or email gabriel@asoprofessional.com. Bring your app link, market and the decision you need help with.
Want a first opinion? Get a free video teardown of your listing.