Overview
Every listing field has a job and a hard limit. The editor shows how many characters you have left as you type, and blocks the name and subtitle at their ceiling rather than letting you paste past it.
Character limits
| Field | Limit | What it is for |
|---|---|---|
| Name | 30 | The app title. The most heavily weighted text you own. |
| Subtitle | 30 | One line under the name. Ranked, and read by people. |
| Keywords | 100 | Comma-separated and never shown to customers. |
| Promotional text | 170 | Changeable without a release. Not ranked. |
| Description | 4000 | The long copy. Not ranked on the App Store. |
| What's new | 4000 | Release notes for the version. |
The counter reads characters left rather than characters used, because the number that matters is the room you have.
The keywords field
The keywords field is 100 characters, comma-separated, and invisible to users. The store combines words across it, so repeating a word you already have in the name buys nothing.
How Spek fills it is covered in how the agent picks keywords.
Common questions
Why does the counter stop me typing?
Name and subtitle carry a hard cap, because a value over the limit would be rejected at publish rather than truncated. The longer fields only warn.
Review the final meaning after shortening a field. Removing words to fit a limit can accidentally change a product claim or leave a translated sentence unclear. Character validity is one check; product accuracy, local language and the provider review requirements still need attention.
Do emoji count as one character?
Not always. The App Store counts in its own units, so treat the counter as a close guide rather than a guarantee for unusual characters.
How should I divide information between the App Store fields?
Give each field a clear job while keeping the listing consistent. The name identifies the product, the subtitle adds a concise reason to care, and the longer description explains the experience and features in more detail. The App Store keywords field is separate from customer-facing prose. Review the complete set rather than repeating the same sentence everywhere. Spek displays the relevant character constraints, but fitting within a limit does not by itself make a claim accurate, useful or suitable for the selected language.
What should I check after localizing metadata?
Read the localized text as a whole, verify that the brand name and product promise remain correct, and check the field counters after editing. Some languages need more space to express the same idea, so a literal translation may need rewriting rather than simple shortening. Review punctuation and unusual characters in the actual field. Keep the selected store in view: the App Store field list in this guide should not be treated as a Google Play field specification.
Why should I review links as carefully as listing text?
A support, marketing or privacy-policy URL is part of the listing a user and the store can rely on. Open the intended destination, check that it belongs to the correct app or organization and confirm that the page is publicly reachable where required. A typo can leave an otherwise polished listing with an unusable support route. When updating the same URL across several locales, review the scope in Bulk and then inspect the final changes before the separate publishing action.
Does an accepted field value mean the store will approve the release?
No. A valid length and a successful metadata write establish only part of the process. The store can apply additional requirements to the app, its content, version, screenshots or submission. Spek's checks help identify supported prerequisites before sending a change, while the provider remains responsible for its own review and public release state. Read the outcome of the publishing action and use App Store Connect for any remaining review requirements rather than treating a filled character counter as approval.