How to Write App Store Release Notes People Actually Read

"Bug fixes and performance improvements." Every iPhone user has read that line a thousand times, and it has taught them to skip release notes altogether. That is a waste, because the "What's New" text is the one place where someone who updates your app can learn what changed and why it matters to them. This guide covers Apple's rules for it as of 16 April 2026, a structure that people read, and how to credit the users who asked for a feature.

Shipping on Android too? The Google Play version of this guide is Google Play Release Notes: Writing What's New in 500 Characters.

The short version

• "What's New in This Version" holds up to 4,000 characters, can be localised, and is required for every version after the one you launch with.
• Guideline 2.3.12 says significant changes must be listed. A generic line is acceptable for small fixes.
• Lead with the change people asked for, in their words, and keep each change to one line.
• Credit requests honestly: "the most requested feature on our board" is better than naming anyone.
• Release notes reach people who open the update page. Tell the people who asked directly as well.

What Apple requires

Apple's reference page on platform version information describes the field. As of 16 April 2026, "What's New in This Version" is a description of the changes in the version, such as new features, UI improvements or bug fixes. It is limited to 4,000 characters. It isn't available for an app's initial version, and it is required for all later ones. It can be localised. Apple recommends giving detailed information so users know the specifics of the changes.

The App Review Guidelines, 2.3.12, set the rule App Review checks: apps must clearly describe new features and product changes in their "What's New" text. Simple bug fixes, security updates and performance improvements may use a generic description. More significant changes must be listed.

Don't confuse it with two neighbouring fields:

• Notes for Review is for App Review, not users. Guideline 2.3.1 asks you to describe every new feature there specifically.
• Promotional text sits above your description on the product page, holds up to 170 characters, and can be changed without submitting a new version. It is a good place to keep a recent headline feature visible for longer.

A structure that gets read

Write so the opening line works on its own, because many people read no further.

1. A headline line. The single most useful change, as a plain statement. "Offline maps are here." Not "Version 4.2".
2. One or two sentences on why it matters. What the user can now do that they couldn't before.
3. Other changes, one line each. Start each line with the thing, not with "We".
4. Fixes, grouped. Name the fixes people noticed, such as a crash on sharing, and group the rest.
5. A way back to you. Where in the app to send feedback or ideas.

An example

Here is a sample for a fictional hiking app:

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
• Trail difficulty filter: show easy, moderate or hard trails.
• Elevation profile on every hike summary.

Fixed
• Sharing a hike with no photos no longer crashes the app.
• Faster map loading on older iPhones.

Thanks to everyone who voted. Send your next idea from
Settings > Suggest a feature.

Crediting user requests

Saying "you asked for this" is the cheapest way to show users their feedback goes somewhere. A few rules keep it honest:

• Use numbers you can stand behind. "248 votes" or "our most requested feature" is checkable. "Everyone wanted this" isn't.
• Don't name individuals unless they have agreed. Release notes are public, and a username in them can surprise the person.
• Say what you built, not what you hoped to build. If you delivered part of a request, say which part.
• Don't preview unfinished work. Guideline 2.3.1 treats promoting content or services an app doesn't actually offer as misleading marketing. Talk about what is in the version.

Apple's page on ratings, reviews and responses makes a related point, as of 16 April 2026: when an update fixes issues mentioned in older reviews, include that in your release notes and consider replying to those reviews to tell people about the fix.

Things to avoid

• The generic line on a big release. It throws away the one moment users look, and guideline 2.3.12 doesn't allow it for significant changes.
• Internal names. Users don't know what "Project Atlas" or "the sync refactor" means.
• Jokes in place of information. A funny line is fine after the facts, not instead of them.
• Forgetting other languages. If your product page is localised, localise the notes too, or at least the headline.

If the release goes out over a week, our guide to phased release on iOS covers how the rollout works and when to announce.

How FeedbackKit fits in

FeedbackKit doesn't write release notes or publish a changelog for your users. The "What's New" text is yours. What FeedbackKit gives you is the evidence behind a line like "248 votes on our feature board", because users vote on requests inside your app and you can see the count for each one.

It also covers the gap release notes leave. Many people never open the update page, 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. Slack updates for your team need Pro.

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. If you are adding a board, start with the Swift docs, and see our guide to the App Review Guidelines for what a public board needs.

If you want your next release notes backed by real votes, start free.