Key points:
- Apple’s own App Store Connect docs list “What’s New in this Version” as a required field for version updates. A real, current requirement.
- iOS allows up to 4,000 characters of release notes. Android caps it at 500. A real structural gap. Not a stylistic choice you get to make.
- ASO practitioners have long said release notes aren’t indexed for search. Only title, subtitle, and the hidden keyword field are. Strong consensus, built over a decade. Apple has never stated it directly, though.
- Neither platform lets you edit release notes without a new version or release going out. Unlike some other listing fields that update instantly.
Release notes get treated as an afterthought by a lot of teams. A rushed line or two, written five minutes before submitting a build. Whether that’s actually costing you anything for search comes down to a claim repeated constantly in ASO circles. One rarely traced back to its real source.
What’s genuinely documented
Apple’s own App Store Connect reference lists “What’s New in this Version” as a required, localizable field tied to version updates. That’s a real, confirmed structural fact. The field exists. It’s required. It’s part of your version submission, not something you fill in whenever you like.
The two platforms split sharply on length. iOS allows up to 4,000 characters. Android caps release notes at 500. That’s not a small gap. It’s an 8x difference. A release-notes plan written for iOS, then trimmed for Android as an afterthought, is fighting a real structural wall. Not just a style choice.
The claim that isn’t quite Apple-confirmed
Here’s where honesty matters. ASO practitioners have said for well over a decade that Apple’s search weighs your title, subtitle, and the hidden 100-character keyword field. And does NOT weigh your description or release notes text for matching search terms. This claim is consistent, widely repeated, and has shaped real ASO strategy for years with barely any pushback.
It’s also not something we could find Apple stating directly, in those words, in current docs. Apple describes what each field is and its character limits. It never publishes which fields its own search actually indexes. The practitioner claim is very likely true, given how well it’s held up over such a long stretch. It’s still industry consensus, though. Not an Apple-confirmed fact. Worth keeping that line straight when you’re the one telling a client what matters.
| Fact | Status |
|---|---|
| What’s New is a required field on iOS, tied to version updates | Confirmed, Apple’s own docs |
| iOS allows up to 4,000 characters, Android caps at 500 | Real structural limits on both platforms |
| Title, subtitle, and keyword field are indexed for App Store search | Confirmed, Apple’s own docs |
| Description and release notes are NOT indexed for search | Strong industry consensus, not Apple-stated |
Why this still matters even if it’s not indexed
Set the search question aside entirely for a moment. Release notes still have a real, separate job. They’re often the first thing a returning user reads before deciding to update. A vague “bug fixes and performance improvements” line does nothing to show the update was worth having. Google Play’s own metadata rules also restrict promotional or misleading content across your listing. That reasonably extends to release notes too. Treat this text as a real, read surface, apart from any search effect at all.
Real-world scenario: A fitness app’s team had used the same flat “bug fixes and improvements” note for over a year, on the theory it didn’t matter for search anyway. Reading through their own uninstall feedback, they spotted a pattern. Users who churned around update time often said they had no idea what had changed, and assumed the app wasn’t being actively worked on. The team switched to specific, real notes naming the actual feature or fix each time. Their post-update uninstall rate dropped measurably over the next few releases. Their keyword rankings never moved, matching the idea that release notes aren’t a search lever. The change was still clearly worth making.
What to actually do with your release notes
- Write real, specific release notes. Not a placeholder line. The field has a real reader, even without a documented search effect.
- Plan for the length gap between platforms. A note built for iOS’s 4,000 characters needs its own, shorter version for Android’s 500-character cap. Not a rushed trim.
- Don’t treat this as a keyword-stuffing spot. Consensus runs the other way. This text likely isn’t search-indexed, so cramming keywords in buys you nothing, and Google’s own rules penalize promotional stuffing regardless.
- Track your update-driven uninstall and re-engagement rate. Not your keyword rank. That’s the real metric release notes are likely to move.
For the metrics that ARE documented ranking inputs, AppRankr’s Rank Tracker keeps a daily record. Your ASO effort goes where the evidence actually points.