How to Write App Store Release Notes (What's New)

Quick answer: "What's New in This Version" is the release-notes field App Store Connect requires for every version after your first. It holds up to 4,000 characters and appears on your product page. Lead with the most important user-facing change, list features in order of importance, keep fixes short and specific, and follow Guideline 2.3.12: significant changes must be described, not hidden behind "bug fixes."

App Store Connect describes What's New as "a description of the changes in this version of the app, such as new features, UI improvements, or bug fixes." Apple adds that the text appears on your product page and where people see available updates.

The App Store rule that matters most is Guideline 2.3.12: apps "must clearly describe new features and product changes" in What's New. Simple bug fixes, security updates and performance improvements may use a generic description, but more significant changes must be listed.

Write your notes before you submit. Once a version is live, its What's New text stays until your next version, so anything that needs to change sooner belongs in promotional text.

Release notes have two audiences:

• Existing users deciding whether a new version is worth opening, or looking for the feature they asked for in a review.
• Potential users scrolling your product page. A recent update with a clear, specific note signals an app that's actively maintained.

Release notes also close the loop on feedback. If people asked for dark mode in reviews and you shipped it, saying so in What's New, and replying to those reviews, shows you listen. Our guide on how to respond to app reviews covers the reply side.

Apple doesn't list What's New among the text fields it matches for search, so write it for people, not for keywords.

Apple recommends listing "new features, content, or functionality in order of importance" and adding call-to-action messaging that gets users excited about the update. A structure that does both:

1. Lead sentence. The single most important change, in user terms. "Meet Focus Blocks" beats "Version 4.0."
2. New features. Two to five lines, most important first. Say what people can do now, not how you built it.
3. Improvements. Faster, clearer or easier things, described by the effect people notice.
4. Fixes. Short and specific when the bug was visible to users: "Fixed a crash when opening shared budgets on iPad."
5. Where to find it. A short pointer such as "Try it from the Plan tab" or "Turn it on in Settings > Appearance."

These examples are written for hypothetical apps.

A full example

For a hypothetical to-do app's major release, the complete note might read:

• Meet Focus Blocks: drag any task onto your calendar and Taskloom protects that time with a reminder before it starts.
• New Home Screen widget: see your next three tasks at a glance.
• Faster sync between iPhone and iPad.
• Fixed: recurring tasks no longer duplicate after you edit them.
• Find Focus Blocks in the Today tab. Tell us what you think from Settings > Feedback.

Five lines, most important first, every line written from the user's side.

Tone is a brand choice, but clarity is not optional. Here's the same fix in three tones:

Even the playful version names the actual change. Jokes that replace information ("Squashed some bugs, enjoy!") don't help users and can fall short of Guideline 2.3.12 when the release includes real changes.

• "Bug fixes and performance improvements" for a big release. Apple allows generic text only for simple fixes; significant changes must be listed.
• Internal jargon. Ticket numbers, "refactored the sync layer" or library names mean nothing to users.
• Raw changelogs. A 40-line list buries the one change people care about.
• Promising what isn't in the build. Describe what this version contains, not what's coming next month.
• Mentioning other platforms. "Now on Android too!" conflicts with Guideline 2.3.10, which keeps other mobile platforms out of your metadata.
• Skipping localization. Localized product pages with English-only notes feel unfinished. Our App Store localization guide covers which fields to translate first.
• Pasting the same text every release. If nothing user-facing changed, say so briefly; if something did, describe it.

On Google Play, release notes are part of each release in Play Console, with up to 500 Unicode characters per language. You can paste several languages at once by wrapping each in language tags such as <en-US> and </en-US> on their own lines.

Google's help page says not to use release notes for promotional purposes or to solicit user actions. So "Rate us 5 stars!" or "50% off this week" don't belong there. Use the 500 characters for the two or three changes that matter most.

A practical workflow for both stores: write the full App Store note first, then cut it down to the top changes for Google Play. For the rest of your Play listing, see our Google Play store listing guide, and for how release notes fit into your overall strategy, read the App Store Optimization guide.