What Are Release Notes, and Where Do They Show?
Release notes are the short text that tells people what changed in a new version of your app. On the App Store the field is called What's New in this Version. Apple describes it as a description of the changes in the version, such as new features, interface improvements or bug fixes, in its reference for platform version information.
The text shows in two places on the App Store: on your product page and on the Updates tab, according to Apple's product page guidance. On Google Play you type it into a box labeled "What's new in this release?" when you prepare a release, and Google's instruction is to use it to tell users about recent updates, as the Play Console Help page on releases puts it.
People also call them app update notes, patch notes, a changelog or simply the What's New text. They are all the same job: one version, a few lines, written for the person using the app and not for the team that built it.
App Store Release Notes Character Limit and Google Play Limit
The two stores give you very different amounts of room. Write the short version first, then expand it for the App Store if the release deserves more.
| Field | Store | Limit | What to know |
|---|---|---|---|
| What's New in this Version | App Store | 4,000 characters | Not available for the first version of an app, required for every version after that, and can be localized, per Apple's platform version information. |
| What's new in this release? | Google Play | 500 Unicode characters per language | Google says not to use release notes for promotional purposes or to solicit user actions. The limit and the rule are in Play Console Help. |
| Promotional text | App Store | 170 characters | Appears above your description and can be changed at any time without a new version, per Apple's product page guidance. Useful for news that cannot wait for a release. |
| Release name | Google Play | Internal only | The release name is used only inside Play Console and is not visible to users, so it is not a place for notes. |
Checked on October 11, 2026. On the App Store, Apple's list of required, localizable and editable properties does not mark What's New as editable without submitting a new version, so proofread before you submit.
Who Reads App Update Notes
Fewer people than you hope, but the ones who matter most. Apps from the App Store update automatically by default, as Apple Support's page on updating apps explains, so many users get the new version without ever opening the list of updates. The ones who do read are your most engaged users: the person waiting for a specific bug fix, the person deciding whether to come back, the person who just hit a problem.
Shoppers read them too. What's New sits on the product page, so someone comparing two apps can see when yours was last updated and whether the notes sound like a team that cares. A page of identical one line notes tells that visitor very little.
App Review reads them as well. Guideline 2.3.12 of Apple's App Review Guidelines says apps must clearly describe new features and product changes in the What's New text. The same rule allows a generic description for simple bug fixes, security updates and performance improvements, but says more significant changes must be listed.
The last readers are inside your company. Support agents, the person writing the newsletter and whoever posts on social media all start from the release notes. Clear notes save each of them from asking engineering what shipped.
App Release Notes Examples for Routine Updates
These four cover most releases. Every example on this page is original, written for an invented app, and under 500 characters. Swap in your own features and numbers. On the store, put each point on its own line.
Bug Fix Release
Fixed a crash that happened when you opened a shared list while offline. Fixed reminders that arrived an hour late after the clock change. Fixed the widget showing yesterday's tasks until you opened the app. Thank you to everyone who sent a report. You made these easy to find. Why it works: each bug is named the way a user would describe it, so the person who hit it knows this update is for them.
One Big Feature
New: shared budgets. Invite your partner or a roommate to a budget and you both see every expense the moment it is added. Each person keeps a private budget too. To try it, open any budget, tap Share and send the invite. Also in this version: faster search and a fix for duplicate bank imports. Why it works: one feature gets the first line and the instructions, and the small items wait at the end.
Several Small Improvements
Five small things you asked for. 1. Sort notes by the date you last edited them. 2. Pin up to three notes to the top. 3. Export a note as a PDF from the share menu. 4. Larger buttons in the toolbar. 5. Dark mode now follows your phone's schedule. Why it works: a numbered list with one sentence each is quick to scan, and the opening line tells users their requests get read.
Performance Release
This one is all about speed. The app now opens in about half the time on older phones. Photo uploads keep going in the background, so you can lock your screen. The download is 30 MB smaller. No new features this time, only a faster app. Why it works: it gives numbers instead of the word faster alone. Only publish figures you measured.
App Store Release Notes Examples for Big Changes
Big changes are where vague notes hurt most. These are the releases people notice, so say plainly what changed and what stayed the same.
Redesign
A new look, the same app. The four tabs are now three: Home, Search and Library. Your downloads moved into Library. Settings moved behind your profile picture in the top right. Nothing was removed, and your playlists are exactly where you left them. Tell us what you think from Settings, Send Feedback. Why it works: it answers the first question after any redesign, which is where a familiar button went.
Pricing Change
Two changes to plans. The free plan now includes 3 projects instead of 1. The Pro price for new subscribers changes on March 1. If you already subscribe, your price stays the same. This version also adds project templates and fixes a sync delay on slow connections. Why it works: it says who is affected, who is not and when, with no amount that would be wrong in another country's currency.
Apology After an Outage
We got version 4.2 wrong. For about a day some of you could not sign in, and a few people lost drafts that had not synced. This version fixes the sign in error and restores those drafts from our backup the first time you open the app. If something is still missing, write to help@example.com and a person will answer. We are sorry. Why it works: what broke, who was hit, what is fixed and how to get help, with no excuses.
Removing a Feature
Heads up: this version removes export to the old CSV format. The newer export has the same columns plus categories, and it opens in the same spreadsheet apps. Exports you already saved are not affected. If your workflow needs the old format, write to us from Settings, Feedback before you update. Why it works: a removal is the change people are angriest to find by themselves, so it goes first and comes with an alternative.
Security Fix
This update fixes a security issue in how the app stored your login on your device. We have no sign that anyone's account was accessed. You will be asked to sign in once after updating. We recommend installing this version today. Why it works: Apple allows a generic line for security updates, but explaining the extra sign in heads off a wave of support email.
Release Notes Examples by App Type and Moment
The same rules apply to every app, but a game, a subscription app and a brand new app each have their own thing to get right.
First Release of a New App
Welcome to version 1.0. Track your runs with GPS, see pace and distance on one screen, and save every route to a private history. No account needed. This is our first release, so we read every message. Use Settings, Contact Us to tell us what to build next. Why it works: a first version has no changes to list, so it says what the app does in three verbs and opens a line for feedback. Use it on Google Play. The App Store has no What's New field for a first version.
Seasonal Update
Winter update. New: a holiday gift list you can share with family, with a checkbox that hides what is already bought. New: three winter themes for your home screen widget. The gift list stays in the app all year under Lists. Also fixed: prices now show in your local currency after you change region. Why it works: seasonal features raise the question of what disappears in January, and the note answers it.
New Version of a Game
Season 5 is live. Explore the Frozen Harbor, a new region with 20 levels and a boss you fight on moving ice. New weapon: the harpoon, earned at level 8. Daily quests now pay double coins on weekends. Balance: the shield cooldown goes from 6 to 8 seconds. Fixed invites that expired after one minute. Why it works: players read notes for new content first, then balance changes with exact numbers, then fixes.
Subscription App
New for subscribers: download workouts to use without a connection, and a weekly plan that adapts when you skip a day. Free for everyone: a stretching library with 12 short routines. Subscribers get the new features automatically. Nothing changes about your billing. Why it works: it separates what paying members get from what is free, and it calms the worry every subscriber has when an update mentions plans.
Accessibility Update
Better support for VoiceOver and larger text. Every button on the player now has a spoken label. Text follows your system size setting up to the largest option without being cut off. Charts have a text summary that can be read aloud. Color is no longer the only way to tell income from spending. If something is still hard to use, please tell us. Why it works: it names the exact settings people rely on, so they can tell whether the app works for them now.
More App Update Notes Examples: Hotfixes, Betas and Migrations
Six releases that do not fit the usual pattern of new, improved and fixed. Each is under 500 characters.
Same Day Hotfix
Version 2.8.1 fixes a problem in yesterday's update: the camera button did nothing on some phones. If scanning stopped working for you, it works again now. No receipts were lost, because nothing was saved while the button was broken. Sorry for the lost day. Why it works: it names the version that broke things, says who was affected and answers the data question before anyone has to ask.
Feature Marked as Beta
New, in beta: voice notes. Hold the microphone button to record, and the app writes a transcript under the audio. It works in English for now and can mishear names. Turn it on under Settings, Beta Features, and tell us where it gets things wrong. Also fixed: tags with spaces now save. Why it works: the feature is in this build and the user switches it on, so the note is accurate, and its limits are stated up front.
Update That Needs Something From the User
Important: the first time you open this version, the app moves your library to a new format. That takes up to a minute for a large library. Keep the app open until the progress bar finishes. Nothing is deleted, and the old copy stays on your phone for 30 days. After that, search is about three times faster. Why it works: the instruction comes first, the fear of losing data is answered, and the payoff closes the note.
Now on a Bigger Screen
Now built for iPad. In landscape you get two columns: notebooks on the left, the page on the right. Drag a photo in from another app. Works with a keyboard, including shortcuts for new page, search and bold. Your notes sync from your phone the first time you sign in. Why it works: a new device is a feature, and the note says what is different on it instead of only that it exists.
Content Update With No New Features
40 new recipes for autumn, including 12 that take under 20 minutes. New collection: one pot dinners. We also corrected the cooking time on the lentil soup (35 minutes, not 15) after three of you wrote in. No changes to how the app works. Why it works: in an app people open for its content, the content is the release, and it deserves numbers too.
TestFlight Beta Notes
What to test in build 412: the new checkout. 1. Add two items and pay with the test card. 2. Close the app in the middle of payment and open it again. 3. Try a discount code. Known issue: the receipt email is not sent yet. To send feedback, take a screenshot in the app. Why it works: testers get tasks, where store users get a changelog. Apple's TestFlight overview says test information can include an explanation of the features to test, and that testers can send feedback by taking a screenshot in the beta app.
App Release Notes Template: Fill in the Blanks
Use only the lines that apply. A release with one fix needs one line. Replace the words in square brackets.
| Line | Fill in the blank | When to use it |
|---|---|---|
| Theme | This version is about [one idea in three or four words]. | When the release has a clear focus, such as speed or sharing. Skip it for a mixed bag. |
| New | New: you can now [do what] from [where in the app]. | A feature that did not exist before. Say where to find it. |
| Improved | Improved: [screen or feature] now [measurable change]. | Something existing that got better. Give a number if you measured one. |
| Fixed | Fixed: [what went wrong, in the user's words] when [situation]. | Any bug a user could have noticed. |
| Changed or removed | Changed: [feature] moved to [new place]. Removed: [feature], use [alternative] instead. | Anything a returning user will look for and not find. |
| Thanks | You asked for [request]. It is in this version. | When feedback led to the change. |
| Help | Something not right? Write to [support address]. | After a rough release, or on a first version. |
The New, Changed, Removed and Fixed labels follow the types of changes used by Keep a Changelog, a published convention for writing changelogs.
What Should Be Included in Release Notes: A Checklist by Release Size
The template above lists the lines you can use. This table says which of them a given release needs. Apple's own advice for the field is to give detailed information so users know the specifics of the changes, improvements or fixes, in its platform version information reference. The right amount of detail depends on what kind of release it is.
| Kind of release | Must include | Include if it is true | Leave out |
|---|---|---|---|
| Patch or hotfix | Every bug a user could have hit, named by its symptom. If it repairs a recent update, the version that broke. | Who was affected, and whether any data was lost or restored. | The cause in engineering terms, ticket numbers and the name of the library at fault. |
| Feature release | The new feature in the first line: what it lets people do and where in the app to find it. | That users asked for it. Whether it is free or only for subscribers. | Features that are built but still switched off for most people. |
| Redesign or major version | What moved, what was removed and what to use instead. | How to send feedback, because a redesign always produces some. | Adjectives such as fresh or reimagined in place of where things went. |
| Security or privacy fix | That the update fixes a security issue, and anything the user has to do, such as signing in again. | Whether there is any sign of misuse, but only when you actually know. | Technical detail that would help someone exploit people still on the old version. |
| Price or plan change | Who is affected, who is not and from what date. | What current subscribers keep, and where to manage the subscription. | An amount in one currency, which is wrong for everyone who pays in another. |
| Content update | What was added, with a count: levels, recipes, lessons, maps. | Corrections to existing content, if people reported them. | A list of every item when a number and two examples say the same thing. |
When a release fits two rows, use both: a feature release that also fixes a security issue leads with the feature and still states the fix plainly.
One Release Written for Four Places
Here is the same invented update, version 3.4 of a budgeting app, cut to fit each place it has to appear. Writing the four together takes ten minutes and keeps them consistent.
| Where | Room you have | Example |
|---|---|---|
| App Store, What's New | 4,000 characters | New: shared budgets. Invite your partner or a roommate to any budget and you both see every expense the moment it is added. Each person can still keep private budgets. To start, open a budget, tap Share and send the invite. Improved: search now looks inside notes and finds results as you type. Improved: the monthly report loads in about a second. Fixed: bank imports no longer create duplicate entries after a failed sync. Fixed: the widget now refreshes at midnight. You asked for shared budgets more than anything else this year. Thank you for the push. |
| Google Play, release notes | 500 characters per language | New: shared budgets. Invite your partner or a roommate and you both see every expense as it is added. Improved: search looks inside notes. Improved: faster monthly report. Fixed: duplicate bank imports and a widget that did not refresh. |
| App Store promotional text | 170 characters | New in 3.4: shared budgets. Invite your partner or a roommate and see every expense the moment it is added. |
| Social post caption | Set by the network | Shared budgets are here. Invite one person, and every expense shows up for both of you the moment it is added. Version 3.4 is on the App Store now. |
Weak Release Notes Rewritten: Before and After
Five notes of the kind that fill the Updates tab, each beside a version a user can act on.
| Before | After | What changed |
|---|---|---|
| Bug fixes and performance improvements. | Fixed: the app froze when you rotated a photo. Long albums scroll more smoothly on older phones. | It names the one bug and the one place speed improved. It is still two lines. |
| We update the app regularly to make it better for you. | This version adds a sleep timer to the player. Find it under the three dots while a story is playing. | It says what is in this build. The first note could sit on any version of any app. |
| Implemented OAuth token refresh, resolved race condition in sync queue (#4821). | You no longer get signed out every few days. Fixed a bug that could save the same note twice. | The same two fixes, in the words on the user's screen. |
| HUGE update!!! You are going to LOVE it!!! | New: split a bill with friends. Add people to an expense and the app works out who owes what. | The feature does the persuading. |
| New: dark mode, widgets, family sharing, export, tags, themes and 23 fixes. | New: family sharing. Invite up to five people to your library. Also new: dark mode, widgets, tags and export. Fixed: 23 bugs, including the search crash. | The biggest change gets its own sentences, and the rest follow in order of importance. |
How to Write App Release Notes in Ten Minutes
Do this while the build is processing, before the submit button is in front of you.
- Step 1
List Everything That Shipped
Copy the merged changes for the version out of your tracker. This list is for you, and none of its wording survives to the store.
- Step 2
Cross Out What No User Can Notice
Refactors, dependency updates and build changes go. What remains is new things, changed things and fixes for bugs somebody could have hit.
- Step 3
Sort by Importance and Rewrite in the User's Words
Put the biggest change first, the order Apple's product page guidance recommends for What's New. For each line, write what the person can now do or what has stopped going wrong.
- Step 4
Cut a Google Play Version
Trim to 500 characters on purpose and keep the first line whole. Count it before you paste it into Play Console.
- Step 5
Proofread Twice
What's New is not on Apple's list of fields you can edit without a new version, so a typo stays on your product page until the next release.
How to Add or Change Release Notes in App Store Connect
Where the text goes, what you can still change once it is submitted, and how teams that ship often skip the web form entirely. Checked against Apple's help pages on October 17, 2026.
- Step 1
Create the New Version
In Apps, select the app, click the add button next to the platform and enter the new version number. Apple's page on creating a new version adds that the current version must be Ready for Distribution before you can start the next one, and that the roles allowed to do it are Account Holder, Admin, App Manager and Marketing. So whoever writes the notes may not be the person who uploads the build.
- Step 2
Read Every Field the New Version Inherited
The same page says metadata from the current version is transferred to the new version automatically. Go through the version page field by field before you save, What's New included, so that nothing from the last release is submitted again by accident.
- Step 3
Write What's New for Each Language
What's New is a localizable field of up to 4,000 characters, per Apple's platform version information. Switch languages in the menu on the version page and paste each translation into its own box. A language you skip shows the primary language's notes.
- Step 4
Change Notes While the Version Is in Review
While a version waits for review or is in review, Apple only lets you edit some of its information. To change everything, remove the submission from review. That is possible from Waiting for Review, In Review, Pending Developer Release and two other statuses, and it sets the version to Developer Rejected. Edit the notes and submit again. Apple notes that the review then starts over, so allow for another round before your release date.
- Step 5
Correct Notes After the Version Is Live
What's New is marked required and localizable but not editable in Apple's list of required, localizable and editable properties, so a live version keeps its notes. Fix the mistake in the next version's notes. Until then, use promotional text, the 170 character line above your description that you can change at any time.
- Step 6
Set the Notes From a Script Instead
Teams that release weekly often never open the form. The App Store Connect API request to modify an app store version localization accepts a whatsNew attribute for each language. The fastlane deliver action reads the notes from a release_notes.txt file in a folder for each language, and can apply one default text to every language that has no file of its own. Either way, the same rules apply: one text per language, written for users.
Video: How to Submit an App Update in App Store Connect
If you have never released a second version, this shows where the version form sits before you write a word of it.
Release Notes Do and Do Not
| Do | Do not | Why |
|---|---|---|
| List changes in order of importance, biggest first. | Open with the version number, a greeting or a joke. | Ordering by importance is Apple's own advice for What's New in its product page guidance. |
| Name the feature you added. | Write "bug fixes and performance improvements" on a release that adds something. | Guideline 2.3.12 allows a generic line only for simple fixes, security updates and performance work. |
| Describe what is in this build today. | Announce features that are still switched off or coming later. | Section 2.3 of the same guidelines asks for metadata that accurately reflects the app, and users will look for what you promised. |
| Keep Google Play notes to plain information. | Ask for ratings or push a sale in Google Play release notes. | Google tells developers not to use release notes for promotion or to solicit user actions, in Play Console Help. |
| Say when feedback led to a change. | Hide a fix because it admits there was a bug. | Apple suggests using What's New to show users you listened when a feature or fix came from their feedback. |
| Write in the words on the user's screen. | Paste ticket numbers, commit messages or internal code names. | Keep a Changelog makes the same point about changelogs: they are for people, and a dump of commit logs is noise. |
| Leave out exact prices. | Quote a dollar amount in notes that every country sees. | Apple gives this advice for the app description: a price written into the text may not be accurate in all regions. The same logic applies to notes. |
| Write a Google Play version of 500 characters or less. | Paste a long App Store note into Play Console and trim whatever does not fit. | The cut usually lands in the middle of a sentence. Write the short version on purpose. |
How to Localize App Release Notes
Both stores let you write different notes for each language. Untranslated notes on a translated listing are an easy thing for a user to spot.
- Step 1
Know What Happens if You Skip It
On the App Store, What's New can be localized. When you add a language, its properties default to those of your primary language, except for the description and keywords, according to Apple's page on localizing app information. So a German listing with no German notes shows your English ones.
- Step 2
Write the Source Text to Be Translated
Short sentences, one idea each, no idioms and no puns. A line such as "Fixed a crash when opening a shared list offline" translates cleanly. A joke about the bug rarely does.
- Step 3
Use the Same Feature Names as the Translated App
If the button says Teilen in the German interface, the German notes must say Teilen too. Give your translator the interface strings, or the notes will send people looking for a button that has a different name.
- Step 4
Leave Room Under the Google Play Limit
Google Play allows 500 characters for each language, and each language's text goes between its own language tags on separate lines, as Play Console Help shows. A translation can run longer than the English, so keep the English well under 500.
- Step 5
Reuse Carefully
Play Console can copy the notes and translations from a previous release into the box for editing, a feature described on the same Play Console Help page. That saves time on a maintenance release, but check every language before you publish, or last month's feature gets announced again.
Google Play Release Notes Too Long? Length, Language Tags and Formatting
Google Play gives you 500 Unicode characters for each language, according to Play Console Help as checked on October 17, 2026. That is an eighth of the room the App Store allows, so the most common reason notes do not fit is simple: an App Store text was pasted in whole. The limit counts each language separately. A long German translation does not use up the English allowance, but it does have to fit in its own 500.
When you paste several languages at once, the format matters as much as the length. Google's help page shows each language's notes sitting between an opening and a closing language tag, with each tag on a line of its own, and it says the notes themselves can run over several lines. Check that every language you paste has both tags and that nothing sits outside them before you start trimming.
To cut a note down to 500 characters without losing what matters, work in this order. Keep the first line whole, because it carries the reason to update. Merge the fixes into one line that starts with Fixed. Drop thank you lines and any request to rate or share, which Google asks you to leave out of release notes anyway. Remove changes that shipped only on iPhone or Apple Watch. Then paste the result into the Release Notes box on the Google Play tab of the App Store character counter to see the count before Play Console does.
Formatting is plain. Google's help page talks about lines of text and language tags and says nothing about bold, links or bullet symbols, so write as though none of it will show. One change per line reads well on a phone, and a word such as New or Fixed at the start of a line does the job a bullet would.
If you release from a pipeline, the notes do not have to be typed into Play Console at all. In the Google Play Developer API, each release in a track has a releaseNotes field that the API reference describes as a description of what is new in the release, given as localized text. The fastlane supply action reads them from a changelogs folder for each language, where each file is named after the version code it belongs to and a default.txt file is used when no file matches. The 500 character limit still applies to whatever the script sends.
How to Reuse Release Notes as a Social Post or Changelog
You already did the hard part, which is deciding what matters in this version. The same few lines can feed four other places.
A Social Post
Pick the two or three points a stranger would care about, lead with the benefit and attach a real screenshot of the feature. Leave out fixes unless the bug was famous. There are worked examples for each network in these app update announcement examples, and a channel by channel plan in how to promote an app on social media.
A Changelog Page on Your Website
Paste each version's notes onto one page, newest first, with the release date. Those are the basics Keep a Changelog recommends: an entry for every version, the latest at the top and the date shown. Unlike the store, your own page keeps the full history readable in one place.
A What's New Screen in the App
App Store updates install automatically by default, so the first launch after an update is the one moment you can be sure they see the news. Show the top one or two points once, with a button to try the feature, and never block the app behind it.
Promotional Text and Store Screenshots
Turn the main point into a line of 170 characters or less for the App Store promotional text, which you can change without a new version. If the release changed how the app looks, update the screenshots in the same submission, using the App Store screenshot sizes reference.
A Phased Release Needs Patient Wording
If you release in phases on the App Store, automatic updates reach people over 7 days, starting with 1 percent on day one, as Apple's phased release page describes. Anyone can still update by hand from the App Store, so a post that says "available now" is true, but "everyone has it" is not.
A Fix Is Always a New Version
Apple states you cannot revert to a previous version on the App Store. If a release goes wrong, you create a new version, and that version gets notes of its own. Write them like the apology example above, and add the lesson to your app launch checklist.
Turn Each Version's Notes Into an App Update Post With Spreadcast
Writing good notes and then telling nobody is the usual pattern. The release goes out, the store updates quietly, and the social accounts stay silent because making the post is one more task.
Spreadcast does that step for you. You paste your App Store link at the start page, and it checks the public listing every day. When a new version appears, it boils the release notes down to two or three points, sets them on a designed image with your app's own screenshot, and publishes the post to the networks you connected, or holds it for one tap of approval. It works with App Store listings today, and Google Play is not supported yet.
The better your notes, the better that post, which is one more reason to stop shipping "bug fixes and performance improvements". For the rest of the plan, read how to market an app and Apple's App Store marketing guidelines explained.
Frequently Asked Questions
What are release notes for an app?
Release notes are a short description of what changed in a new version of an app: new features, improvements and bug fixes. On the App Store they appear as What's New, and in Google Play Console the field is called "What's new in this release?". They are written for users, so they describe changes in everyday words.
What is the App Store release notes character limit?
4,000 characters. Apple's reference for the What's New in this Version field says it is limited to 4000 characters, is not available for the first version of an app and is required for all later versions. See Apple's platform version information, checked October 11, 2026.
What is the character limit for release notes on Google Play?
500 Unicode characters per language, according to Google's Play Console Help, checked October 11, 2026. That is one eighth of the App Store limit, so write the Google Play version as its own short text.
Can I just write "bug fixes and performance improvements"?
Only when that is all the release contains. Apple's guideline 2.3.12 allows a generic description for simple bug fixes, security updates and performance improvements, and requires more significant changes to be listed. Even when it is allowed, naming the fixed bug is more useful to the person who reported it.
Do I need release notes for the first version of a new app?
Not on the App Store. Apple says the What's New field is not available for the first version of an app, so your description and promotional text carry the launch. If you write a note for a first release on Google Play, describe what the app does and how to send feedback, as in the first release example above.
Can I edit App Store release notes after the update is live?
Plan as if you cannot. Apple's list of properties you can edit without submitting a new version does not include What's New. Promotional text is the field you can change at any time, so use that for corrections or news between versions. The list is in Apple's required, localizable and editable properties.
How long should app release notes be?
Long enough to name every change a user could notice, and no longer. For most updates that is two to six short lines, which also fits Google Play's 500 characters. A major version can use more of the App Store's 4,000 characters, with the biggest change first.
What is a good Android app release notes example?
Nearly every example on this page works for Android, because each is under Google Play's 500 character limit (the TestFlight one is for Apple's beta tool). A typical one: "New: shared budgets, invite one person and see every expense as it is added. Improved: search looks inside notes. Fixed: duplicate bank imports." Keep it informational, since Google does not allow promotion or requests for action in release notes.
Can I change release notes while the app is in review?
Only partly. While a version is waiting for review or in review, App Store Connect lets you edit some of its information. To change the rest, remove the version from review, which sets it to Developer Rejected, then edit and submit again. Apple says the review starts over when you resubmit. The steps are on Apple's page about removing a submission from review.
What should be included in release notes?
Every change a user could notice in this version, biggest first: new features and where to find them, anything that moved or was removed, and bugs named by their symptom. Add who is affected when a change only touches some people, such as subscribers or one device. Leave out internal work, ticket numbers and prices written in one currency.
Where These Facts Come From
Every outside number, rule and price on this page links to the page it was taken from.
- Platform version information, including the What's New fieldApple Developer, App Store Connect Help
- Required, localizable and editable propertiesApple Developer, App Store Connect Help
- Localize app informationApple Developer, App Store Connect Help
- Create a new versionApple Developer, App Store Connect Help
- Release a version update in phasesApple Developer, App Store Connect Help
- Creating your product pageApple Developer
- App Review Guidelines, guideline 2.3.12Apple Developer
- How to manually update apps from the App StoreApple Support
- Prepare and roll out a releaseGoogle Play Console Help
- Keep a Changelog, version 1.1.0Keep a Changelog
- TestFlight overview: test information and tester feedbackApple Developer, App Store Connect Help
- Remove a submission from reviewApple Developer, App Store Connect Help
- Modify an app store version localization, including whatsNewApple Developer, App Store Connect API
- deliver: uploading App Store metadata and release notesfastlane docs
- supply: uploading Google Play metadata and changelogsfastlane docs
- Google Play Developer API: edits.tracks and release notesGoogle for Developers
- Video: releasing a new version in App Store ConnectThink Like an Engineer
Researched and written by Spreadcast. Last checked on October 17, 2026.
