The What's New field is the only piece of App Store copy written for people who already chose you. It appears on your product page and in the Updates tab, in front of an audience that installed the app, kept it, and is deciding whether this version is worth the download.
App Store Connect's platform version information reference gives it the same budget as the description: "Limited to 4000 characters". Most releases spend six words of it saying nothing.
What Apple documents, and what it does not
Three things are on Apple's reference page and worth knowing before you plan around them:
- What's New is 4,000 characters, the same as the description.
- Promotional text is 170 characters and — this is the useful part — "lets you inform your App Store visitors of any current app features without requiring an updated submission". Promotional text is the field you can change between releases. What's New is not.
- Neither field appears in Apple's list of what search results are based on. Apple's App Store search page names "your app's title, subtitle, keywords, and primary category" for text relevance. Release notes are not among them.
| What's New | Promotional text | |
|---|---|---|
| Length | 4,000 characters | 170 characters |
| Where it shows | Product page and the Updates tab | Above the description on the product page |
| Change it without shipping a build? | No | Yes |
| In Apple's list of search-relevance fields? | No | No |
So: no ranking claim here, in either direction. What is verifiable is placement — the notes are on the product page and in the Updates tab — and that is a good enough reason to write them properly.
The field is a public claim about shipped software
This is the constraint that governs everything else. A release note is not marketing copy that can be aspirational. It is a statement that specific things are in the build a user is about to install.
Which makes drafting them with a language model a specific kind of risk. Being told not to invent a feature is not the same as being unable to. A model given a terse changelog and asked for something readable will helpfully round "fixed sync race condition" up to "faster, more reliable sync across all your devices" — a claim about performance that nobody measured — or add a feature that sounds like it belongs.
The mitigations that actually work are structural rather than instructional:
- The changelog is the only source of facts, stated as a rule in the prompt: no added features, no teasers, no thanks, no invented numbers, no other version numbers.
- Keep the changelog on screen beside the output, so the comparison is one glance rather than an act of recall.
- Make the output editable and copy the edit, not the draft.
- Read it as a claim, not as prose. For each sentence: is this in the build?
Appstro's release notes writer does all four and still says, in the closing copy, that being told not to invent something is not the same as being unable to. That sentence is not a disclaimer. It is the accurate description of what a model is.
One further detail worth copying: the app's previous release notes are passed to the model as a voice sample only, shown to you in an expandable block rather than hidden inside the prompt. You should be able to see what your draft is being modelled on. Last release's content is not shipping again.
What is worth checking, and what is not
The validation here is deliberately narrow: the 4,000-character cap, and a literal list of filler phrases — "bug fixes and performance improvements" and its close relatives.
Filler is a warning, not an error, and that distinction is the whole design. A genuine maintenance release has nothing else to say. Forcing text into the field is exactly how it fills up with invention, which is the failure the tool exists to prevent. If the release really was three crash fixes, "three crash fixes" is a better note than a paragraph.
Everything else about release notes is a judgement call, and a score over judgement calls only teaches people to write for the checker.
The date is public, and what you can honestly say about it
Your last release date is on your product page, and on everyone else's. That makes it one of the few genuinely comparable facts about a competitor.
It is worth being precise about what it supports. Apple's public API exposes only currentVersionReleaseDate — the date of the current version. There is no release history in it. So "last shipped 12 days ago" is supportable and "ships every 12 days" is not, for any app but your own. That is why Appstro's tool is called update recency and not update cadence: the name is the honest description of what the data contains.
One trap if you build this yourself. Apple's lookup and search endpoints are not always the same snapshot. Observed live for the same app, same country, seconds apart: lookup returned v2.14.20 dated 30 July 2026 while search returned v2.14.21 dated 5 August 2026 — the search index running six days ahead. Build the app under test from the lookup and its competitors from the search, and you will report an app as six days behind its rivals on a morning it had already shipped.
The three-year rule, and both of its conditions
Since it comes up whenever release frequency does: Apple's App Store Improvements process. An app is identified for possible removal when it has not been updated within the last three years AND fails to meet a minimal download threshold. Apple's own wording joins them with "and". A developer identified this way receives an email and has 90 days to submit an update.
Both conditions. An old app that still gets downloaded is not at risk under this process, and nobody should be shipping churn updates on the strength of a misremembered version of that rule. (Apps that crash on launch are a separate case and are removed without the 90-day window.)
Nothing on this page will tell you to ship more often. A tool cannot see whether you have anything worth shipping, and an update pushed to move a date is churn — it costs your users a download and tells them nothing.
What this cannot tell you
- Not whether release notes or update frequency affect ranking. Apple names four text-relevance fields; neither is among them.
- Not another app's release history. The public API has one date, not a series.
- Not whether your note is accurate. Only you know what is in the build. That is the entire risk and no checker touches it.
- Not whether the release was worth shipping. Different question, different evidence.
The work
Paste your raw changelog into the release notes writer, read every sentence of the draft against it, edit it, and copy the edit. Then check the recency of your app against the ones you share a search result with — not to feel bad about the gap, but because the date is the one thing your users can see and you cannot un-see.