App Store Release Notes That Drive Updates (What's New Best Practices)

App Store release notes are the most-skipped indie metadata surface. Most teams default to “Bug fixes and improvements” or paste a git-log-flavored changelog and call it done. The field drives update-install conversion — how many existing users on an old version actually tap Update when they see your notes. Written well, release notes lift update-install conversion 20–40% in App Store Connect analytics.

This post covers the two stores’ release notes fields (iOS 4,000 chars, Play 500 chars), when users actually read them, a 3-part template you can adapt each release, and the mistakes that make notes unreadable.

Pair with the promotional text guide, Apple keywords field deep-dive, and the ASO playbook for indie developers to complete the metadata cluster.

The two fields and their limits

Two stores, two fields, two very different character budgets.

The asymmetry matters for how you write: Play is the constraint. Most indie teams write the 500-character version first and either ship it verbatim to both stores or expand slightly for iOS. Writing the 4,000-character iOS version first and trimming for Play almost always produces a 500-char Play version that reads as a cut-off version of the iOS one.

The other distinction: both fields are tied to the version number. Updating the binary from 2.4.0 to 2.4.1 without editing the field means users see stale notes. Treat release notes as a required part of the 9-minute pre-flight checklist.

When users actually read release notes

Reality check before you spend an hour writing the notes.

• iOS update prompt readership:approximately 15% of existing users scroll the update-available popup to read What’s New. The other 85% tap Update without reading.
• Google Play Updates tab:release notes appear prominently. Users browsing the Updates tab actively read them — Play’s Updates-tab experience is designed around the notes.
• First-time visitors to your listing: see release notes below the fold. Virtually none read the notes before reading the description.

The implication: write notes primarily for existing users who need a reason to tap Update, not for acquisition. That means benefit-shaped bullet points, not feature lists; trust signals more than marketing; brevity over comprehensiveness. What acquisition-focused indie listings want in the description, update-focused listings want out of the release notes.

The 3-part template

One copy-paste structure that fits both stores when written to the Play 500-char limit.

Part 1 — One-line headline

Lead with the single biggest thing this release delivers. One sentence, one benefit, no version numbers. “Offline sync is finally here.” “We cut startup time in half.” “Widgets, at last.”

Part 2 — Bulleted new-and-improved

3–5 items that users actually care about. Each bullet should be benefit-shaped, not feature-shaped:

• “Search now finds notes by tag, not just title.” ✅
• “Added tag-based search in NSPredicate.” ❌

The benefit-shaped bullet tells an existing user what they’ll experience differently. The feature-shaped bullet tells them nothing.

Part 3 — Closing line

One sentence acknowledging fixes + a pointer to what’s coming next. “Also fixed the iPad sidebar glitch folks flagged last month. Calendar sync next.”

The closing line does two jobs: it tells users you listened, and it gives them a reason to check back at the next release.

A worked example for a markdown notes app

Bad (what most indies ship):

“Bug fixes and performance improvements.”

Good (following the template):

Offline sync finally works on every platform.

• Search now finds notes by tag, not just title.
• Export to PDF from long-press on any note.
• Dark mode matches the system exactly.

Also fixed the iPad sidebar glitch from last month. Calendar sync next.

The good version is 275 characters — well under Play’s 500. Expand with 2–3 more bullets for iOS if you want; the structure already works as-is.

What to skip in release notes

Six patterns that make notes unreadable.

1. “Bug fixes and improvements.” The laziest notes on the App Store. Users correctly read this as “the developer didn’t care enough to tell me.”
2. Technical jargon. “Updated Swift to 6.0,” “Migrated to NSPredicate,” “Upgraded SDK to 3.4.1.” Users don’t care. Rewrite as the user-facing impact.
3. Apologies for bugs users didn’t know about. “Fixed a critical crash in iOS 18.2 that affected sync” tells 95% of your users that your app crashes — information they didn’t have before reading the notes.
4. Time-bound language.“Fixing the crash from last week” reads weird six weeks later when the notes are still in the version history.
5. External URLs.Apple rejects URLs in release notes under guideline 2.3.1, same as promotional text. Move links to the in-app What’s New modal instead.
6. Marketing language.“Check out our amazing new feature!” reads as desperate. Lead with the feature itself.

The 6-month rule

Both stores preserve historical release notes for roughly the last 6 months of versions. App Store Connect shows the full version history on the product page; Google Play shows recent releases in the What’s new card.

The implication: write each release’s notes to read well in contextwith the previous 5–10 releases, not as standalone marketing. A user scrolling your version history reads the notes sequentially. Each release feeling like a separate marketing launch reads as inconsistent; releases that build on each other (“last month we shipped X, this month we fixed Y the feedback flagged, next month Z”) read as operational ownership.

Release cadence and notes quality

Match the notes structure to the release type:

• Monthly minor updates — lead with one feature. 2–3 bullets. Short closing line.
• Every-3-months major updates — lead with the headline benefit. 4–5 bullets. Longer closing line signaling the next major release direction.
• Security / hotfix releases— state the specific fix briefly. “Fixed a sync issue introduced in 2.4.0. No new features in this release.” Users appreciate honesty on hotfixes more than manufactured excitement.

Pair the release-notes cadence with the 30-day iteration cycle described in the ASO playbook.

Frequently asked questions