Every time you ship an update, you get 4,000 characters to tell Apple what changed. Most indie developers use fewer than 40.
“Bug fixes and performance improvements” is not release notes. It is wasted real estate, and under Apple’s 2026 guidelines, it may be working against your app’s position in the store.
What release notes actually do
Release notes in the App Store serve three separate audiences at once:
- Existing users deciding whether to update
- Prospective users reading the version history section of your product page
- Apple’s indexing systems evaluating whether the update represents meaningful, active development
Most indie developers write for the first audience only, or skip release notes entirely because they are time-pressured after shipping a build. That is a mistake.
Apple’s App Store search algorithm treats your app’s update history as a signal. Not the version number, not the binary size. The content of your release notes. An app with descriptive, specific release notes across a consistent update history signals active maintenance. An app with “Bug fixes.” in every update slot signals the opposite.
Under the WWDC26 guidelines update, Apple expanded its stated right to remove apps that “are not updated or improved.” Your release notes field is a direct window into whether your app has been meaningfully updated. If your last five entries all say “minor improvements,” your update history reads as dormant, regardless of what actually shipped in the binary.
How Apple indexes release notes
Apple indexes text across your product page to determine which search queries your app is eligible for. The highest-weighted fields are your title, subtitle, and keyword field. Below those, Apple processes your description, promotional text, and release notes.
Release notes are re-indexed on each update. That means every time you ship, you have a fresh window to introduce new terms that reflect what your app does now. If you shipped a new feature, the release notes entry is the fastest path to getting that feature indexed before your next full metadata submission.
This matters for features that did not exist at launch. If you added dark mode support, a widget, a share extension, or a new workflow since your original metadata was written, your keyword field likely does not mention these features at all. A release notes entry that describes the new feature gets that term into Apple’s index immediately.
This is not a loophole. It is using the tool the way Apple designed it. The field exists so developers can communicate changes. Apple indexes changes because they matter to users searching for apps with specific functionality.
The specific mistake most apps make
Open App Store Connect and look at your last ten release notes entries.
If they look like this:
- “Bug fixes”
- “Performance improvements”
- “Minor stability updates”
- “We’ve been working hard on improving your experience”
You are not just under-serving users. You are writing content that is invisible to Apple’s indexing systems.
“Bug fixes” contains no keyword signal. “Performance improvements” is not a search term anyone types. “Working hard on improving your experience” is a filler phrase that gets filtered by every ranking system that processes natural language.
Compare that to:
Added Focus Filter integration so your app list adapts to your current Focus mode. Improved keyword suggestions to show monthly search volume for each term. Fixed crash on iPad when opening the competitor analysis view with more than 50 tracked apps.
This version names a specific feature (Focus Filter integration), names category terms Apple can index (keyword suggestions, search volume), describes a real fix with platform context (iPad crash), and contains natural language that matches how developers search for functionality.
One of these entries does work for you. The other does not.
A formula that works
Write release notes in three parts:
Lead with the feature, named specifically. “Added scheduled keyword reports” is indexable. “Improvements to the reports section” is not. If you shipped a new screen, name the screen. If you added an integration, name the integration target. Specificity is what gets indexed, and specificity is also what users scan for when deciding whether to update.
Name the use case, not the mechanism. “Track competitor keyword changes across 50 storefronts with daily email digests” is search-adjacent. “Backend optimization for competitor tracking” is not. Write from the user’s perspective, not the engineer’s.
Describe fixes with context. Bug fixes belong in release notes, but they should include what was broken, on what device or configuration, and what the expected behavior now is. “Fixed crash on iPhone SE when submitting metadata with Japanese characters” is useful. “Fixed crash” is not.
Under this formula, a release notes entry for a substantive update might look like:
Added CSV export for keyword rank history. You can now export 90 days of rank data per keyword, per storefront, directly from the tracking view. Export triggers from the top-right icon in the Keywords tab.
Improved ASO score calculation to weight promotional text freshness and review response rate as separate signals.
Fixed incorrect character count shown in the keyword field editor when using mixed-script locales (Japanese, Korean, Chinese).
This entry is around 400 characters, well within the 4,000-character limit, and contains indexable terms across the metadata and localization categories. It describes real changes users can verify, and it signals to Apple that the update was substantive.
How release notes connect to the 2026 purge risk
Apple’s guideline language, “not updated, improved, or does not attract customers,” applies to already-published apps. Your release notes are part of the evidence Apple evaluates when assessing update recency.
An app with descriptive, feature-specific release notes across the last several updates reads differently to Apple’s systems than an app whose entire history is “Bug fixes and performance improvements.” The former demonstrates consistent, active development. The latter provides no signal either way, which is almost as bad as no updates at all.
If you ran the metadata audit from the previous post in this series, update recency was one of the six checks. Strong release notes are the operational mechanism behind that check. You cannot claim “active development” with a binary update if the release notes say nothing about what changed.
How often to revisit your release notes strategy
Release notes are live until your next update. Review them as part of your standard pre-submission checklist:
- Before shipping a significant feature: draft the release notes alongside the feature, not after
- On maintenance releases: describe what actually changed, even if the changes are small
- After a major platform update (new iOS version, new device support): mention compatibility explicitly in the notes
On frequency: Apple does not publish a threshold for how often updates need to ship, but the pattern that shows up in developer account warnings suggests that six months without a substantive update is in the risk window. Consistent releases with descriptive notes across a rolling 90-day window provide stronger evidence of maintenance than a single large update every eight months.
What you can do before your next submission
You cannot retroactively rewrite past release notes. But every update from here forward is a clean slate.
Before your next App Store submission:
- Open a draft and list every user-visible change in the build
- For each change, write one sentence that names the feature and the use case it addresses
- For each bug fix, add the affected platform or context
- Combine into the release notes field (300 to 500 characters is usually sufficient for a substantive entry; the 4,000-character limit gives you room to go deeper if the update warrants it)
This takes fifteen minutes. It is the cheapest indexable metadata you will ever produce, and it stacks with every other metadata investment you make. Do it before you hit submit.
Marteso’s AI metadata optimizer helps draft keyword-aware content across your entire listing. If you have not audited your current metadata, marteso.com/aso-score-checker surfaces exactly where your listing is underperforming before your next update.