Google Play Release Notes: Writing What's New in 500 Characters

On Google Play, release notes are short. Each language gets 500 characters, roughly three or four sentences, and they appear in the "What's new" section of your store listing. That limit is a gift: there is no room for a wall of changes, so you have to pick the one that matters. This guide covers how the field works in Play Console as of 28 September 2026, what you can change after a release, and how to write notes that name the requests your users asked for.

The short version

• You write release notes in the "What's new in this release?" field when you prepare a release, up to 500 Unicode characters per language.
• Each language's text goes between its own language tags, such as <en-GB> and </en-GB>, on separate lines.
• Google asks you not to use release notes for promotion or to ask users to do something.
• Managed publishing doesn't hold back an update to a release's notes, so you can fix a typo without waiting on your own publish button.
• Lead with the request people voted for, then tell the people who asked directly, because many of them never read the notes.

Where the field is

Google's Play Console Help page Prepare and roll out a release describes the steps. As of 28 September 2026, you open the track you are releasing to (internal, closed or open testing, or production), click Create new release, add your app bundle, name the release, and enter your localised release notes before you click Next.

Two fields on that page are easy to confuse:

• Release name is for your team. Google says it appears in Play Console and is not visible to users. Play Console fills it with the version name of the bundle you added; a build number or a code name works well.
• What's new in this release? is for users. Google's overview for it reads: inform users about recent updates made in your release, and don't use release notes for promotional purposes or to solicit user actions.

There is also a Copy from a previous release button, which copies an earlier release's notes and translations into the box for editing. It replaces what is there, so use it before you start typing.

The 500-character limit and language tags

As of 28 September 2026, Google's page says you can enter release notes using up to 500 Unicode characters per language. The text box shows a pair of language tags for each language your app supports, and you write each language's notes between its tags, with the tags on their own lines. Here is a release for a fictional hiking app in British English and German:

<en-GB>
Offline maps are here. You asked for this more than anything else: 248 votes on our feature board. Download a trail region before you lose signal, and Trailmate keeps the map and your route on your phone.

Also new: a trail difficulty filter, and an elevation profile on every hike summary.

Fixed: sharing a hike with no photos no longer crashes the app.

Thanks to everyone who voted.
</en-GB>
<de-DE>
Offline-Karten sind da. Mit 248 Stimmen war das die meistgewünschte Funktion auf unserem Feedback-Board. Lade ein Wandergebiet herunter, bevor du kein Netz mehr hast.

Neu: ein Filter für den Schwierigkeitsgrad und ein Höhenprofil für jede Tour.

Behoben: Das Teilen einer Tour ohne Fotos führt nicht mehr zum Absturz.
</de-DE>

The English text is 386 characters and the German 318, so both fit with room to spare. A few things to know about the tags:

• The tags follow your app's languages. Google's page says that to change which languages appear, you add translations beforehand; when you return to the release, the new set of tags is there.
• The limit is per language. A translation that runs longer than the English, as German often does, still has its own 500 characters.
• The API uses the same codes. If you release from a script or CI, Google's Play Developer API guide to tracks shows release notes as a releaseNotes list, each entry with a language such as en-US and its text, sent with the track update.

Notice what the example leaves out: a line such as "Send your next idea from Settings". It is a reasonable line to write elsewhere, but it asks the reader to do something, and Google's guidance for the field says not to.

Can you change release notes after a release?

This matters when you spot a typo an hour after rollout. Google's page on controlling when app changes are reviewed and published explains managed publishing: when it is on, most changes wait in Play Console until you press Publish, including releases, store listing changes and app content changes. As of 28 September 2026, the page lists a set of exceptions that managed publishing does not hold back, and updating your app's "Release notes" section is one of them, alongside increasing a staged rollout to 100% and price changes.

So an edit to the notes is not parked behind your publish button the way a new release is. Google's page doesn't say whether such an edit is reviewed, so don't plan on rewriting notes freely after launch. Get them right in the release, and treat a later edit as a fix, not a second chance to announce something.

The release details page in Play Console also keeps a list of previous release notes, which is useful when you write the next set and want to see what you said last time.

How to write notes people read

Five hundred characters means every sentence has to earn its place.

1. Open with the change. "Offline maps are here." Not "Version 4.2" and not "We've been busy".
2. Say why it matters in one sentence. What can the user now do that they couldn't before?
3. Group the rest. One line for other new things, one line for fixes people noticed. Everything else can go.
4. Use numbers you can stand behind. "248 votes on our feature board" can be checked. "Everyone wanted this" can't.
5. Don't name individuals unless they have agreed. Release notes are public.
6. Describe what is in this release. Google's rule against promotional use rules out teasing the next feature, and so does honesty: if you delivered part of a request, say which part.
7. Localise the notes for every language your listing has, or at least the opening line.

Mind the rollout

With a staged rollout, some users get the version days after others. Write the notes for the moment someone gets the update, and hold any announcement elsewhere until the rollout reaches the people you are telling. Our guide to staged rollouts on Google Play covers how the percentages and halts work.

Releases to testing tracks are prepared the same way, release notes included. See Google Play testing tracks for setting those up.

How FeedbackKit fits in

FeedbackKit doesn't write your release notes and doesn't publish a changelog for your users. The "What's new" text is yours. What FeedbackKit gives you is the evidence behind it: users vote on requests inside your Android app, so "248 votes on our feature board" is a number you can read off the board. The requests you moved to Completed since the last release are, in effect, the draft of your next notes.

It also closes the gap release notes leave. Many people never open the listing to read "What's new", including the person who asked for the feature. When you move a request to Completed, FeedbackKit emails the person who submitted it, on every plan, if Completed is on the project's list of statuses that send email; a new project's list includes it. Choosing a different list needs Pro, and emailing voters who opted in needs Team. A good habit: move the request to Completed when the release reaches users, not when you upload the bundle, so the email doesn't arrive before the update does.

FeedbackKit's beta status is called TestFlight, after Apple's service, and Android users see that same label. Many teams use it to mean "in testing", whichever store's beta it is, so a request can sit at TestFlight while its feature is on a closed track and move to Completed when it reaches production.

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

We wrote more about why that email matters in closing the loop with status emails. To add a board to your app, start with the Kotlin docs, or the Flutter and React Native SDKs. If you also ship on iOS, see App Store release notes.

If you want your next release notes backed by real votes, start free. Pricing lists what each plan includes.