Can you change the What's New text without shipping a new build?

Apple does not document a way to do it. What's New in This Version is version information in App Store Connect, and Apple's reference says the property is not available for the first version of the app but is required for all subsequent versions. The field Apple does document for changing copy between releases is promotional text, capped at 170 characters, which it describes as letting you inform App Store visitors of current app features without requiring an updated submission. That carve-out exists because the rest of the version metadata does not work that way. So treat the notes as part of the release, and keep promotional text for the sentence you expect to rewrite later.

Are release notes required?

On the App Store, yes, from your second release onwards. Apple's version reference says What's New in This Version is not available for the first version of the app but required for all subsequent versions, so every update carries one whether you have something to say or not. Google Play's help page lists entering localised release notes among the steps for preparing a release, but it does not say what happens if you leave a language blank, so do not build a process on the assumption that blank is accepted.

What are you not allowed to write in Google Play release notes?

Google's help page for preparing and rolling out a release tells you to inform users about recent updates made in your release, and warns against using the notes for promotional purposes or to solicit user actions. That rules out discount copy, rate-us pleas, follow-us-on-social lines, and anything that reads like an advert dressed as an update. Describe what changed. That is the entire job of the field, and it is also what makes the note worth reading.

How do you write release notes in more than one language?

On Google Play they all go in one box, wrapped in language tags that sit on their own lines, so each block is an opening tag, then the notes, then a closing tag, repeated for every language. Google's example uses an en-US block and says the notes themselves can run over several lines. Changing which languages you offer means adding translations first. On the App Store, Apple marks What's New in This Version as a property that can be localized, so each App Store language gets its own 4000 characters and its own wording.

Can you reuse the previous release's notes?

On Google Play there is a button for it. The help page documents Copy from a previous release, which pulls the notes and their translations from an earlier release into the box. It replaces what is already there, which is handy for a hotfix that repeats most of last week's text and dangerous if you then forget to edit it, because it overwrites every language at once. Apple's version reference documents no equivalent, so the App Store note is retyped or pasted in by hand.

Who is actually reading a release note?

Two people who want different things. The first is standing on the update screen deciding whether this is worth the bandwidth, and wants the one line that affects them. The second reported a bug three weeks ago and is checking whether anyone listened, and wants their own words handed back. Apple's guidance points the same way: it recommends providing detailed information to let users know the specifics of the changes, improvements, or fixes in the version. Specifics serve both readers. A generic line serves neither, and costs you the only moment when somebody is already looking at your app and reading.

Articles · GuidesUpdated October 2026

A release note people read names the thing that was wrong in the words they used to report it.

You get two boxes, and they are not the same size. Apple calls it What's New in This Version and limits it to 4000 characters. Google Play gives you up to 500 Unicode characters per language, and tells you not to use them to promote anything or to ask users to do something. So the real constraint is 500 characters of plain description, written once per language, attached to a release you are about to ship. Both figures come from Apple's and Google's own documentation, read on 16 October 2026. Most people meet this field for the first time while publishing to the App Store.

What follows is what each store actually gives you, what the wording rules forbid, how the two handle languages, and the timing question everybody asks too late. One store has a button that copies last week's notes over every language at once. Neither store documents a way to rewrite a note after the release has gone out.

Start here

The short version

One line per change, and the one that hurt somebody goes first.

A release note is not an announcement. It is the answer to a question somebody is asking while they stand on the update screen: is this worth doing now. The answer is specific or it is nothing. Fixed the crash when you opened a saved order with no items in it is an answer. Bug fixes and performance improvements is a shrug, and it is the most common thing in the field because it is the easiest thing to type at the end of a long day.

Apple pushes the same way in its own documentation. Its version reference recommends that you provide detailed information to let users know the specifics of the changes, improvements, or fixes in the version. Google pushes from the other side, by telling you what the field is not for: not promotion, not asking users to do things. Between the two you are left with description, which turns out to be the only thing anyone wanted from the field anyway.

What does each store give you to write in?

On the App Store the field sits in what Apple calls platform version information, alongside the description, the keywords and the screenshots. Apple's reference describes it as a description of the changes in this version of the app, such as new features, UI improvements, or bug fixes, and limits it to 4000 characters. It can be localized, so each App Store language carries its own. And it has one structural rule that surprises people: the property is not available for the first version of the app, but it is required for all subsequent versions. Your launch has no release note. Every update after it has to have one.

