App Store Release Notes: Character Limits, ASO Impact & 10 Examples

The App Store and Google Play release notes box looks like an afterthought. Four thousand characters on iOS, five hundred on Android, no formatting, no links on Apple, wedged between the version number and the download button. Most teams paste "Bug fixes and performance improvements" and move on.

The teams that don't — Duolingo, Revolut, Notion, Linear, a handful of others — treat those bytes like conversion copy. Release notes are the last thing users read before deciding to update, the first thing they see when landing on your store page for the first time, and a signal to the algorithm that your app is actively maintained. This guide covers what actually fits, what works, and what ten top-tier apps put in the box.

TL;DR

• iOS: 4000 characters, no markdown, no clickable links, no images.
• Google Play: 500 characters, no markdown, no clickable links, no images.
• Both show only the latest version by default — older notes are in a "Version History" panel users rarely open.
• The notes affect conversion on the store page and — indirectly — ASO via update frequency signals.
• Localize per country. Apple and Google serve the release notes in the user's device language when you provide a translation.

The hard constraints, one more time

Most teams write mobile release notes without knowing the actual specs. Get these wrong and your copy either truncates or shows up as literal ** asterisks.

| Constraint | iOS App Store | Google Play | |---|---|---| | Character limit | 4000 | 500 | | Markdown | No — renders as plain text | No — renders as plain text | | Clickable links | No | Yes, auto-linkified | | Emoji | Yes, renders everywhere | Yes, renders everywhere | | Line breaks | Yes | Yes | | Bullet points | Visual only (use • or –) | Visual only (use • or –) | | Localized per country | Yes, per App Store locale | Yes, per Play Console locale | | Visible in "Version History" | Yes | No — only latest version shown |

How release notes affect ASO

The notes don't directly feed keyword indexes on either store (that's the app subtitle and description). But they do affect two things the algorithms care about, plus one conversion lever that matters more.

Update frequency signal. Both Apple and Google reward apps that ship regular updates. The release notes are a visible marker of that cadence. An app that hasn't updated in 6 months with "Bug fixes" as its last note is getting beaten in ranking by a less-capable competitor shipping weekly with substantive notes. The notes don't cause the ranking boost, but they're the visible signal of the pattern that does.

Review quality. Users who read clear release notes before hitting "Update" file fewer 1-star "what did you change?!" reviews after. Cryptic notes ("Bug fixes") after a major UI change are a known generator of review-bomb spikes. Clear notes acknowledging the change shift the review distribution upward.

Conversion on the store page. For users who scroll down to "What's New" before installing for the first time, the notes are the final conversion touchpoint. A good note ("Dark mode, offline transcripts, 3× faster search") reduces friction; a bad one ("Bug fixes") signals dead app. The effect is small per install but compounds across hundreds of thousands of monthly visitors.

What fits in 500 characters

Google Play's limit is the hard one. Half a tweet. Assume you have 3 lines of ~80 characters each, plus one headline line. Strip every redundant word.

Here's what 500 characters actually looks like:

New in this update:

• Dark mode — automatic, based on your system settings
• Offline mode for saved items
• 3× faster search (no kidding, we benchmarked)
• Fixed: the notification sound glitch on Pixel devices
• Fixed: rare crash when opening shared links from Slack

Feedback? Tap Settings > Help.

That's 408 characters, including the whitespace. Notice: no brand voice flourish, no marketing language, no "We're excited to announce". Four new items, two fixes, one low-friction feedback path. Ship.

10 teams that write release notes that convert

What "good" actually looks like, stripped of marketing language and measured against conversion data we've seen from teams running A/B tests on the box.

1. Duolingo

Duolingo uses persistent, friendly copy with a dose of character (the green owl, you know the one). Their notes include the version, a single-line descriptor ("We made the app faster and the owl happier"), and a bullet list of actual changes. They localize in every supported language — 38+ at last count. The character budget is spent on voice consistency, not information density.

2. Revolut

Revolut ships release notes that read like a changelog for finance professionals. Specific, dated, feature-grouped. "Crypto: buy USDC directly from a connected bank account. Cards: virtual card generation moved to in-app. Fixed: duplicate transaction notifications." Their audience skims for regulatory/financial changes and Revolut surfaces them first.

3. Notion

Notion's mobile notes mirror their web changelog — same tone, same structure, roughly half the length. They name specific integrations ("Sync improvements for Outlook"), cite shipped user requests ("You asked for block-level undo — it's here"), and reserve one slot for the most-requested fix. The connection to the web changelog reinforces the brand's "we ship constantly" narrative across platforms.

4. Airbnb

Airbnb is disciplined about seasonal relevance. Release notes shipped in February lean on ski-cabin and winter-escape framing; summer updates on beach rentals. It's release-note-as-merchandising — technically true ("we improved search filtering") but editorially framed for the season. Works for consumer apps where use-case framing drives re-engagement.

5. Linear Mobile

Linear's mobile app is the companion to the web tool; their notes treat the audience as a developer. Tight, code-adjacent phrasing. "New: swipe-to-triage on inbox. Fixed: offline queue no longer double-sends on reconnect." No emoji, no voice flourish. Matches the web changelog's aesthetic.

6. Spotify

