App Store Description and Subtitle: Limits and Examples

Four numbers decide most of your App Store listing: 30 characters for the app name, 30 for the subtitle, 100 bytes for the keyword field, 4,000 characters for the description. Get them wrong and you fix them on Apple's schedule rather than yours, because almost every one of those fields only changes when you ship a new version.

This is the reference we keep open before a submission: the exact limits from Apple's own documentation, subtitle examples with counts, and a short audit of our own listing at the end, defects included.

Every App Store field and its limit

• App name. 30 characters. Changes only with a new version.
• Subtitle. 30 characters. Changes only with a new version.
• Promotional text. 170 characters. Changeable at any time, with no submission and no review.
• Description. 4,000 characters, plain text, HTML is not supported. Changes only with a new version.
• Keywords. 100 bytes, and each term has to be longer than two characters. Changes only with a new version.
• What's New in This Version. 4,000 characters, and it ships with the version.
• Screenshots. Up to 10.
• App previews. Up to three per localization per device size, 30 seconds each.
• In-app purchase name and description. 35 and 55 characters, edited separately from the listing.

Two Apple pages back this up and both are worth reading: Creating your product page for the guidance, and the App Store Connect reference on platform version information for the field rules.

Characters or bytes?

Apple's product page article says the keyword field is limited to 100 characters total. The App Store Connect reference says you can provide up to 100 bytes of content. Both are on Apple's own site, and they are not the same rule.

For plain English they match, because one character costs one byte. As soon as you localize, they diverge. A Russian keyword string of 42 characters is already 80 bytes, four fifths of the field gone. Our own app name is 29 characters but 31 bytes, because the interpunct at the end of it costs three.

So if you publish in Cyrillic, Greek, Japanese, Chinese or Korean, count bytes and expect roughly half as many terms to fit as the English field holds. Run the string through a byte counter before you paste it into App Store Connect.

What Apple actually indexes

Search and conversion are two different jobs, and they live in different fields.

Search runs on the app name, the subtitle and the keyword field. Apple's reference adds a detail worth money: your app is already searchable by app name and company name, so you should not duplicate those values in the keyword list. Every byte spent repeating your own brand is a byte not spent on demand.

Promotional text does not affect ranking. Apple states that plainly, and adds that it should not be used to display keywords.

The description is never listed as a ranking input in Apple's documentation, and Apple explicitly tells you not to add keywords to it in an attempt to improve search results. Treat it as conversion copy. It has to sell, not rank.

App Store subtitle examples

The subtitle is 30 characters that explain what the name cannot. Apple's own guidance is to use it to convey value rather than restate the name, and it names the failure mode directly: avoid generic descriptions such as "world's best app".

Seven that fit, with their character counts:

• Daily habit tracker & streaks (29). Category plus the mechanic people actually search for.
• Invoicing for freelancers (25). Says who it is for, which filters out the wrong installs.
• Sleep, calm and focus daily (27). Three outcomes, no adjectives.
• Job scheduling for crews (24). Names the user, not the technology.
• Meal plans and grocery lists (28). Two concrete nouns people type.
• Track blood pressure at home (28). A verb plus the context of use.
• Speak Spanish in 10 min a day (29). Outcome and time cost in one line.

And the one to avoid: "The best app for your needs", 27 characters that rank for nothing and tell a shopper nothing.

A practical way to write yours. Finish the sentence "this app helps someone do something", cut it to 30 characters, then read the name and the subtitle together the way they appear in search results. If the two lines describe two different products, fix it now, because you cannot fix it again until the next release.

The keyword field, packed properly

Apple's rules for the field, condensed:

• Terms are comma separated with no spaces between them. Spaces are allowed inside a phrase, so daily planner counts as one term.
• Skip plurals of words you already used in the singular.
• Skip category names and the word app.
• Skip duplicates, including anything already sitting in your name or subtitle.
• Skip special characters such as # or @ unless they are part of your brand. They carry no extra weight in search.
• Never use trademarked terms, celebrity names or competing app names. Improper keyword use is a common reason for rejection.

A worked example for a habit tracker, 89 bytes with 11 to spare:

habit,streak,routine,daily planner,goal,productivity,reminder,self care,journal,checklist

Note what is missing. No tracker, because it is already in the subtitle. No app. No plurals. No brand name.

Writing the description

Apple's advice here is short and mostly ignored. The first sentence is the one users read without tapping more, so it carries the whole pitch. After that, a concise informative paragraph followed by a short list of main features. Keep prices out of it, since pricing already appears on the product page and any number you write may be wrong in another region. If you want to mention an award, put it at the end or in the promotional text.

Four thousand characters is a ceiling, not a target. Our own listing uses 2,223 of them, and the honest read is that the first two lines do the work while the rest is there for the people who scroll.

If you are still costing the build that will carry this listing, our breakdown of what a mobile app actually costs covers the part that happens before the store page exists.

Promotional text and screenshots

Promotional text is the only field on this page you can change today. It is 170 characters, it sits above the description, and it needs no submission and no review. That makes it the right home for a launch or a limited-time price, while the description stays evergreen.

Screenshots are where most listings lose the install. You get up to 10, and when there is no app preview the first one to three are what appear in search results, so those three have to carry the pitch on their own. Previews autoplay muted, so the first two seconds decide whether anyone watches the rest. If the app supports Dark Mode, show it in at least one shot.

We audited our own listing

We publish our own apps, so we ran this checklist against one of them, Wallpapers for iPhone & iPad. Measured on 23 August 2026:

• Name: 29 of 30 characters, 31 bytes, spending the last character on an interpunct.
• Subtitle: Apple watch faces and themes, 28 of 30.
• Description: 2,223 of 4,000 characters.
• Screenshots: 8 of 10, and zero iPad screenshots.
• Last version: 1.9.4, February 2024.

Two defects fall straight out of that. The name sells wallpapers for iPhone and iPad, the subtitle sells Apple Watch faces, and someone scanning search results sees two different products on two adjacent lines. And the store page labels the app Only for iPhone while the name promises iPad, which is the kind of mismatch that costs a refund and a one-star review rather than a ranking.

None of this needed a paid ASO tool. Apple's public lookup endpoint returns the name, the description and the screenshot set for any app id, which is enough to audit a listing in about five minutes: https://itunes.apple.com/lookup?id=YOUR_APP_ID

Before you submit

• Name and subtitle read as one product, not two.
• No word repeated across name, subtitle and keywords.
• Keyword string measured in bytes, in every localization.
• The first sentence of the description works on its own, above the fold.
• The first three screenshots carry the pitch without the other seven.
• Promotional text holds the news, so the description does not have to.
• Support URL points at real contact details. Apple requires it, and local law may too.

Everything above is metadata work, and metadata cannot rescue an app that does not hold its users. If you want the build itself handled by a team that ships and maintains its own listings, that is our mobile development practice, and the fastest way to start is to tell us what you are building.