Google Play is the tighter of the two by a long way. The notes go in during the release preparation step, under a heading that reads what's new in this release, and Play Console help says you can enter release notes using up to 500 Unicode characters per language. Unicode characters, not bytes, so an accented word costs what it looks like it costs. Per language, not in total, so a second language is a second 500 rather than a division of the first. There is also a Copy from a previous release control that pulls the notes and their translations in from an earlier release, replacing whatever is in the box.

The practical consequence of the gap is that you write once, for 500. Four thousand characters of App Store note is a page of text nobody scrolls, and keeping two different notes per release is a job that quietly stops getting done by the third week. Draft the Play version, paste it into Apple, move on. That also means the note gets written while the change is still fresh in your head, rather than at the end of a submission when you are tired and the honest answer is that you cannot remember what you fixed.

Neither of these boxes costs money, and neither of them is where the money goes. If you are still working out the bill for getting an app onto a store at all, the numbers are in what it costs to publish an app. The note is free. It is also the one piece of your listing you rewrite every single release, which makes it the only part anybody sees change.

Apple, App Store Connect Help, platform version information, read 16 October 2026

Draft it here

What fits in the box each store gives you

Tick what changed in this release. The counter is the real Google Play ceiling, 500 Unicode characters per language, against Apple's 4000.

Fixed the crash when you opened a saved order that had no items in it.

The booking list now loads in about a second on older phones instead of five.

Google Play

148 of 500 characters, per language

App Store

148 of 4000 characters

Both boxes take this. Write for the smaller one and the larger one never bites.

What are you not allowed to put in them?

Google is explicit, and it is the only wording rule either store states at this step. Play Console help says to inform users about recent updates made in your release, and warns against using release notes for promotional purposes or to solicit user actions. Read that twice, because it covers more than it looks like it covers. A line offering twenty percent off this week is promotional. So is a line asking people to rate the app, to follow an account, or to tell a friend. So is a line about a funding round. If the sentence would work in an advert, it does not belong in this field.

That restriction is a gift once you stop reading it as a restriction. The field is small, somebody is reading it with their thumb already on the button, and you have been told to use it for one purpose. Four sentences of what changed will beat anything clever. Lead with the fix that affects the most people. Name the screen it happened on, because that is how the person remembers it. Put the new feature second, because a new feature is a reason to update and a broken thing getting fixed is a reason to update now.

Apple's version reference carries no equivalent wording rule for What's New, which is not the same as saying anything goes. The note is part of the version you submit, so it travels in front of review with the build, and review looks at metadata as well as code. A note that promises a feature the build does not contain is the cheapest way to turn a working release into a rejected one. If that has already happened to you, the path back is in appealing a rejection, and the fastest version of it is usually to fix the sentence rather than argue about it.

One more thing worth being careful about: a known problem you leave in the note. Saying that photo upload still fails on slow connections is honest, it stops a wave of duplicate reports, and it is description rather than promotion, so it sits inside the rules. It also tells every reader that you know. The cost is that it is now written down, in public, in eight languages, until the next release replaces it. Say it when it is true and when you mean to fix it.

Google, Play Console Help, prepare and roll out a release, read 16 October 2026

What happens when you ship in more than one language?

The two stores solve this in opposite ways, and the Google answer is the one that catches people. On Google Play every language goes into the same box, separated by language tags. Google's help page says to place language tags on separate lines from the release notes, and its example wraps an en-US block around notes that can run over several lines. So one text area holds every translation you support, tags and all, and a stray tag breaks the block it was meant to open. Changing which languages are available means adding translations to the app first, not editing the tags.

Apple treats it as metadata, which it already handles per language everywhere else. Its reference marks What's New in This Version as a property that can be localized, so each App Store language has its own field and its own 4000 characters. That is easier to get right and slower to fill in. There is no copy-from-last-release control documented on Apple's side, so the App Store note is typed or pasted each time.

The Copy from a previous release button on Google Play deserves a warning of its own. It brings in the notes and the translations from an earlier release and replaces what is in the box. For a hotfix that repeats most of last week, that is the right move. For a release with one new line, it is how the note for version 14 ends up describing version 13 in nine languages, because you edited the English block and scrolled past the rest. Copy, then read the whole box from the top before you save.

