How to write App Store release notes people actually read

People do read these

There's a common assumption that nobody reads release notes. That's wrong, but in a specific way. Most casual users don't read them. But the users who do are disproportionately your most engaged ones. They care enough about your app to check what changed. They write reviews. They tell friends. They're the users you most want to keep happy.

There's a second audience too: people browsing the App Store who land on your listing. They scroll down past the screenshots, past the description, and see the "What's New" section. If it says "Bug fixes" and was last updated eight months ago, that tells them the app is probably abandoned. If it has a specific, recent update with real content, that signals active maintenance. It's a trust signal, even if the person never reads the actual text carefully.

Apple also uses update frequency and quality as signals for editorial features. If you're hoping to get featured on the App Store, regular updates with clear release notes show Apple that you're an active developer. It's not a guarantee, but it's one of many things they look at.

Why "bug fixes and performance improvements" is a waste

I understand why people do this. You shipped a bunch of small fixes, none of them are individually interesting, and writing release notes feels like busywork when you're already behind on the next feature. So you type the default phrase and submit.

The problem is that you're spending one of your limited communication channels with users on literally nothing. Release notes are free space. No character limit that matters in practice. No approval process beyond the normal review. You get to talk directly to people who already have your app installed. That's worth more than a throwaway sentence.

The other problem is that generic release notes often precede a spike in bad reviews. Someone updates, notices something different, and has no context for why. If the release notes had said "we moved the settings icon to the top right" they might have been fine. Instead they leave a one-star review saying the app is "broken" because they can't find a button that moved three centimeters.

There are a few companies that get away with jokey non-release-notes. Slack used to write funny ones. Tumblr does absurdist ones. If you're genuinely funny, fine. But most attempts at humor in release notes land somewhere between cringeworthy and confusing. And even Slack eventually stopped because users complained they couldn't tell what actually changed.

What to actually write

Release notes should answer one question: "what will I notice?" Not "what did the developer change in the codebase" but "what's different from the user's perspective."

For feature updates, describe the feature in terms of what the user can now do. "You can now export your data as a CSV file from the settings screen" is better than "Added CSV export functionality." The first one tells someone exactly where to find it and what it does. The second one is a commit message, not a release note.

For bug fixes, mention the bug, not the fix. "Fixed a crash that happened when opening the app on iPad" is useful because iPad users who experienced that crash know their problem is solved. "Fixed a memory allocation issue in the layout engine" means nothing to anyone except the developer who wrote it.

For design changes, be direct about what moved and why. "We moved the compose button to the bottom of the screen so it's easier to reach with one hand" prevents the inevitable "where did the compose button go" support emails and angry reviews. Users handle change much better when they know it was intentional.

For performance work, quantify it if you can. "The app now opens about 40% faster on older devices" means something. "Performance improvements" means nothing. Even rough numbers feel more honest than vague claims.

Structure that works

You don't need a format specification. But having a rough pattern saves you time and makes notes scannable.

Lead with the biggest change. If you added a new feature and also fixed three bugs, open with the feature. Users scan the first line or two. If the first thing they see is "Fixed a rare crash on iOS 17.2" they might stop reading before they see the new feature you spent a month building.

Use short paragraphs or a simple list. Don't write a wall of text. Don't write a novel. Three to five bullet points is usually the right length for a regular update. For a major release, you can go longer, but anything past ten bullet points is probably too much for a release note. Put the details on your blog or changelog page.

Here's a release note that works:

That's maybe 80 words. Took two minutes to write. Tells existing users what to look for, tells browsing users the app is well maintained, and defuses the "why did my dark mode change" complaint before it starts.

Release notes are marketing copy you're not paying for

Think about it. You have a text field that goes out to every single person who has your app installed. Apple sends them a notification. The update appears in their update queue with your text right there. No ad budget. No algorithm to fight. Just your words in front of your users.

Some developers use this well. They mention features that users might not have discovered yet. "Did you know you can swipe left on any item to archive it? We made the gesture faster in this update." That's a bug fix and a feature discovery prompt in one sentence.

You can also use release notes to address common complaints proactively. If you see recurring themes in your reviews about a missing feature, and you just added that feature, say so clearly. "A lot of you asked for widget support. Here it is. Three sizes, customizable colors." That kind of note can turn a frustrated user who was about to switch into a loyal one.

If you're running a subscription app, release notes justify the ongoing cost. A subscriber who sees specific improvements every two weeks feels like they're getting value. A subscriber who sees "bug fixes" every two weeks wonders what they're paying for. This directly affects subscription churn.

How often to update

There's no universal right answer, but there are wrong answers. Updating every day is too frequent. Users get annoyed. Apple might slow down your review process. And each update has a small risk of introducing a new bug. Updating once every six months is too infrequent. It signals abandonment, regardless of how much work you're doing behind the scenes.