Spotify's notes are boring on purpose. "Updates to improve your experience and fix bugs" is their default. This works because the app updates weekly — users don't read the notes, they update on autopilot. For a mass-market app where the update habit is already solid, release notes are not a conversion lever and minimal notes are a fine choice. Do not copy this if your app updates monthly.

7. Figma

Figma's mobile release notes reference the desktop release notes with consistent version numbers. A user reading the Figma web changelog and the iOS release notes gets the same information, keyed to the same release. Cross-surface consistency builds trust for pro-tool users who care about version tracking.

8. Arc Browser

Arc uses release notes as personality. They write in first person, include playful descriptions of what the team is working on next, and sometimes reference the week's Arc newsletter. The notes are a small-but-visible surface for brand voice. Works for a product that leans heavily on community.

9. Superhuman

Superhuman's notes are brief, specific, and always include a keyboard shortcut if one's new. They assume power users reading for the one change that affects their muscle memory. "Cmd+Shift+L now archives. Previously: label." No fluff, highly actionable.

10. Cal.com

Cal.com's mobile notes are bullet lists, usually under 300 characters, dated. They reference specific integrations by name ("Google Meet, Zoom, Around, Riverside — all now support round-robin booking"). The specificity signals active integration work and reassures users with specific tools in their stack.

What to actually write

Six-part structure that fits in both platforms' limits:

1. One-line summary — what's the headline?
2. New features — 2-4 bullets, specific
3. Improvements — 1-2 bullets on existing features
4. Fixes — 2-3 bullets on the bugs users complained about
5. Optional — thanks, roadmap hint, or voice line
6. Feedback path — "Settings > Help" or equivalent

Full iOS example (1400 chars, well under the 4000 limit):

Version 3.8 — Dark mode and faster sync

New
• Dark mode: automatic based on your system theme, or pick a preference
  in Settings > Appearance
• Offline transcripts: downloaded episodes now include the transcript
• Share to WhatsApp, Telegram, and Discord directly from any item

Improvements
• Search is roughly 3× faster on libraries over 1,000 items
• Sync handles spotty connections without duplicating entries

Fixes
• Fixed a rare crash when opening shared links from Slack
• Fixed the notification sound glitch on iPhone 15 Pro
• Fixed playback stutter on AirPods Pro 2 with Bluetooth codec switching

Thanks to everyone who reported the sync bug — v3.8 is mostly your
feedback. Keep it coming via Settings > Help > Contact.

Google Play version (465 chars):

v3.8 — Dark mode and faster sync

New:
• Dark mode, system-aware
• Offline transcripts for downloaded episodes
• Share direct to WhatsApp, Telegram, Discord

Improved:
• Search 3× faster on large libraries
• Sync handles spotty connections cleanly

Fixes:
• Rare crash from Slack-shared links
• Notification sound on Pixel 8
• Playback stutter on Bluetooth codec switch

Feedback: Settings > Help.

Same information, half the characters. The Android version strips voice flourish and keeps only the functional core.

Localization: the detail that gets skipped

Apple and Google both support per-locale release notes, and both fall back to the default (usually English) if no translation is provided. Localizing is worth it because:

• Store conversion rates improve materially in non-English markets when release notes are in the local language. Not huge — typically a few percent — but compounding across every release.
• Review quality improves. Non-English users who got a cryptic English release note will review in their local language, and the review ends up on your store page.
• App Store Optimization tools (ASO ranking trackers) pick up local-language terms from the release notes' indexed text, adding a small long-tail keyword lift.

Start with your top 3-5 markets by install volume. Translate the notes, not the brand voice — a literal translation of "we ship fast" is often not culturally appropriate. Use a native reviewer, not just an AI pass.

Common pitfalls

"Bug fixes and performance improvements"

The default. Ship it only if you are literally only shipping bug fixes and perf improvements, and only after a meaningful update. A version with "Bug fixes" as its note after a UI redesign is a review-bomb magnet.

Version number inconsistency

The release note says "v3.8 brings dark mode". The web changelog says "v3.8.1 ships dark mode". The user submitting a bug report has no idea which version they're on. Align versions across every surface — App Store, Play Console, web changelog, support docs.

Review-bomb after a UI redesign

If you ship a material UI change, the release notes must acknowledge it, not hide it. "We redesigned the home screen based on feedback — let us know what you think at Settings > Help" inoculates against the "where is everything?!" wave.

Over-promising in the notes

Release notes are a promise. "Instant sync across devices" that takes 8 seconds under normal wifi is a 1-star review waiting to happen. Describe the feature as it behaves on the median user's connection, not the best case.

Shipping without updating the description

The release notes and the app's main description should be consistent. If the notes mention a feature that isn't in the description, update both at the same time. ASO trackers scan the description more than the notes.

FAQ

Wrap-up

Four thousand characters on iOS, five hundred on Android, no links on Apple. Inside those constraints, the teams that treat release notes as real copy — Duolingo, Revolut, Notion, Linear — get a small-but-compounding lift on conversion, review quality, and update-frequency signal. The teams that paste "Bug fixes and performance improvements" after every release are leaving that lift on the table.

Write the long version first, cut to fit, localize the top markets, never promise what the median user's connection can't deliver. Ship with every update. The discipline is boring; the compounding effect is not.