App Store release notes: the limits, examples and a template for What’s New

What’s New in this Version, the field for App Store release notes, holds 4,000 characters, but at phone width the App Store’s web page may show only the first sentence of a long note before its “more” link. So write that sentence first, as if it were the whole note, and use the rest of the field for the details.

This page is about the App Store’s field: its limits and rules, where you enter it, a template, four notes from planner apps that shipped in September 2026, and four mistakes from the version history of Ellie, the planner I build. For how to decide what goes in a note in the first place, start with how to write release notes.

• What it is for. Apple’s help for What’s New in this Version describes it as the changes in this version, such as new features, UI improvements or bug fixes, and recommends giving details so people know the specifics.

• First version and languages. The field isn’t available for an app’s first version and is required for every version after it. It can be localized, so each language on your listing carries its own note.

• Changing it. Apple’s table of required, localizable and editable properties marks the fields you can edit at any time without submitting a new version, and What’s New isn’t one of them. Once a version is out, its note stays until the next version.

• What App Review expects. Guideline 2.3.12 of the App Review Guidelines requires apps to describe new features and product changes clearly in What’s New. A generic line is fine for “simple bug fixes, security updates, and performance improvements”; anything more significant has to be listed.

• Where it shows. Apple’s product page guide says the text appears on your product page and on the Updates tab. On iPhone and iPad there’s no tab by that name now: Apple’s support page on updating apps puts the list under your photo at the top of the App Store, then App Updates. The guide suggests listing new features in order of importance, adding a call to action, and saying so when a fix came from user feedback.

• The field next to it. Promotional text is the one to use for news that changes between versions. The same guide says it sits at the top of the description, holds 170 characters and can be updated at any time without a new version.

• If you also ship on Google Play. Google’s help for preparing a release allows up to 500 Unicode characters of release notes per language and says not to use them for promotion or to ask users to take an action. Apple’s guide, by contrast, suggests a call to action. If one note goes to both stores, cut it to 500 characters and leave the call to action out.

What’s New belongs to a version, so it is written when you create one. Apple’s steps for creating a new version, in short:

1. In App Store Connect, open Apps and select the app. The current version has to be Ready for Distribution, and you need the Account Holder, Admin, App Manager or Marketing role.

2. In the sidebar, click the add button (+) next to the platform, enter the new version number and click Create.

3. Review and enter the metadata for the new version, which includes What’s New in This Version for each language, then click Save.

4. Upload the build, add it to the version, and submit it to App Review.

Apple’s help adds that the metadata of the current version is copied into the new one. So before you submit, read what is actually in the What’s New field rather than what you meant to write: if last version’s note came along with the rest, it’s an easy way to ship the same text twice (mistake 3 below).

What’s New on Ellie’s App Store page (top) and Structured’s (bottom), each captured at a 390 px wide browser viewport. Ellie’s 102-character note shows in full; Structured’s 774-character note shows its first sentence and the line What’s new, and the rest is behind the circled more link. Screenshots of apps.apple.com, captured September 18, 2026 with Moonjar, our product.

The App Store’s web page shows the start of the note and folds the rest behind “more”. Captured at a 390 px wide viewport, about the width of a phone browser, Ellie’s 102-character note for 4.0.13 showed in full. Structured’s 774-character note for 4.6.0 showed its opening sentence and the line “What’s new”, and none of its six list items. At a 1440 px desktop width, the first list item showed as well.

So the 4,000 characters are room for the details. On the web page at phone width, the first sentence was all of Structured’s note that showed, so for anyone who doesn’t tap “more” it can be the whole note, which makes it the headline. Structured’s opening holds up when it is cut off: a reader who stops there still learns that this is the iOS 27 update and that it adds ways to plan.

Three things waste that first line:

• A label that repeats the heading. The App Store page already prints “What’s New” above your text. A note that opens with “What’s New:” spends its first line saying it again.

• Anything that isn’t the change: thanks, a greeting, a request for a review.

• “Bug fixes and improvements” at the top of a release that has a feature in it. Put the feature first and the generic line last.

Copy the block that fits the release, without its capitalized label, and replace each bracket with your own words. Every line in it is a line in the field, so nothing breaks where you didn’t mean it to.

ONE CHANGE
[Adds/Improves/Fixes] [feature or screen, by its in-app name] [on iPhone or iPad, if only one].

SEVERAL CHANGES
[The change most people will notice, as one sentence that stands alone.]

New
- [What you can do now, and where to find it.]
Improved
- [What is faster or clearer, and where.]
Fixed
- [What went wrong, as people saw it, and what happens now.]

Needs [the iOS version, or the setting that turns it on].

ONLY FIXES
Fixes [the problem people most likely hit, as they saw it]. Also includes smaller fixes and performance improvements.

What each part is for:

• One change: a single sentence that starts with a verb, names the screen or feature with the label the app uses, and says which device when the change applies to only one.

• Several changes: the opening sentence is the change most people will notice, or what the release adds up to, and it has to make sense alone, because at phone width it may be all that shows. Keep only the groups you need. The Needs line is for the iOS version a feature requires, or the setting that turns it on, written as Settings, then the exact menu names.

• Only fixes: lead with the problem people were most likely to hit, described the way they saw it, and keep the generic line last.

Write it as plain text with line breaks. The Structured capture above shows the page keeping the gap between its first sentence and the next line. Before you submit:

• The first sentence stands on its own.

• Button and screen names match the app, capitals included.

• The note in the field is this version’s, not the one carried over from the last.