If you only ship in one language, none of this is work. Write the 500 characters, paste them into Apple, done. The moment you add a second language the note becomes a small translation job per release, and it is worth deciding up front whether you will actually do it or whether you would rather ship fewer languages honestly than nine languages with eight of them describing a release from February.

Google, Play Console Help, prepare and roll out a release, read 16 October 2026

Can you fix the note after the release is out?

Neither store documents a way to do it, and this is the one place where honest beats confident. On the App Store, What's New in This Version is version information. Apple's reference says the property is not available for the first version of the app but is required for all subsequent versions, and it is silent on changing the text once that version is out. The field Apple does document for copy you expect to change between releases is promotional text, which it caps at 170 characters and describes as letting you inform App Store visitors of any current app features without requiring an updated submission. That carve-out is the tell. If the rest of the metadata could be rewritten freely, the carve-out would not need to exist.

On Google Play the notes belong to a release rather than to the listing, and the help page describes editing a release you have not shipped yet: open the track's Releases tab, click Edit under the release, and work through the preparation and preview screens again. It does not describe rewriting the notes on a release that is already rolled out. Worth knowing alongside it: Publish pushes changes live immediately, while Save adds them to the Changes ready to send for review section of the Publishing overview page, where you choose when to submit them. Those are different buttons with different consequences, and the time to learn which is which is not the hour after a bad release.

So the working rule is that a release note is part of the release. Write it before you press the button, not after. Two habits make that cheap. Keep a running file in the repository that gets a line every time you merge something a user would notice, so the note is assembled rather than remembered. And put the 500 character draft in the pull request, where somebody can read it before it is a public sentence in nine languages.

That file matters for a reason beyond this release. Notes are the only running account of what the app did over a year, and the person who inherits the project reads them before they read your code. If the app ever moves, it travels with its own history: transferring an app to another account moves the app record, which is where every note you have ever written lives.

The same note, measured by each store

The question	App Store, What's New	Google Play, release notes	Same on both
What the box is called	What's New in This Version	What's new in this release?	No
How much text fits	Limited to 4000 characters	Up to 500 Unicode characters per language	No
Offered on your very first release	No, not available for the first version	Yes, the notes box is there	No
Required after the first one	Required for all subsequent versions	Listed as a step, not stated as required	No
Written once per language	Yes	Yes	Yes
One click to reuse the last notes	No	Copy from a previous release	No
Rule against promotional wording	Not in the version reference	Yes, stated in the release notes step	No

Field names and limits as documented by Apple and Google, read 16 October 2026. Where a row says not stated, that is the documentation's silence and not a permission.

Where this lands if a builder generated your app

Nothing about the note changes because an AI wrote the code. The 500 characters are still yours to write, because only you know which of this week's changes a customer will notice. What does change is how easy it is to find out what shipped. A builder that hands you a repository gives you a commit history to read the note out of. A builder that hands you a running app and nothing else leaves you guessing at the end of the week.

Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own, with two-way GitHub sync, so the diff behind every release is sitting in your own repository where you can read it. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, and builds a standalone Android APK. It is $25 a month, with no free plan. For the note, the sync is the part that matters: the changes are in commits with messages, and a week of commits is a first draft of a release note.

The honest limit is the same one every builder has. Newly does not submit to the App Store for you, because App Store Review Guideline 4.2.6 rejects apps created from a commercialized template or app generation service unless they are submitted directly by the provider of the app's content. You press submit, which means you also fill in the note. No tool can write it for you, because no tool knows which of the ten things that changed is the one somebody has been waiting three weeks to hear about.

Questions people ask about writing release notes

Two different boxes, and one is eight times the other. On the App Store the field is called What's New in This Version, and Apple's own version reference says it is limited to 4000 characters. On Google Play the Play Console help page for preparing and rolling out a release says you can enter release notes using up to 500 Unicode characters per language. Both figures were read on 16 October 2026. The 500 is per language rather than shared across all of them, so adding a language does not eat anyone else's budget. Write for 500 and the App Store box is never the thing that stops you.

Write the note while you still remember what you fixed

Keep a line per user-visible change as you merge it, draft the 500 characters against the smaller box, and the release note stops being the last tired thing you type before pressing submit.

Start building