App Store What's New and Play Release Notes (2026)

I read Apple's App Store Connect help, its App Review Guidelines and Google's Play Console help on 31 October 2026.

This post covers the limits in each store, where the text shows, the rules on describing changes, Google's language tag format and a simple template you can reuse.

Release notes get less attention than screenshots, so advice about them often goes stale. I checked each fact below against the store's own page, not a summary. Five pages cover it.

1. 1App Store Connect help, for the What's New field, its limit and when it's required.
2. 2Apple's App Review Guidelines, for the rule on describing changes.
3. 3Product page guidance from Apple, for where the text shows and what Apple recommends.
4. 4Play Console help, for the release notes limit and the language tag format.
5. 5Google Play's Developer Program Policy, for the two lines that mention the what's new section.

Where a page didn't state something, I left it out. That's why this guide gives no rule on how release notes affect search ranking. Neither store says.

In App Store Connect, the field is called What's New in this Version. Apple's help describes it as a description of the changes in the version, such as new features, UI improvements or bug fixes.

The limit is 4,000 characters. That's the same as the app description.

Timing matters here. The field isn't available for the first version of an app. It's required for every version after that, so each update needs its own text.

You can localize it too. Each language your listing supports can carry its own What's New text.

Apple also recommends detail. Its help says to give users the specifics of the changes, improvements or fixes in the version. A long field and that advice point the same way. Say what changed.

Apple's App Review Guidelines put the rule in plain words. Rule 2.3.12 says apps must clearly describe new features and product changes in their What's New text.

It then draws a line. Simple bug fixes, security updates and performance improvements may rely on a generic description. More significant changes must be listed in the notes.

So a line like "Bug fixes and performance improvements" is fine for a release that only does that. It isn't fine for a release that adds a feature, removes one or changes how a main screen works.

Think of the generic line as a label for small releases. When an update is big enough that a user would notice, name what changed.

Apple's product page guidance says What's New text appears in two places. One is your product page. The other is the Updates tab.

That makes it a message to two groups. People who already use your app read it to learn what changed. People who are deciding whether to download it may see it on your product page.

Apple suggests using the text to show you listen. If you added a feature or fixed a bug based on feedback, its guidance says to use What's New to let users know.

That's a small detail, but it's one of the few things in a listing that speaks straight to your current users.

Apple gives you three text fields that change on different schedules. It helps to know which one fits which job.

1. 1What's New belongs to each version and describes that version's changes, in up to 4,000 characters.
2. 2Promotional text sits above the description, holds up to 170 characters and can change at any time without a new version.
3. 3Your description, also up to 4,000 characters, can change when you submit a new version.

Apple's product page guidance adds one more fact. Promotional text doesn't affect your app's search ranking.

So use promotional text for news that changes often, such as an event or a sale. Use What's New for what this version changed. Keep the description for what the app does overall.

Apple's product page guidance gives three pieces of advice for What's New. Each one is short, and each one is easy to skip when a release is late.

1. 1List new features, content or functionality in order of importance.
2. 2Add call to action messaging that gets users excited about the update.
3. 3Tell users when a feature or fix came from their feedback.

Order of importance is the one I'd start with. Readers stop early, so the change that matters most to them goes first. A fix for a crash on launch can matter more than a new color theme.

The call to action can be small. Something like "Try the new export button on the share screen" tells a user where to look.

On Google Play, the text sits under the heading "What's new in this release?" in Play Console. Google's help says the notes inform users about recent updates in your release.

The limit is up to 500 Unicode characters per language. That's an eighth of Apple's 4,000, so Play notes need to be tight.

Release notes are separate from your store listing text. Your short and full description stay as they are when you ship notes for a new release. Our guide to the two Play descriptions covers those fields.

If you write one set of notes for both stores, start with the Play version. Fitting 500 characters forces you to pick the main change. You can then add detail for the App Store.

Play Console expects each language's notes between two language tags. The tags go on separate lines from the notes themselves.

