# App Store Metadata: Write Your Name, Subtitle and Keywords Canonical page: https://www.aso.guide/blog/app-store-metadata/ Author: ASO Guide Published: 2026-09-26 App Store metadata is the information that describes your app in its store listing, including its name, subtitle, keywords and description. Optimizing it means choosing words that match your app and help people understand what it does. This guide shows how to turn a keyword shortlist into an English-language listing for an iOS app, with examples and field limits you can check as you write. Bring the shortlist from our [App Store keyword research guide](https://www.aso.guide/blog/app-store-keyword-research/) and the positioning sentence from [ASO competitor analysis](https://www.aso.guide/blog/aso-competitor-analysis/). If you haven't chosen an audience or a problem yet, start there. Those decisions will help you choose what to put in each field. ## Give each metadata field a job Each field has a different job. Use the limits to check your draft, rather than treating them as space you have to fill. | Field and limit | Purpose in your draft | | ------------------------------------- | ------------------------------------------------------------------ | | App name: 30 characters | Identify the product and make its main use recognizable. | | Subtitle: 30 characters | Add a useful reason to consider the app. | | Keywords: 100 characters / 100 bytes* | Add relevant terms you haven't already covered. | | Description: 4,000 characters | Explain the experience, features and conditions in readable prose. | | Promotional text: 170 characters | Highlight a current message above the description. | *Apple's two references describe the keyword limit differently; see the explanation below. Apple documents the name and subtitle limits in its [app information reference](https://developer.apple.com/help/app-store-connect/reference/app-information/app-information/). The other limits appear in [platform version information](https://developer.apple.com/help/app-store-connect/reference/app-information/platform-version-information/). The keyword limit needs care: Apple's [product-page guidance](https://developer.apple.com/app-store/product-page/) says 100 characters, while its technical reference says 100 bytes. Our ASCII-only English examples fit both. For accented text or other scripts, count UTF-8 bytes as well as characters and check the actual localized field in App Store Connect before submission. Apple's documentation doesn't explain exactly how the live field counts Unicode text, so treat the byte count as a precaution. Apple identifies the name, subtitle and keywords among the text-relevance inputs to search, alongside other factors. It doesn't publish a complete ranking formula. A field passing validation doesn't establish that a query has demand or that your app will rank for it. [Apple: App Store search](https://developer.apple.com/app-store/search/). ## Start with a promise the product can support Our example is the series' fictional habit tracker, which we'll call **Daynook**. We haven't checked whether that name is available. For a real app, check App Store name availability and trademarks before choosing it. The app has a daily checklist, reminders and a history of completed habits. It doesn't plan a user's entire schedule or provide guided workouts. Its working position is: > A habit tracker for people who want to see today's habits, get a reminder, and record what they completed. A promise to transform someone's life would be hard to support with these features. The daily checklist is something we can explain and show. The metadata below is fictional too. We can explain the edits, but we haven't measured their effect on rankings or downloads. ## Before and after: a complete field comparison Spaces, punctuation and commas are included in these counts. The keyword examples contain only ASCII characters, so their UTF-8 byte counts match their character counts. ### Before: within the limits, but poorly allocated **Name - 28 / 30 characters** Daynook: Daily Habit Tracker **Subtitle - 30 / 30 characters** Habits, Goals & Daily Routines **Keywords - 60 / 100 characters; 60 bytes** habit,tracker,daily,routine,reminders,goals,calendar,workout The name already establishes habit tracking. The subtitle spends much of its space repeating that idea. The keyword field repeats visible wording, then adds `calendar` and `workout`, even though someone seeking a scheduling tool or guided exercise would be disappointed. Every field fits its limit, yet the listing still needs work. ### After: a clearer division of work **Name - 22 / 30 characters** Daynook: Habit Tracker **Subtitle - 29 / 30 characters** Daily checklist and reminders **Keywords - 38 / 100 characters; 38 bytes** routine,goals,progress,log,consistency The name identifies the app as a habit tracker, while the subtitle tells readers about its checklist and reminders. The keyword field adds other terms to investigate. We've left the keyword field at 38 characters because this example has a small research shortlist. There's no ideal length here. Add a term when you can explain why it belongs, and note when you still need evidence that people search for it. ## Write a name people can recognize Adding `Habit Tracker` to Daynook tells a reader what kind of app it is. We moved `Daily` to the subtitle, where it describes the checklist. That makes the wording more specific; we don't know whether the move would change its search ranking. Read the name on its own, then alongside the icon, subtitle and screenshots. Someone looking for your app should be able to recognize it in both situations. If your established brand name is long, it may leave little room for a phrase describing the app. Don't abbreviate it beyond recognition just to imitate this example. The goal is a name users can understand and remember within the available space. Apple requires accurate metadata and bars attempts to manipulate it with irrelevant terms. Its subtitle rules also reject references to other apps and unverifiable claims. Review the wording against [App Review Guideline 2.3](https://developer.apple.com/app-store/review/guidelines/#accurate-metadata), not only against a counter. ## Make the subtitle answer the next question Once someone knows Daynook is a habit tracker, the next useful question is how it works. `Daily checklist and reminders` gives a direct answer in 29 characters. The earlier subtitle, `Habits, Goals & Daily Routines`, says little about using the app. The revision points to two features a screenshot can demonstrate: today's checklist and the reminder controls. Try reading your name and subtitle aloud as one unit. Remove a repeated idea if doing so makes room for useful information. Keep ordinary grammar; a string of disconnected search terms can make the app harder to understand. For a real draft, ask someone unfamiliar with the app to describe what they expect after reading those two fields. If they imagine a feature you don't have, revise the wording before testing whether it attracts downloads. ## Use the keyword field for justified candidates Apple advises separating keyword entries with commas, omitting spaces around those separators. Spaces within a multiword phrase are allowed. Its search guidance also says to avoid repeating words from the name, subtitle or category, redundant singular/plural forms, and competing app names. [Apple: Keyword guidance](https://developer.apple.com/app-store/search/). Here's why we kept or rejected each candidate: | Candidate | Feature connection and decision | | ----------- | ------------------------------------------------------------------------------------------------------------- | | routine | A daily set of habits. Keep as a research candidate; don't imply full-day scheduling. | | goals | Users can pursue personal habits. Check whether search results instead suggest project or financial planning. | | progress | Completion history lets users review what they have done. The draft doesn't promise predictive insights. | | log | Recording completed habits is part of the product. Check the intent of the actual queries you want to reach. | | consistency | Describes the user's aim. Search demand remains unverified in this fictional example. | | calendar | Exclude from this draft: the product doesn't offer calendar planning. | | workout | Exclude from this draft: recording an exercise habit doesn't make the app a workout guide. | Keep the rejected terms in your research notes. Otherwise, the same attractive but unsuitable suggestion can return every time you revise the listing. Don't treat a comma-separated list as a promise that every possible combination will appear in search. Check the actual queries in the intended storefront and keep your observations separate from assumptions about how matching works. ## Use the description to explain the experience The description gives you room to resolve questions the short fields leave open. For Daynook, an illustrative opening is: > Keep your daily habits in one checklist. Set reminders, mark what you complete, and look back at your history. That paragraph is 110 characters. A full description could then explain adding a habit, setting a reminder and reviewing previous completions. Include relevant access or purchase conditions if they apply to the real app. Apple advises against padding the description with keywords and states that promotional text doesn't affect search ranking. Promotional text can be updated without submitting a new app version. Use it for a current, useful message; leave it empty if you have nothing useful to add. [Apple: Description and promotional text](https://developer.apple.com/app-store/product-page/). Keep your metadata change log separate from the customer-facing What's New text. In the log, explain why you changed the listing and what you want to learn. In What's New, describe changes that matter to someone using the app. ## Validate one localization before release This example uses English (US) metadata and research scoped to the US storefront. Record both the language you're editing and the market you researched. Don't assume an English phrase will express the same intent when translated word for word. Before submission, work through these checks: 1. Count the exact final strings, including punctuation and spaces. Check keyword bytes as well. 2. Match every promise to a feature available in the submitted version. 3. Remove unsupported names, claims and irrelevant search terms. 4. Read the visible fields together with the screenshots and description. 5. Paste the draft into the intended App Store Connect localization and resolve its validation messages. 6. Save the old and new text with the version and release context. ## Where to edit your App Store metadata In App Store Connect, open **Apps**, select your app, and use the **Distribution** tab. There are two places to check: 1. Under **General → App Information**, find the name and subtitle. Select the intended localization before editing these fields. 2. Select the app version beneath the relevant platform in the sidebar. Its localized version information contains keywords, description and promotional text. Check the language here too, then save your changes. Whether you can edit a field depends on the version's status and your account permissions. If a field is locked, check both before changing your release plan. [Apple: View and edit app information](https://developer.apple.com/help/app-store-connect/create-an-app-record/view-and-edit-app-information). For an app already on sale, plan keyword changes with the next version submission. Apple’s [new-version workflow](https://developer.apple.com/help/app-store-connect/update-your-app/create-a-new-version/) carries existing metadata into the new version so you can revise it before review. Saving that draft does not publish it: complete the applicable review and release steps, then verify the public listing. Promotional text can be updated without a new version; that exception does not apply to all fields. ## Record what you want to learn ### A completed example for Daynook Here's a fictional release plan for the revised listing. The dates show how to organize a review; they don't prescribe how long your test should run, and there are no measured results. - **Scope and owner:** English (US), US storefront, iPhone; the developer owns the metadata and review notes. - **Release:** version 1.1, planned for October 5, 2026. Replace that date with the actual date the metadata becomes available. - **Change:** use the revised name (22 characters), subtitle (29) and keywords (38) shown above. Preserve the three original strings in the same record. - **Query and reason:** follow `habit reminder` from the research shortlist. The new subtitle mentions reminders, and the app's reminder controls support that promise. We still need to check demand and whether the app appears for the query. - **Check reader expectations:** before submission, show the name and subtitle to prospective users unfamiliar with the app. Ask what they expect to do. Record their answers without suggesting features; revise wording that repeatedly implies full-day scheduling or guided workouts. - **Measurements to save:** save App Store Connect impressions and first-time downloads for September 21–October 4. Compare October 5–18 using the same US, iPhone and App Store Search filters; move the periods if release slips. Record daily query positions separately with the same storefront and collection method. This example contains no measured values. - **Other changes:** aim to keep screenshots and pricing unchanged during this comparison. Log product releases, advertising or other events that could affect the results. - **Review:** on October 19, check whether the listing is correct and whether the observations are comparable. Correct misleading wording promptly. Keep the performance result inconclusive if data is sparse or other changes prevent a useful comparison; do not attribute an increase to one word. ### Your metadata change log Copy this worksheet for your own app: - **Localization and research storefront:** - **App version and actual metadata release date:** - **Audience and task:** - **Old name, subtitle and keyword field:** - **Proposed text and validated counts:** - **Feature evidence for each new promise:** - **Queries to observe and reasons for choosing them:** - **Expected effect and remaining uncertainty:** - **Baseline period, reporting source and filters:** - **Other changes during the comparison:** - **Owner, review date and reason to revise:** Use comparable reporting periods and filters. Record advertising, pricing, product and creative changes that could affect the same results. Apple's search guidance notes that Apple Ads performance is included in App Store Connect search-source reporting, so that source isn't a clean organic-only experiment. [Apple: Monitor search performance](https://developer.apple.com/app-store/search/). A before-and-after comparison can suggest a direction; it cannot isolate the effect of one word. If traffic is too sparse or the surrounding changes are too large, keep the result inconclusive. Don't rewrite the listing merely because a review date has arrived. ## Frequently asked questions ### Do I need to fill the keyword field? No. Add terms when they are relevant and supported by research. Apple’s marketing guidance says 100 characters, while its technical reference says 100 bytes; our ASCII example fits both at 38. Check the localized field before submission, especially for non-ASCII text. ### Are spaces allowed in App Store keywords? Use commas without surrounding spaces between entries. Apple allows spaces within a keyword phrase. For this example, each entry is a single word, so no spaces are needed. ### Should I repeat my app name in the keyword field? Apple advises against repeating it there. Use that space for other relevant terms. Check the subtitle and category for duplication as well. ### Does promotional text improve keyword rankings? Apple explicitly says it doesn't affect search ranking. Choose it for what it tells a reader about the app, not as extra keyword storage. ### Can I change keywords without releasing a new version? For an already released app, plan keyword changes with a new version submission. You can edit the draft when its status permits it; saving does not update the live listing. Promotional text has a different update workflow. See the [App Store Connect steps above](#where-to-edit-your-app-store-metadata). ### Where do I enter the keyword field? Select your app in App Store Connect, open the version beneath the relevant platform, and choose the intended localization in its version information. Enter terms in Keywords. The name and subtitle are in App Information; keywords are not entered in the public description. ## Turn the written promise into a screenshot brief Finish one localized draft and ask a teammate to point to the screen that supports each visible claim. For Daynook, the first candidate is the daily checklist; the next shows setting a reminder, followed by completion history. This is an illustrative sequence to evaluate, not a proven conversion winner. Use those screens as the starting point for a storyboard. Our [App Store screenshots guide](https://www.aso.guide/blog/app-store-screenshots/) shows how to choose the sequence and write captions that explain what the app does. You can follow keyword positions and history in [ASO Analytics](https://www.aso.guide/#features). Keep your change log alongside those observations so you know which version of the listing was live when a position changed.