App Store Connect gives you 4,000 characters of description. A visitor sees a few lines of it, then a "more" link. Everything after that link is behind a tap that most people never make.
That much is uncontroversial. What follows it usually is not, because the next thing most advice does is put a number on it — you get about 170 characters, or 3 lines, or 250. Apple has never published such a number, and there could not be a single one to publish. Where the text breaks depends on the width of the device, the reader's Dynamic Type setting and the script the copy is written in. A rule that is right on an iPhone 16 Pro Max is roughly 40% wrong on an iPhone SE.
So the useful question is not "how many characters do I get". It is "what does my first line do when it is the only line".
What Apple actually says
Apple's Creating Your Product Page guidance is specific about the stake and silent about the size:
"The first sentence of your description is the most important — this is what users can read without having to tap to read more."
That is Apple naming the constraint. On the reference side, App Store Connect's platform version information page states the description is "Limited to 4000 characters" and says nothing whatsoever about truncation on the product page. Both pages were fetched for this post; neither carries a cut-off figure.
Two facts, then, and the gap between them is where the folklore lives. Apple tells you the first sentence is what gets read. Apple does not tell you how long the first sentence is allowed to be.
Why a fixed number cannot be right
The product page renders your description as wrapped text in a clamped container. Three independent inputs move the boundary:
- Width. An iPhone SE and a Pro Max do not have the same content width, and neither does an iPad.
- Dynamic Type. A reader who has turned the system text size up sees fewer characters per line. This is an accessibility setting, not an edge case.
- Script. Characters per line differs enormously between English, German compounds and Chinese.
Appstro's above-the-fold preview therefore refuses to state a constant. It measures instead: an off-screen probe is rendered at the same width and font as the preview, then filled by binary search until it exceeds lineHeight × lines. The result is checked at the boundary — at 2, 3 and 4 lines the reported count fits and one more character overflows.
Measured that way on one sample listing, the visible budget came out as 120 characters at 288px, 158 at 358px and 168 at 398px. Same text, same font, three phone widths, a 40% spread. Any single number you might have printed would have been wrong on two of the three.
The newline problem, which is bigger than the character count
Here is the finding that matters more than any of the above, and it surprised us when it showed up in testing.
The product page preserves the description's own line breaks. So a hard newline in your copy consumes a visible line exactly as a full sentence would.
Measured against a real listing of 2,612 characters, the preview showed 115 characters — 4% of the description — because the first line was short and ended in a newline. Everything after it, including the sentence that actually explained the app, sat behind the "more" tap. The developer had written a perfectly good opening paragraph. The product page showed the salutation above it.
This is a formatting bug that looks like a copywriting problem, and it is invisible unless you look at the rendered page rather than the text file. Three shapes cause it:
| Opening shape | What the reader gets |
|---|---|
| A short greeting or tagline on its own line | One line, then "more" |
| A blank line after the first sentence | The first sentence only |
| Bullets or emoji-led feature lines from the top | Two or three bullets, no premise |
None of these are wrong in a 4,000-character document. All of them are expensive in the 150 or so characters that get read.
What is worth checking, and what is a judgement call
Appstro's preview also runs a small set of structural checks over the opening. They are deliberately narrow — a stock opener pattern, an over-long first sentence, a bloated first paragraph, a description that opens on bullets, and one too short to work with. Stock openers are a warning, not an error.
There is no score. Whether an opening line is worth reading is a judgement about the product, and a number over judgement calls only teaches people to write for the checker. The same discipline governs the release-notes checks in this codebase, and for the same reason.
What a checker can honestly do is tell you the shape of your opening. What it cannot do is tell you whether the shape carries the right idea.
A note on the other claim you will see
A related piece of folklore says the description feeds App Store search, so the opening should be keyword-dense. Apple's App Store search page describes what search is based on:
"Search results are based on a number of factors, including text relevance (matches for your app's title, subtitle, keywords, and primary category), as well as user behavior (downloads, ratings and reviews, and more)."
Title, subtitle, keywords, primary category. The description is not in that list. Apple does not say the description is indexed, and this post does not claim it is not indexed either — it says Apple names four text fields and the description is not one of them. Write the opening for the person, not for a matcher Apple has not described.
What this cannot tell you
- Not the exact cut on any specific reader's phone. A measurement at a chosen width and line count is a good model of a real device; it is not that device. The setting that moves it most — Dynamic Type — belongs to the reader.
- Not whether a better opening converts better. Impressions-to-installs on your own listing is visible only in App Store Connect, and testing a change properly means a product page test, with the multiple-comparison problem that implies.
- Not whether your first sentence is any good. That is the part no tool here evaluates, on purpose.
- Nothing about the description's effect on ranking. Apple names four text-relevance fields and the description is not among them; anything beyond that is inference.
The work
Paste your draft into the above-the-fold preview — the draft case is the useful one, since the point is to fix the copy before it ships — and read what a stranger reads. If your first 120 characters do not say what the app is and who it is for, nothing further down will get the chance to. Then move the rest of the listing onto one sheet with the listing kit, where every field is checked against Apple's own caps.