• Every language on your listing has a note, not only English.

• It is 500 characters or fewer if the same text goes to Google Play.

All four apps shipped between September 4 and September 17, 2026. The notes, versions and dates come from each app’s App Store page and Apple’s lookup data, read on September 18, 2026; the apps may have shipped newer versions since. Character counts include line breaks.

Ellie 4.0.13 (September 4, 2026): one sentence, 102 characters

Improves task template ordering and makes drag-and-drop placement more accurate in the Timebox on iOS.

It starts with a verb, names the two places that changed with the labels the app uses (task templates, the Timebox) and says which platform. It fits whole on Ellie’s App Store page at phone width. What it can’t do is show where task templates live, which is the changelog entry’s job (see the last section).

Structured 4.6.0 (September 11, 2026): a sentence, a list and the fine print, 774 characters

The note opens with one sentence that sums up the update, then a “What’s new” list of six items: five name a feature and what it does, and the last covers performance and bug fixes. After the list it says the features need iOS 27, that one of them only works in some regions, and that another is in beta and switched on under Settings, then Advanced. It ends with a feedback address.

Copy the fine print. Someone still on iOS 26 learns why the new features aren’t there, and someone looking for the beta feature learns where to turn it on.

TickTick 8.2.11 (September 15, 2026): grouped under two headings, 841 characters

The note has two labeled groups, one for new iOS 27 features and one for improvements, and each improvement starts with a short label followed by a one-sentence explanation. It closes with two general paragraphs, the second listing the team’s social accounts.

Grouping helps when a release mixes new features with improvements to old ones. The cost is that the first line is a group label rather than a summary, so the first thing people read before “more” is a heading.

Moleskine Planner 3.1.734 (September 17, 2026): a short list, 350 characters

A label, then five items: three changes written as what now works, one fix and one catch-all line, then a closing line asking what you think. The first two items say what changed and what that makes easier, which is the part to copy. The opening label repeats the section heading, which is the part to skip.

Ellie’s App Store page shows 25 notes in its version history, from 3.62 (July 25, 2025) to 4.0.13, although Ellie has been on the App Store since December 2021. They run from 15 to 303 characters, with a median of 97. None comes close to 4,000. The seven most recent each start with a verb and name what changed, but four patterns in the history are worth avoiding.

1. Saying where, not what. 4.0.3 (May 1, 2026) reads “Fixes for iPad.” Someone who hit an iPad bug can’t tell whether it was theirs. Compare 4.0.9 (May 29, 2026): “Fixed task card labels and scheduled-time indicators so they appear reliably after account data loads.”

2. The generic line on its own. 4.0.2 (April 19, 2026) reads “Bug fixes and performance improvements”. Guideline 2.3.12 allows that for simple fixes. Once a release adds or changes something people will notice, name it.

3. The same note twice. 4.0.4 and 4.0.5 (May 15 and 16, 2026) carry the same note about rich text in notes, so the history doesn’t say what 4.0.5 changed. A follow-up release gets its own line, even a short one that names what it fixed and the version the problem came from.

4. Internal names. 4.0.10 (June 15, 2026) ends by mentioning Sentry observability improvements that help diagnose crashes faster. Sentry is a service on the developer’s side; users never see it. Leave a line like that out, and when the work fixes something people noticed, name the fix.

Each language on your listing has its own What’s New. In the App Store Connect API, the note is the whatsNew attribute of an App Store version localization, one per locale. fastlane’s deliver documentation says it reads the note from a release_notes.txt file in each language’s metadata folder, or from a release_notes setting with a default value used for every language that has no note of its own. Either way, write the English note first, keep its first sentence short enough to survive translation, and check the translated first sentences on their own.

What’s New carries words only. The pictures on your product page are its screenshots and app previews, which are separate from the note; how to make App Store screenshots covers those. When a release is worth seeing, write the matching entry on your changelog or updates page with the same headline, and give it one image of where the change lives.

A picture for an Ellie 4.0.13 changelog entry, made for this article: the Task Templates sheet open over the Timebox on iPhone, with one template lifted. Styled with Moonjar, our product, on September 18, 2026 from a capture of Ellie’s demo data taken September 16. Photo by Alexander Grey on Unsplash.

For Ellie 4.0.13, the image made for this article is the Task Templates sheet open over the Timebox, with one template lifted. The App Store note names the two places that changed; the image shows where they are, which a sentence can’t. To see how other apps pair entries with pictures, look at eleven changelog pages, captured and annotated; to build a page of your own with a link for every entry, see how to create a changelog in Framer CMS.

The image was made with Moonjar, our product (in early access, Mac only), from a capture of Ellie’s demo data in the iOS Simulator: it drew the iPhone, lifted the first template card so it runs slightly past the phone’s edges, and dimmed the rest. It also took the App Store captures above, from each page’s address. Here is what Moonjar makes, and early access to Moonjar if you want to try it.

Every note quoted or described here was live on the App Store on September 18, 2026: the 25 notes in Ellie’s version history and the current notes of three other planner apps that shipped updates in the same two weeks. The notes, versions and dates were read from Apple’s App Store pages and lookup data that day, and Ellie’s again on September 19. Apple’s and Google’s rules come from their own help pages, rechecked on September 19, 2026. The What’s New captures were taken with Moonjar on September 18, 2026. The Ellie image was styled with Moonjar the same day from a demo-data capture taken in the iOS Simulator on September 16, 2026. The text was drafted with AI assistance.