Guide
How to write App Store What's New text
Write clear, honest What's New release notes for the App Store. Structure, tone, localization tips, and how Helm templates keep every locale consistent.What’s New is the changelog your customers actually see. Done well, it builds trust and highlights work that would otherwise stay invisible. Done poorly, it reads like filler. This guide shows a structure you can reuse, plus how Helm releases help you keep every locale in sync.
What good What’s New copy does
- Names the customer-visible change
- Stays honest about scope
- Scans in a few seconds on iPhone
- Avoids insider jargon and ticket IDs
- Leaves room for locales without overflowing limits
You are writing for people updating an app they already own, not for App Review. Still, empty or nonsensical notes look careless in both places.
A reliable structure
Use this pattern for most updates:
- One-line summary of the release theme (optional but helpful for larger updates)
- Bullets for user-facing features and fixes
- Thanks or support nudge only when it earns the space
Example shape:
This update makes sharing faster and fixes a crash on iOS 18.
- New share sheet actions for projects
- Improved offline sync when you return online
- Fixed a crash when opening large attachments
For tiny bug-fix releases, skip the theme line and keep two or three concrete bullets.
What to include
- Features people can find without a tour
- Fixes for issues customers reported
- Performance or battery improvements when they are real
- Platform support changes (new OS, new devices) when relevant
What to skip
- Internal refactors with no user effect
- Vague lines like “bug fixes and improvements” as the only content
- Marketing hype that oversells a small change
- Joke release notes that hide a serious fix people need to notice
- Competitor digs
“Bug fixes and improvements” is fine as a final bullet after specifics, not as a substitute for them.
Tone
Match your product. A kids’ app can be playful. A banking app should stay plain. In every case, prefer active verbs: added, fixed, improved, redesigned, removed.
Write as “you” when it helps (“You can now export CSV”), and avoid corporate filler.
Localization
Translate What’s New for every locale you maintain. A German listing with English release notes feels unfinished. Bootstrap from your base language, then adjust for length and clarity. See localize your App Store listing and translate app metadata.
Watch character limits per field. A witty English line may not fit after translation. Prefer simple sentences when you ship many languages.
Templates without sounding robotic
Helm supports release templates so recurring sections stay consistent: intro line, bullets, footer with support link. Templates should hold structure, not force identical wording across unrelated releases.
A useful Pro workflow: draft in your base language, apply or translate across locales, then skim the highest-traffic storefronts before submit. Release notes can also be reused across platforms when iOS and Mac ship together.
Timing
Write What’s New when the scope of the release is frozen, not during early development. Update the notes if you drop a feature from the build. Misleading release notes erode trust faster than a short honest list.
Pair with promotional text
Promotional text can change without a new binary. Use it for time-sensitive campaigns. Keep What’s New tied to what shipped in this version so the two fields do not contradict each other.
Pre-submit checklist for notes
- Base locale filled
- All other shipped locales filled or intentionally inherited per your process
- No placeholder text (“test”, “lorem”, ticket numbers)
- Mentions match the binary
- Support URL still valid if you referenced it
