App Store release notes examples: write What's New text that tells users what changed (2026)

Good App Store release notes answer one question: what is different for me after I update? The App Store release notes examples below all follow one pattern. Lead with the change the user will notice, name each fix specifically, and leave out anything they can't see. Apple's own guidance for the What's New in This Version field says the same thing. It asks for new features, UI improvements or bug fixes and recommends telling users "the specifics of the changes, improvements, or fixes in the version."

What are the release notes rules in App Store Connect and Google Play?

Apple's What's New field allows 4,000 characters and is required on every version after the first. Google Play allows 500 Unicode characters per language and bans promotional content.

As of October 2026, Play Console Help says: "Do not use release notes for promotional purposes or to solicit user actions." On Apple, put marketing copy in Promotional Text instead. That field allows 170 characters, appears above your description, and Apple lets you update it without submitting a new version.

What do good App Store release notes look like?

Good release notes name the situation the user was in and the result they now get. The examples below come from a fictional habit-tracking app. The vague versions are the kind of notes that get written at the last minute.

If a fix is too technical to explain in one sentence, users probably won't notice it, so it can go under a single "stability improvements" line at the end. Guideline 2.3.12 allows that for minor fixes but not for real feature changes.

Is there a release notes template I can reuse?

Yes. A reusable template has a headline, then New, Improved and Fixed sections. Keep it in your repository next to the changelog and fill it in when you cut the release branch, not after the build has uploaded.

[One-line headline: the change most users will notice]

New
- [Feature]: [what you can now do], [where to find it]

Improved
- [Screen or flow]: [what feels different]

Fixed
- [Symptom the user saw] when [situation]

Thanks for the reports. Reply via Settings > Help if anything looks off.

For Google Play, cut the same notes down to the headline plus the top two or three bullets so they fit in 500 characters. Put each language's tags on their own lines, for example <en-US> and </en-US>. Drop the closing line on Play, because it asks the user to do something.

How do you turn merged pull requests into release notes?

To turn merged pull requests into release notes, filter out changes users can't see, then rewrite each remaining change as a symptom or outcome. Follow these steps for every release.

1. Export the merged pull request titles since the last tag, then delete anything users can't see, such as refactors, dependency bumps and CI changes.
2. Rewrite each remaining item as a symptom or an outcome. "Fix nil coordinator" becomes "Fixed a blank screen after signing in with Apple."
3. Order the items by how many users they affect, not by how much engineering work they took.
4. In App Store Connect, create the new version, then clear the copied What's New text before you paste the new notes, because the previous version's metadata carries over.
5. Paste the notes into every localization you support, translated or at least checked in each language, so users in other locales don't see last version's notes.
6. For Play, paste the shortened version inside the language tags and confirm each language stays under 500 characters.
7. Read the notes aloud once. If a sentence needs a developer to explain it, rewrite it.

What should release notes say for a hotfix?

Hotfix release notes should name the broken version, describe the symptom that is now fixed, and tell affected users what happens after they update. Apple doesn't let you revert to a previous version on the App Store, so a fix always ships as a new version.

An example: "Fixed an issue in 3.4.0 where reminders stopped firing for some users. Reminders you set before updating will resume automatically." Users who were affected know to update, and users who weren't can tell the fix doesn't concern them. Don't blame the operating system and don't promise dates for future fixes. If you ship updates with a phased release, pausing the rollout limits how many users get the broken build while the fix is in review. If the hotfix changes how a feature behaves, run through the App Store submission checklist again so notes, screenshots and review notes match.

Can App Review reject an update because of its release notes?

Yes. Release notes are metadata, and the App Review Guidelines cover them directly. Guideline 2.3.12 says "Apps must clearly describe new features and product changes in their "What's New" text."

Generic wording is allowed for "simple bug fixes, security updates, and performance improvements," but "more significant changes must be listed in the notes." Guideline 2.3.10 bans names or imagery of other mobile platforms in metadata, which includes What's New. Don't describe features hidden behind flags or anything that isn't in the submitted build. Guideline 2.3.1(a) separately requires new features to be "described with specificity in the Notes for Review section," so put reviewer steps and a demo account there, not in public notes. If you do get a metadata question, our guide to App Store rejection fixes explains how to reply.

What release notes problems have other developers hit?

Publicly reported cases show two failure types: uploads rejected for going over a store's length limit, and review rejections that include What's New text in their cleanup instructions.

• Play length limit in CI. A GitHub issue in a Flutter deployment template reports an AI-generated changelog that broke a Google Play internal test upload through fastlane with: "The release created has notes in language ko-KR with length 612, which is too long (max: 500)." The maintainers added a script that truncates notes before upload: 480 characters for Play and 3,800 bytes for TestFlight, which measures its limit in bytes.
• 2.3.10 cleanup that includes What's New. A developer on the Apple Developer Forums posted a Guideline 2.3.10 rejection triggered by non-iOS status bars in screenshots. Apple's next steps said to "remove all instances of this information from your app and its metadata, including the app description, promotional text, What's New info, previews, and screenshots." Replies advised retaking screenshots and checking every metadata field, release notes included.

The takeaway: the length limit is mechanical and fails loudly at upload, while review rules are about content and apply to every metadata field. Automate a character check, and read What's New with the same care as your screenshots.

What should you check before submitting release notes?

Before submitting, check that the notes describe only what is in the build, fit each store's limits and replace last version's text in every language.

• The headline names the change most users will notice.
• Every significant feature or product change is listed, as guideline 2.3.12 requires.
• Every fix describes a symptom the user saw, not internal code.
• No features behind flags, no future promises, no internal ticket numbers, no other platform names.
• Previous version's What's New text cleared and replaced in every localization.
• Play notes are under 500 characters per language, wrapped in correct language tags, with no promotion or calls to action.
• Marketing messages moved to Promotional Text on Apple.
• If you're also running Android testers, the same notes have been checked against your closed testing plan.

If you'd like a second pair of eyes on your update metadata before submitting, email yagyeshsrbobde@gmail.com with your draft notes and the list of changes in the build, or see our services.