App Store What's New: 4000-Character Limit and Release Note Rules

As of November 2026, What's New in this Version holds up to 4000 characters per localization. It describes the changes in that version, it is required for every version after the first, and it ships with the version you submit.

This guide is for iOS developers who own their listing. It gives the exact limit, where the text appears, how it differs from description and promotional text, and a counted example you can copy.

Where does What's New appear?

It appears in two places: on your product page and on the Updates tab. Apple states this directly on its product page. When you update your app, you use What's New to communicate changes. The text appears on the product page and on the Updates tab.

Write for both readers: a store visitor reads the notes on the product page before they update, and an existing user reads them on the Updates tab to decide whether to update now. Put the most important change first so both readers see it without expanding the text.

Apple recommends that you list new features, content, or functionality in order of importance, and that you add call-to-action messaging that gets users excited about the update. Name the feature, say what it changes for the reader, and close with one action such as trying the new view today.

Screenshots sit next to the notes on the product page. The first screenshots carry the visual proof while the notes carry the facts. For the image rules that shape that side of the page, read the screenshot size and upload rules.

What are the limits and version rules?

The limit is 4000 characters. Apple phrases the rule as a description of the changes in the version, such as new features, UI improvements, or bug fixes, limited to 4000 characters. Apple recommends detailed information so users learn the specifics of the changes, improvements, or fixes.

Apple's property matrix confirms the pattern: it lists What's New as required for version updates only, and as localizable. It does not list it as editable at any time, which is the column Promotional Text owns. Enter the notes on the version itself, check them during review preparation, and expect them to go live with that version.

Count the text with python3 before you save it, and keep a margin for multi-byte characters:

len("Fixed offline sync for playlists larger than 1 GB. New sleep timer in the player.")

That line uses 81 of the 4000 characters. A short factual note like that passes the limit with room for a short list below it.

Do not confuse this field with Notes. Notes holds up to 4000 bytes of review-only information such as test accounts, and users never see it. What's New is the user-facing text.

How is it different from Description and Promotional Text?

The three fields share the page but follow different rules. The table below uses the limits Apple states for each one, as of November 2026.

Description details the app itself: features and functionality in plain text with line breaks where needed. Apple shows it on the product page, at install time, and in web search results, and lists it as required and localizable. Promotional Text informs visitors of current features without a new submission, appears above the description on devices with iOS 11 or later, and cannot run longer than 170 characters.

Use each field for its own job. Put lasting value in Description, timely news in Promotional Text, and version changes in What's New. Do not paste the same paragraph into all three. For the full comparison of the two reader-facing fields, read promotional text and description rules.

Apple does not document whether What's New text feeds search indexing. Treat it as reader-facing text, not keyword space. Put search terms in the fields Apple indexes for search instead: app name, subtitle, and the hidden keyword field. For that formatting, read the keyword field rules.

What should you write in it?

Follow these steps when you enter the notes on a new version in App Store Connect.

1. Open the version, not the app record, and select each localization you sell in.
2. Write one line per change, most important first.
3. Name the feature, the fix, or the content, with the outcome for the reader.
4. Keep each line factual and short, with no prices, no rival names, and no keyword lists.
5. Count every localization with python3 and keep each at or under 4000 characters.
6. Submit the notes with the version and check them on the product page after release.

The following example uses a clearly made-up app. Harbor is a fictional tide app. Its 4.2 notes below replace the previous version's notes; they do not edit them in place.

New in 4.2: offline charts for saved trips. Storm alerts now show wind gusts per hour. Fixed a sync error on playlists larger than 1 GB. Try the new harbor view today.

That text uses 167 of the 4000 characters. It names two changes, one fix, and one action. It stays true across regions because it names no price and no date.

When a version has no user-facing change, still enter a short factual note. Name the stability or compatibility work in one line rather than leaving the required field empty or copying the description.

What this doesn't cover

This post does not cover Google Play release notes, which follow a shorter limit and different rules. It does not cover pricing, availability, or review-response practice. It does not cover search ranking: Apple publishes no weighting across relevance fields, and this post makes no claim about where What's New ranks.