Google's help shows the shape with US English. The first line holds en-US inside angle brackets. Your notes follow, and they can take up several lines. The last line holds the same code with a slash before it, also inside angle brackets.

You don't have to type the tags from memory. The help says language tags appear in the text box for each language your app supports. You add your notes between the right tags.

Teams that publish with the Google Play Developer API send the same notes as a list. Each entry carries a BCP 47 language tag, such as de-AT for Austrian German, plus the text. The API reference doesn't state a length limit, so keep to the 500 characters Play Console allows.

Play Console can copy notes from a release you already shipped. That saves time when most of your languages carry the same structure each update.

There's one catch. Google's help says that selecting a release copies its notes and translations into the text box for editing, and it replaces the existing entries.

So copy first, then edit. If you write new notes and copy an old release after that, you lose what you wrote.

After copying, read every language. Old notes describe old changes, and it's easy to ship last month's text by mistake.

I found two lines in Google Play's Developer Program Policy that name the what's new section.

The first sits in the Deceptive Behavior part of the policy, in its examples of common violations. One example is apps that change significantly between versions without alerting the user, for example in the what's new section, and without updating the store listing.

That puts two duties on a big update. Tell users what changed in the notes. Then update the listing so screenshots and text match the new app.

Google doesn't define "significantly" in that line. A safe reading is the same as Apple's rule. If users would notice the change, describe it.

The second line sits in the policy's part on target audience. Google strongly recommends that you let existing users know if you change the target age group for your app or start using ads or in app purchases.

It names two ways to do that. You can use the What's New section of your store listing page, or you can use in app notifications.

This is a recommendation, not a stated violation. Still, these are the changes users care about most. Someone who installed a free app with no ads deserves a line saying ads are coming.

If an update adds ads or purchases, say so in the first sentence of the notes. Don't bury it under smaller changes.

The rules above set the limits. The tips below are my own advice for working inside them, not store rules.

1. 1Lead with the change users will notice most.
2. 2Name each feature the way it appears in the app, so users can find it.
3. 3Give one change per line, so readers can scan.
4. 4Say what users can now do, rather than what your team rebuilt.
5. 5Keep the generic fixes line for releases that really only fix bugs.

Plain words beat clever ones here. Users read notes in a few seconds. A joke can work in a long Apple note, but it shouldn't push the main change out of the first line.

Check the length before you paste. Play Console counts up to 500 characters per language, and a note that's cut short reads badly.

A template keeps notes consistent from one release to the next. This one fits inside Google's 500 characters for most updates.

1. 1The headline change, in one sentence.
2. 2One or two smaller changes, one line each.
3. 3Fixes, grouped into one line.
4. 4A short pointer to where users can try the new feature.

Here's an example for a made up notes app.

"New: dark mode on every screen. Turn it on in Settings, under Display. Search now finds words inside attachments. Fixed a crash when sharing a long note. Thanks for the reports that helped us find it."

That example runs to 200 characters, so there's room for a translation that runs longer. For the App Store, you can add a line of detail under each change.

Both stores support release notes per language. Apple's help says What's New can be localized. Google gives each language its own pair of tags and its own 500 characters.

If your listing is translated, translate the notes as well. A user who reads your listing in Spanish will likely expect Spanish notes too.

Translations can run longer than the English text. A note near 500 characters in English may not fit once translated. Leave room in the English version.

Our guide to localizing app store listings covers the other fields and how to plan a translated listing.

We make PlayMockUp, so weigh this part with that in mind. Release notes are text, and PlayMockUp doesn't write them.

Where we can help is the second half of Google's policy line. When an update changes how your app looks, your screenshots may need to change with it. PlayMockUp puts your screenshots in device frames for store listings.

You can start with our free mockup generator and pick a device from the frame list.

If you're unsure whether new screenshots need a new app version on Apple's side, our guide on changing App Store screenshots without an update covers that question.