For most indie apps, every two to four weeks is a good cadence. It's frequent enough that your "What's New" section always looks recent. It's infrequent enough that each update has enough substance for real release notes. And it gives you a forcing function to ship regularly instead of accumulating a massive update that's scary to release.

If you're in a phase where you're mostly fixing bugs and not adding features, consider batching a few fixes into a single update rather than shipping each one individually. "We fixed five bugs this month" reads better than five separate "bug fix" updates.

One exception: critical bugs. If the app is crashing for a significant number of users, ship the fix immediately. Don't wait to batch it. And when you write the release notes, be honest: "Fixed a crash affecting users on iOS 18.3. Sorry about that. The issue was caused by [brief explanation]. Should be stable now." Users respect honesty more than silence.

Version numbers matter less than you think

Some developers agonize over whether something is a 2.1 or a 2.2 or a 3.0. Users don't care about your version number. They care about what changed. A "3.0" with no visible differences is confusing. A "2.3.1" that adds the one feature they've been asking for is the best update they've ever seen.

That said, major version bumps (2.x to 3.0) can be useful as a marketing signal. If you've done a significant redesign or added a major feature set, a version 3.0 gives you an excuse to write bigger release notes, maybe do a blog post, and treat it more like a mini-launch. Some developers time their major version bumps with Apple events or seasonal trends to maximize visibility.

One thing to avoid: resetting your rating on a major update. Apple lets you reset your star rating when you submit a new version. It sounds appealing if your current rating isn't great. But resetting means you go from 4.2 stars with 500 ratings to zero stars with zero ratings. That looks worse than 4.2. Only reset if your rating is below 3.5 and the new version fundamentally changes the app.

Apple vs Google Play differences

Both stores have a "What's New" section, but they display it differently and the audience behavior varies.

On iOS, release notes appear prominently on the app page and in the Updates tab. Users with auto-update disabled see the notes before deciding whether to update. Apple gives you 4,000 characters, which is more than you need. The App Store app also shows a collapsed preview with a "more" expander, so your first line or two need to be the hook.

On Google Play, the "What's New" section is less prominently placed on the listing. Google also provides 500 characters for the "short description" and a separate release notes field. Because the space is more constrained, you need to be more concise. Prioritize the most impactful change.

If you're on both platforms, don't use identical release notes. iOS users don't need to hear about an Android-specific fix. And a note that fits nicely in Apple's generous space might need editing for Google Play's tighter constraints.

