What’s New release notes App Review checklist
What’s New text is not filler. It is a public record of what the submitted build changes for users.
Tie every release-note claim to the exact build under review. Apple App Store Connect submission flow depends on app information and submitted builds. AppReviewReady interpretation: What’s New should be concise, user-visible, and synchronized with the binary, server configuration, screenshots, and support plan.
List what actually changed
Separate user-visible features, bug fixes, performance improvements, compliance changes, pricing changes, removed features, and server-only changes. Do not include roadmap promises that are not in the submitted build.
If a release fixes a rejection, the release note can stay user-facing while Review Notes carry the detailed reviewer path.
Remove unsupported claims
- Avoid claiming faster, safer, most accurate, medically reliable, or guaranteed unless evidence supports it.
- Do not announce unavailable countries, beta features, or hidden server flags.
- Make subscription, pricing, or entitlement changes clear enough for users.
- Localize release notes only when the feature is available in that locale.
- Avoid generic notes that hide meaningful safety, privacy, or commerce changes from support.
Align notes with product state
What’s New should match screenshots, app description, support macros, feature flags, and the selected build. A mismatch can make reviewers wonder whether they are testing the correct version.
AppReviewReady interpretation: release notes are an operational coordination tool. They help support, marketing, and review understand the same version.
Add release-note QA
- Compare release notes with the merged release branch and build provenance record.
- Check legal, privacy, and safety wording for sensitive changes.
- Review all localizations for claims and availability.
- Update support and status pages if users may ask about the change.
- Archive the final text with the release record.
Release-note evidence template
A good note is specific without turning into a changelog for internal refactors. Users should understand why the update matters.
After launch, compare support tickets and app ratings with the release note. Confusion around an update can reveal missing migration copy or a mispositioned change.
If a release removes a feature, write the note from the user's perspective and prepare support copy. Quiet removals can reduce immediate attention but increase refund, rating, and review risk when users notice later.
For compliance fixes, avoid over-disclosing security details while still being truthful. A note can say that privacy controls, purchase handling, or account recovery improved without exposing implementation weaknesses.
When release notes are localized, ensure the same change is actually available in that locale. A translated note can accidentally announce a feature to a market where the server flag is still off.
For phased releases, keep notes stable while rollout is in progress. Changing the note mid-rollout can make support diagnosis harder.
What’s New record: Build/version: [numbers] User-visible change: [summary] In-app proof: [screen] Server flag needed: [yes/no] Locale availability: [markets] Support impact: [notes] Review-note detail: [yes/no]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check release notes
Review What’s New copy, build alignment, localization, and support impact before submission.
Open the tool