Mobile release notes live inside two small boxes with hard rules — 4,000 characters on the App Store, 500 on Google Play — read by users deciding whether your app is alive and worth trusting. Here are the actual rules, the actual data on whether they matter, and how to write them well without making it a weekly chore.
Most guides to release notes assume you control the page they’re published on. Mobile is different: Apple and Google own the container, set the character limits, review what you write, and decide where it appears. Writing good mobile release notes starts with knowing the rules of each box — several of which are commonly gotten wrong.
The App Store Rules
The What’s New field holds 4,000 characters and is required for every version after your first release. It can be localized into each of the roughly 40 App Store locales, and it appears in two places: your product page, and the user’s App Updates list (in current iOS, under your profile icon in the App Store — there’s no standalone Updates tab anymore).
You can’t edit it without shipping. Since 2018, changing What’s New text means submitting a new version through review. Proofread accordingly.
Apple reviews what you write. App Review Guideline 2.3.12 is specific: “Apps must clearly describe new features and product changes in their ‘What’s New’ text. Simple bug fixes, security updates, and performance improvements may rely on a generic description, but more significant changes must be listed in the notes.” So the universal “bug fixes and performance improvements” boilerplate is permitted — but only when that’s genuinely all the update contains. Shipping a redesign under boilerplate is a metadata-accuracy problem under Guideline 2.3, not just a style choice. (New features must also be described “with specificity” in your Notes for Review.)
Promotional text is the escape hatch. It’s a separate 170-character field at the top of your description that you can update anytime without a new build — useful for time-sensitive announcements. One thing it won’t do, per Apple directly: “promotional text doesn’t affect your app’s search ranking so it should not be used to display keywords.”
Phased releases change the timeline. If you use Apple’s 7-day phased rollout, the update reaches roughly 1%, 2%, 5%, 10%, 20%, 50%, then 100% of auto-update users day by day (anyone can still manually update from day one), and you can pause for up to 30 days. Your release notes are public from the first day — write them for the full audience, not the 1%.
The Google Play Rules
500 Unicode characters per language. That’s the whole budget — an eighth of Apple’s. Notes are entered between locale tags in the Play Console (<en-US> on its own line, your text, then </en-US>), one block per supported language, with a copy-from-previous-release option that also carries translations forward.
No promotion, by policy. Google states it plainly: “Release notes shouldn’t be used for promotional purposes or to solicit actions from your users.” Combined with the broader metadata policy against “misleading, improperly formatted, non-descriptive, irrelevant, excessive, or inappropriate” text, Play release notes are the wrong place for discount codes and rating begs — describe the changes, full stop.
Staged rollouts are manual. Play’s staged rollout reaches a random percentage of users you increase yourself (it never advances automatically), users aren’t notified they’re in the stage, and Google recommends updating your store listing only after reaching 100%.
The practical consequence of the 500-character limit: write the Play version first. Compressing 4,000 characters down to 500 produces mush; expanding a tight 500 into more detail for iOS is easy. The constraint is a good editor.
Do Release Notes Actually Matter? The Honest Answer
Three facts to hold together.
Most updates install silently. iOS updates apps automatically by default, and Android offers the same. Many of your users will never see a single word of your release notes at update time. Anyone who claims a precise percentage of users who read them is making it up — no credible published statistic exists.
But the readers who do see them are disproportionately important. Release notes appear on your product page, where prospects evaluating your app check — among other things — whether it’s actively maintained. A wall of “bug fixes” with no dates of substance reads exactly like the silence that makes users think a product is dead.
And the correlation data is real. The largest study of mobile release notes — Yang et al., published in Empirical Software Engineering (2022), covering 69,851 releases of 2,232 top Google Play apps and 67.7 million user reviews — found release notes cluster bimodally (either over 50 words or under 7), that apps with longer release notes tend to have higher average user ratings, and that apps which shifted from rarely-updated boilerplate to frequent, informative notes tended to see higher average ratings. Correlation, not causation — good teams both write better notes and ship better apps — but the association runs in exactly one direction.
On search: don’t expect keyword magic. Apple indexes the app name, subtitle, and keyword field — not What’s New. Whether Google Play indexes release-notes text is unverified even among ASO vendors. Release notes earn their keep through conversion and retention, not rankings.
This is a volume game, too: per 42matters (July 2026), 38% of the top 1,000 iOS apps update at least weekly and 76% at least monthly, with nearly identical figures on Play. If you’re shipping anywhere near that cadence, release notes are a weekly writing task — worth systematizing, not improvising.
How to Write the Notes
Lead with the change users asked for. One update, one headline change. If you shipped the thing your reviews have been begging for, that’s your first line — and your best shot at converting a 3-star review into a 4.
Specifics beat adjectives. “Search now filters by date” beats “improved search experience.” The test from our changelog copywriting guide applies verbatim here: if a sentence could describe any app’s update, it describes no one’s.
Personality is optional; clarity isn’t. Slack made release notes famous as a voice channel — from 2014, writer Anna Pickard codified a “clear, concise, and human” style, and the team’s own position was that “‘Minor improvements and bug fixes’ was not our style.” A real one, from October 2015: “Fixed: If you select ‘Safari’ as your Web Browser preference, links will not open in the in-app browser, they’ll now open in… wait for it: Safari.” Note what makes that work: the joke is riding on a precise description of an actual fix. Pocket Casts does the same today (from its current App Store notes: “The mini player got bigger controls (your thumbs asked nicely)… We also waved off iOS 16 and watchOS 9. Thanks for the memories.”). But the opposite register works too — Things 3’s current notes read, in full: “• Fixed a bug where generated URL scheme tokens had insufficient entropy. • Fixed a rare crash.” Terse, specific, perfectly trustworthy. Personality without specifics is noise; specifics without personality are still release notes.
Reserve boilerplate for boilerplate releases. Guideline 2.3.12 explicitly allows a generic description for simple bug fixes and performance work. Use it when true. The failure mode is using it always — which the EMSE data suggests is the pattern correlated with lower-rated apps.
A 500-character skeleton that covers the job:
NEW: [The headline change, one line, user language]
IMPROVED: [Second-most-important change]
FIXED: [The bug users actually noticed]
[One human sentence — thanks, context, or what's next.]
One Source of Truth, Two Stores
The structural problem with store release notes: they’re trapped. Each version’s notes vanish from view when the next version ships, they live in two consoles in two formats, and they’re invisible to your web users, your support team, and the AI assistants that now answer questions about your product.
The fix is to stop treating store notes as the original. Keep a canonical changelog — dated entries, stable URLs, the durable record of what shipped — and treat both stores’ What’s New boxes as excerpts of it: the Play version is your 500-character summary, the App Store version adds detail, and the full story lives at a URL you control. That’s the changelog vs release notes distinction doing practical work: the changelog is the source; release notes are drawn from it.
If your mobile app ships from GitHub, ReleasePad generates that canonical entry from your merged PRs — AI-drafted, human-approved — and publishing to the stores becomes a two-minute condensation job instead of a blank-page exercise. At weekly cadence, that’s the difference between release notes that get written and release notes that get skipped.
Further Reading
Frequently Asked Questions
What is the character limit for App Store release notes?
Apple's What's New field is limited to 4,000 characters. It's required for every version update (but not for your first release), and it can be localized per storefront. Google Play is far tighter: release notes are limited to 500 Unicode characters per language, entered between locale tags like <en-US> in the Play Console.
Are release notes required for app updates?
On the App Store, yes — the What's New field is required for all versions after the first. Apple's review guideline 2.3.12 goes further: 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, but significant changes must be listed. Google Play accepts releases without notes, but its metadata policy prohibits misleading or irrelevant text and states release notes shouldn't be used for promotion.
Do app release notes affect App Store search rankings?
Not directly on iOS. Apple states outright that promotional text doesn't affect search ranking, and ASO industry analyses agree Apple indexes only the app name, subtitle, and keyword field. But a 2022 peer-reviewed study of 69,851 releases from 2,232 top Google Play apps found apps with longer release notes tend to have higher average user ratings — and ratings feed every ranking system. Release notes work on conversion and trust, not keywords.
Can I update App Store release notes without submitting a new build?
No — since 2018, changing What's New text requires submitting a new version for review. The exception is promotional text: a separate 170-character field at the top of your description that you can update at any time without a new submission. Use promotional text for time-sensitive messages and treat What's New as fixed once the version ships.
How often do top apps update and post release notes?
Frequently. Per 42matters data from July 2026, 38% of the top 1,000 App Store apps update at least weekly and 76% at least monthly; Google Play numbers are nearly identical (37% and 75%). Monday is the most popular release day on both stores. Frequent updates mean release notes are a recurring writing task — which is why a single changelog source that feeds both stores saves real time.
What did Slack's famous release notes actually look like?
From 2014, Slack treated release notes as a brand voice channel, with writer Anna Pickard codifying a 'clear, concise, and human' style. A real example from October 2015: 'Fixed: If you select Safari as your Web Browser preference, links will not open in the in-app browser, they'll now open in… wait for it: Safari.' The team's stated position: 'Minor improvements and bug fixes' was not our style.
Ready to put this into practice?
Your changelog shouldn't be an afterthought.
ReleasePad makes it easy to publish great release notes — from a public changelog page to an in-app widget, GitHub integration, and analytics. Free to get started.
Get started — it's free