One thing specific to Google Play: staged rollouts. If you're rolling out gradually (10%, 25%, 50%, 100%), your release notes are already live for the users who receive the update early. Use this as a soft test. If the 10% rollout generates confused reviews about something you mentioned in the notes, you can adjust the notes before the full rollout. You can't do this on the App Store because updates go to everyone at once (unless you use phased release, which delays delivery but doesn't let you edit notes between phases).

Localizing release notes

If your app is localized for multiple markets, your release notes should be too. This is the part most developers skip, and it's noticeable. A Japanese user seeing English release notes gets a small but real signal that this app wasn't really made for them.

You don't need professional translation for release notes. They're short, they change frequently, and the language is simple. Machine translation with a quick review is usually fine here, unlike your app metadata and screenshots where quality matters more.

If you're only going to localize release notes for one market beyond English, pick the market where you have the most users. Check your analytics for user distribution by country and start there.

Mistakes I keep seeing

Using internal jargon. "Migrated data layer to CoreData" is meaningless to a user. "The app should feel snappier, especially with large lists" communicates the same change in terms they understand. Save the technical details for your commit log.

Listing every single change. If you fixed fifteen minor bugs, you don't need fifteen bullet points. "Fixed various small bugs including a layout issue on iPad and a timezone problem in notifications" covers it. Mention the two or three that users might have actually encountered. Skip the rest.

Copy-pasting the same notes across multiple versions. I've seen apps with the same release notes for five consecutive updates. This looks worse than unique "bug fixes" text because it actively tells the user you don't care enough to spend sixty seconds writing something new.

Being passive-aggressive about bad reviews. "For users who gave us 1 star because of X: we fixed it. Please update your review." This comes across as petty. Fix the bug, mention the fix neutrally, and let the review management strategy handle the rest separately.

Announcing features that aren't ready yet. "Coming soon: dark mode!" generates support requests from people who updated expecting to find it. Only mention what's in the current build. If you want to tease upcoming features, do it on social media, not in release notes.

Forgetting to mention removed features. If you removed something, say so and explain why. "We removed the widget because it was causing battery drain on some devices. We're working on a better version." Silence about removals leads to confused and angry users who think their app is broken.

The connection to ASO

There's some debate about whether release notes affect App Store search rankings. Apple has never confirmed it, and most ASO practitioners consider the ranking impact minimal compared to title, subtitle, and keyword field. But there are indirect effects worth considering.

Regular updates signal to Apple's algorithm that the app is active. Active apps are less likely to be deprioritized. The mechanism is unclear, but apps that haven't been updated in a year tend to rank worse than recently updated competitors, all else being equal.

Good release notes also affect conversion rate, which does affect ranking. If a user on your listing page sees a recent, specific update, they're more likely to download. Higher conversion means better ranking for your keywords. It's a second-order effect, but it exists.

Don't stuff keywords into your release notes. Apple specifically warns against it and it reads terribly. Write for humans. The ASO benefit comes from being active and converting well, not from cramming "best budget tracker free" into your bug fix notes.

When you're shipping a big redesign

Major visual updates are the highest-risk releases for bad reviews. People don't like change, especially in apps they use daily. Your release notes matter more here than for any routine update.

Be specific about what changed and why. "We redesigned the home screen to put your most-used features within one tap" is honest and gives users a reason to adapt. "Fresh new look!" tells them nothing and sounds like you changed things for the sake of it.

If you moved things around, tell people where things went. "Your saved items are now under the profile tab instead of the menu." This one sentence prevents dozens of "where did my saved items go" reviews. You'd be surprised how many developers skip this.

Acknowledge that it's a big change. "This is our biggest update in a while, and we know it takes time to get used to new layouts. If something feels off, email us at support@example.com." That one line redirects complaints from public reviews to private email, which is where you want them. If you need more on managing reviews during turbulent updates, the user retention guide covers the broader risk.

A 10-minute process for writing release notes

The reason most developers write bad release notes is that they try to write them at the last minute, right before submitting the build. By that point they're tired, they just want to ship, and "bug fixes" is the path of least resistance.

Instead, keep a running document (even a plain text file or a note in your project) where you jot down user-facing changes as you make them. When it's time to submit, you already have the raw material. Spend ten minutes turning those notes into release text:

Minutes 1-3: Read through the list and pick the top change. That's your opening paragraph. Write it as "you can now..." or "we fixed..." in plain language.

Minutes 4-7: Group the remaining changes into three to five bullet points. Merge minor items. Drop anything purely internal. Translate technical descriptions into user language.

Minutes 8-10: Read the whole thing aloud. If any sentence makes you stumble, simplify it. Check that the first two lines work as a standalone summary, since that's all most people will see before the "more" expander. Done.

Ten minutes. That's less time than most developers spend choosing between two shades of blue for a button.

Templates for different kinds of updates

Not every update is the same. Here are patterns that work for common scenarios:

Mostly bug fixes: Open with the most noticeable fix, then batch the rest. "We fixed the issue where notifications sometimes arrived late. Also squashed a few layout bugs on smaller screens and improved how the app handles slow connections."

One new feature: Lead with the feature, explain it in one or two sentences, then mention any other changes briefly. Keep the spotlight on the feature since that's what users care about.

Seasonal or event-based: If your update ties to something (new iOS version, holiday theme, a current event), mention the context. "Updated for iOS 19 with new widget sizes and Live Activities support" tells the user why they're seeing this update now.

Pricing changes: If you changed your pricing, mention it in the release notes even if existing users are grandfathered. Transparency prevents backlash. "We adjusted pricing for new subscribers. If you're already subscribed, your price doesn't change." That one sentence avoids a wave of angry reviews from existing subscribers who saw the price change mentioned somewhere else and panicked.

Emergency hotfix: Be honest. "We found a bug in the last update that caused [specific problem]. This update fixes it. Sorry about the disruption." Honesty in hotfix notes generates goodwill. Silence generates resentment.

Release notes in context

Release notes are one piece of a bigger picture. Your App Store listing as a whole tells a story: the screenshots show what the app looks like, the description explains what it does, and the release notes show that someone is still working on it.

When you ship an update with new features, update your screenshots too if the UI changed. Nothing undermines trust faster than release notes describing a new feature while the screenshots still show the old interface. The listing should feel coherent, not like different parts were written at different times by different people (even if they were).

The same goes for your landing page. If your app has a website, a monthly landing page review timed with your update cadence keeps everything consistent. Update the app, update the notes, update the website. Twenty minutes total, and your presence across all channels tells the same story.

Writing good release notes is one of those things that takes very little effort compared to the effort of building the features themselves. It's ten minutes of writing that reaches every active user of your app. No other marketing channel gives you that kind of direct access for free. Treat it accordingly.

If you're building something and want to see where the opportunities are, the opportunity scanners analyze the App Store across six different angles. And one of the things that keeps showing up in the data: apps with generic release notes and stale update dates are disproportionately represented in the zombie scanner results. Active maintenance, clearly communicated, is part of what separates a live app from a dead one.