How to write Microsoft Store release notes, with examples

What Microsoft says about the field

The field sits on each language's Store listing page in Partner Center, next to the description and product features. Microsoft's listing docs keep it short.

Like the rest of the listing, it's text customers see when they look at your app in the Store. Microsoft doesn't say exactly where on the page it appears or whether any formatting is rendered, so we treat it as plain text. For every other field's limit, see Microsoft Store listing limits.

Since each language has its own copy, a listing in five languages has five sets of notes to fill in for each update. Microsoft recommends a listing for every language your packages support, and the CSV import is its way to change many languages at once.

How we write them

Everything in this section is our own practice. Microsoft doesn't publish rules for what goes in the notes beyond the limit.

• Lead with the change people will notice most, and put fixes after new things.
• Say what changed for the user. "Search finds words inside PDFs" beats "Improved search indexing".
• Keep real numbers when you have them, like "opens in half the time", instead of words like "faster".
• Name the feature the way your listing and app name it, so people can find it.
• Skip internal work. Dependency bumps, CI changes, refactors, tests and code signing mean nothing to users.
• Leave out links, pull request numbers, commit hashes and contributor credits.
• Leave out changes that only affect your Mac or Linux build.
• Keep the English around 1,100 characters or less. German and French translations often run longer, and each one has to fit 1,500.
• "Bug fixes and performance improvements" tells people nothing. If that's all there is, name the worst bug you fixed.

Before and after examples

These are examples for a made-up note-taking app called Notely. Each one shows notes as they often get written and a version we'd send to the Store.

Example 1. A changelog pasted as it is.

Before:
- feat(sync): background sync worker (#412)
- chore: bump electron to 33.2.1
- fix: crash in clipboard handler when image > 10MB (#430)
- refactor: move editor state into store
- ci: sign msix in release workflow

After:
New:
- Notes now sync in the background while you work
Fixes:
- Notely no longer crashes when you paste a large image

Example 2. Notes too vague to tell anyone anything.

Before:
Bug fixes and performance improvements.

After:
Quick Note opens in about half the time it used to. We also fixed a bug where notes pinned to the taskbar sometimes opened empty.

Example 3. A big release that tries to say everything.

Before:
We're thrilled to announce Notely 4.0, our biggest release ever! After months of hard work, we've completely reimagined the editor from the ground up, ...
(2,300 characters about every change)

After:
New:
- A new editor with tables, checklists and code blocks
- Search now finds words inside PDFs and images
- Dark mode follows your Windows setting
Fixes:
- Exported Word files keep their headings

Example 4. A small fix release.

Before:
v3.8.2 hotfix, see GitHub for details

After:
This update fixes a problem where some notes didn't save if you closed Notely right after typing.

Turning a changelog into Store notes

Most apps already keep a changelog, a GitHub release or a list of commits. Here's how we cut one down.

1. Start from the section for this version only.
2. Delete every line a user wouldn't notice, like builds, dependencies, tests and refactors.
3. Delete lines that only apply to other platforms.
4. Merge lines about the same feature into one.
5. Rewrite each line as what the user sees now, and drop issue numbers and hashes.
6. Put the most noticeable change first, and stop when the rest are small.
7. Count the characters, and leave room for longer translations.

Plain, dashes or Markdown

Pick one layout and keep it from release to release, so your notes look the same every time. StoreFast lets you choose one of three per app in the app's settings.

Dashes is the default because it reads well whether or not anything gets rendered. Examples 1 and 3 above use it, and examples 2 and 4 are plain.

How StoreFast writes them

When you publish an update in StoreFast, you write What's new once in English while the package uploads. Your last notes show in the empty box as a starting point, and each language is counted against the 1,500 character limit.

If you paste a long changelog, Shorten for the Store rewrites it into a short version in your app's format and writing style. It keeps the changes a user notices, drops internal work, links, hashes and lines only about other platforms, and aims for about 1,150 characters so translations still fit. It only uses what's in your text. Undo brings your original back.

Then Translate all writes the notes in every other language of your listing, in the tone that listing already uses. That part has its own guide, translating your release notes in your app's own voice.

The same steps work from a coding agent. StoreFast's MCP server has a write_release_notes tool that takes the English, translates it into the other listing languages, and with summarize on turns a whole GitHub release or changelog section into the short Store version first. The REST API and the GitHub Action do the same.

Questions

What's the character limit for What's new in this version?

1,500 characters. Microsoft's listing docs give that limit, and it applies to each language's listing on its own.

Is What's new the same as release notes?

Yes. Partner Center used to call the field Release notes, and Microsoft's docs still mention the old name.

Should I fill in What's new on my first submission?

No. Microsoft says to leave it blank the first time you submit an app and use it for updates to an existing app.

Do I need release notes in every language?

Each language's listing has its own What's new, and you edit each language separately in Partner Center. Microsoft recommends a listing in every language your app supports, so an update usually means notes for each of them.

Can I use Markdown or HTML in the notes?

Microsoft doesn't document any formatting for this field, so we write it as plain text. Dashes and short heading lines read fine as plain text, and HTML tags would show up as typed.