How to Use the Release Notes Generator Above
The tool at the top of this page rewrites a list of changes into text you can paste into each store. It needs no account and takes a few seconds.
- Step 1
Paste Your Changes
Paste what shipped in this version: commit messages, a changelog or a rough list in your own words. The box takes up to 3,000 characters. One change on each line gives the cleanest result.
- Step 2
Add the App's Name if You Like
The name is optional. Add it when you want the texts, above all the social post, to mention the app by name.
- Step 3
Pick a Tone: Plain or Friendly
Plain states each change and stops. Friendly is warmer. A later section of this page covers which one suits which kind of app.
- Step 4
Get Three Texts Back
The generator returns App Store What's New notes in short lines, kept under 4,000 characters, Google Play release notes kept to 500 characters, and a one line social post about the update.
- Step 5
Check the Counts and Copy
Each result shows its character count against the store's limit and has a Copy button. If you edit a text afterwards, count it again before you paste it into the store.
- Step 6
Read Every Line Before You Publish
The tool uses AI on our server to rewrite what you paste. It is told to use only what you pasted and not to invent features, but a model can still misread a terse commit. Compare each line with what is in the build.
- Step 7
Know the Limits of the Free Tool
To keep it free there is a limit of 6 runs in 10 minutes for each visitor. What you paste is not stored.
What Release Notes Are and Where Each Store Shows Them
Release notes are the few lines that tell people what changed in a new version of your app. On the App Store the field is called What's New in this Version, and Apple's product page guidance says the text appears on your product page and on the Updates tab. On Google Play you type them into a box labeled "What's new in this release?" when you prepare a release, and Google's instruction on its Play Console Help page about releases is to use it to inform users about recent updates.
Fewer people read them than you would like. Apps from the App Store update automatically by default, as Apple Support's page on updating apps explains, so many users receive the new version without opening the list of updates. The readers you do get are the ones who matter: someone waiting for a fix, someone comparing two apps on their product pages, and the reviewer at App Review.
People search for this tool as an app release notes generator, an App Store release notes generator or a What's New generator. The job is the same under each name: one version, a few lines, written for the person using the app. This page is about producing that text. For finished notes to learn from, there are 20 written out in these app release notes examples, from a one line bug fix to an apology after an outage.
Release Notes Character Limits the Generator Writes To
The two stores give you very different amounts of room, which is why the generator returns a separate text for each. Limits were checked on October 12, 2026.
| Text | Where it goes | Limit | Rule to know |
|---|---|---|---|
| App Store What's New | App Store Connect, on the page for the new version | 4,000 characters | Not available for the first version of an app and required for every version after it, per Apple's platform version information reference. |
| Google Play release notes | Play Console, when you prepare the release | 500 Unicode characters for each language | Google says not to use release notes for promotion or to ask users to do something. The limit and the rule are both on the Play Console Help page. |
| One line social post | Any network you post on | Set by the network | Each network has its own limit. X's page on counting characters gives 280 characters for a post, for one, so a single line is the right size. |
| App Store promotional text, which the generator does not write | App Store Connect | 170 characters | It can be changed at any time without a new version, so it suits news that cannot wait. The first line of your What's New notes is usually a good starting point. |
To check a text after you edit it, paste it into the App Store character counter, which has a box for each of these fields.
Release Notes From Commits: A Worked Example of Good Input
This example was written by hand for this page to show the kind of input that works. The app, a hiking tracker called Trailmark, is invented, and so is version 2.4. Each row is one commit message as a developer would paste it.
| Commit message pasted | What a user would notice | Belongs in the notes? |
|---|---|---|
| feat(maps): offline maps for saved trails | Maps of saved trails open with no signal | Yes, and first |
| feat(share): export a hike as GPX | A hike can be exported as a file | Yes |
| fix(chart): elevation flat after pausing a recording | The elevation chart stays correct after a pause | Yes |
| fix(watch): crash when starting a hike from the watch | The watch app no longer crashes at the start of a hike | Yes, on the App Store |
| perf(routes): cache route list, load time 1.8s to 0.6s | The list of routes opens faster | Yes, in one short line |
| refactor(sync): move queue to an actor | Nothing | No |
| chore(deps): bump maps sdk to 9.2 | Nothing | No |
| ci: add nightly build | Nothing | No |
| docs: update README | Nothing | No |
Nine commits, five of which a user can notice. You can paste all nine, but the result is more predictable when you delete the last four yourself first, so that nothing a user cannot see has a chance to reach the notes.
What Comes Back: App Store, Google Play and Social Text for the Same Release
These three texts are an illustration of the shape of the result for the commits above, written for this page. The generator's own wording will differ from run to run.
| Text | Example | Length |
|---|---|---|
| App Store What's New | New: offline maps. Maps for your saved trails now open with no signal. Save a trail while you are online and it is ready on the mountain. New: export any hike as a GPX file from the Share menu. Faster: your list of routes opens about three times as fast. Fixed: the elevation chart no longer goes flat after you pause a recording. Fixed: a crash when you started a hike from the watch. | 385 of 4,000 characters |
| Google Play release notes | New: offline maps for your saved trails, ready with no signal. New: export any hike as a GPX file. Faster: the route list opens about three times as fast. Fixed: the elevation chart no longer goes flat after a pause. Fixed: a crash when starting a hike from the watch. | 268 of 500 characters |
| One line social post | Trailmark 2.4 is out: offline maps for every saved trail, so the map still opens when the signal does not. | 106 characters |
One line needs a human. The watch fix is an Apple Watch change, so it should come out of the Google Play text unless your Android build has the same fix. The generator works from one pasted list and cannot know which change shipped on which platform.
Release Notes From Git Commits: Which Commit Types to Keep
If your team writes commits in the Conventional Commits format, the prefix already tells you most of what belongs in the notes. The specification defines feat for a new feature and fix for a bug fix, and it mentions other types teams commonly add, among them perf, refactor, docs, test, build, ci, chore and style.
| Commit type | What it marks | In the store notes? | How to rewrite it |
|---|---|---|---|
| feat | A new feature | Yes, at the top | Say what the person can now do and where in the app to find it. |
| fix | A patch for a bug | Yes, if a user could have hit the bug | Describe the symptom in the words on the user's screen, then say it is gone. |
| perf | A change made for speed | Only if someone would feel it | Name the screen that got faster. Give a number only when you measured one. |
| Any type marked as a breaking change | The specification marks these with an exclamation mark after the type or a BREAKING CHANGE footer | Yes, when it removes or moves something users had | Say what went away or moved, and what to use in its place. |
| refactor, style, test | Code that was reorganized, reformatted or tested | No | Leave it out. Nothing changed for the user. |
| build, ci, chore | Tooling, pipelines and dependency updates | No | Leave it out, unless a dependency update fixed a bug users saw. Then write it as a fix. |
| docs | Documentation for developers | No | Leave it out. A change to help text inside the app is a different matter and can earn a line. |
The generator does not require this format. A rough list such as added offline maps, fixed the chart bug works too. The prefixes simply make it easier for you, and for the tool, to tell user facing changes from housekeeping.
How to Write Release Notes by Hand From Commits or a Changelog
The generator automates this job. Knowing the steps lets you check its work, and do it yourself on a day when you would rather not paste anything anywhere.
- Step 1
List the Commits Since the Last Release
With tags on your releases, git log v2.3..v2.4 --oneline prints one short line for each commit between the two versions. The range syntax and the oneline option are both described in the git log documentation. The related command git shortlog exists for this exact purpose: its documentation says it summarizes the log in a format suitable for release announcements, with commits grouped by author.
- Step 2
Delete What No User Can See
Go down the list and strike refactors, dependency updates, test changes and pipeline work. In the example above that removes four of nine lines.
- Step 3
Group What Is Left by Kind of Change
Keep a Changelog names six types of change: added, changed, deprecated, removed, fixed and security. For store notes three or four are enough. New, improved and fixed cover most releases, and changed or removed joins them when something a returning user will look for has moved.
- Step 4
Merge Commits That Describe One Change
A feature is often five commits. Keep a Changelog makes the distinction clearly: a commit documents one step in the code, while a changelog entry documents the noteworthy difference, often across several commits. Offline maps is one line in the notes, however many commits it took.
- Step 5
Rewrite Each Line for the Person Using the App
Replace the code's vocabulary with the screen's vocabulary. The commit says cache route list. The note says your list of routes opens faster. If a line still contains a class name, a ticket number or a library, it is not finished.
- Step 6
Put the Biggest Change First
Apple's product page guidance recommends listing new features, content or functionality in order of importance. Most readers stop after the first line, so that line should carry the reason to open the app again.
- Step 7
Cut a Separate Version for Google Play
Shorten on purpose to 500 characters. Keep the first line whole, compress the fixes, and remove anything that only shipped on Apple platforms.
- Step 8
Proofread Against the Build
Open the build and confirm that each line is true in it. On the App Store, What's New is not among the properties that Apple's list of editable properties marks as changeable without a new version, so a mistake stays on your product page until the next release.
What to Leave Out of Release Notes
Whether the text comes from the generator or from you, check it against this list before it goes into a store.
| Leave out | Why | Where the rule comes from |
|---|---|---|
| Promotion in Google Play notes: sales, discounts, new plan pitches | Google asks for information about the update and nothing else | Play Console Help says not to use release notes for promotional purposes |
| Requests to rate, review, share or follow in Google Play notes | The same sentence in Google's help covers them | It also rules out using release notes to solicit user actions |
| A generic line on a release that adds a feature | Apple allows a generic description only for simple bug fixes, security updates and performance improvements | Guideline 2.3.12 of Apple's App Review Guidelines, which says more significant changes must be listed |
| Features that are not in this build | Users will look for what you announced, and a reviewer may too | Section 2.3 of the same guidelines asks for metadata that accurately reflects the app |
| Ticket numbers, branch names and internal code names | They mean nothing outside your team | Keep a Changelog calls a dump of the commit log a bad changelog, because it is full of noise |
| Exact prices | A price written into text that every country sees may be wrong in some of them | Apple gives this advice for the app description in its product page guidance. The same logic applies to notes |
| Changes that shipped on the other platform only | A reader on Android cannot use an Apple Watch fix | Common sense, and the one thing a generator fed a single list cannot work out |
| Anything the generator added that you did not paste | The tool is told to use only your input, but you are the one publishing it | Your own check against the build |
Writing for App Review and for Users: Two Fields, Two Readers
An update on the App Store carries two descriptions of what changed. Users read one. Only App Review reads the other. The generator writes the first. Both fields are described in Apple's platform version information reference.
| Question | What's New in this Version | Notes for App Review |
|---|---|---|
| Who reads it | Everyone who visits your product page or the Updates tab | The App Review team. Apple says it is not visible to customers |
| Limit | 4,000 characters | 4,000 bytes, in any language |
| What Apple asks for | Guideline 2.3.12 asks you to clearly describe new features and product changes | Guideline 2.3.1(a) of the App Review Guidelines, as revised on October 16, 2026, asks you to describe all new features, functionality and product changes with specificity, and says generic descriptions will be rejected |
| What to put in it | What the person can now do, in order of importance | Where the new feature is, the steps to reach it, any settings needed to test it and the details of a test account |
| Example line | New: export any hike as a GPX file from the Share menu. | GPX export: open any recorded hike, tap Share, then Export GPX. The demo account has three recorded hikes. |
| Can you change it later | Only with a new version | Apple says the App Review information can be edited at any time |
| Does the generator write it | Yes | No. Write it yourself from the same list of changes |
A practical habit: once the generator has given you the user text, add one line of directions under each new feature and save that copy for the review notes.
Plain or Friendly: Which Tone to Pick for Your Release Notes
The tone changes the wording. The facts should be the same in both, which is one more thing to check when you read the result. The sample lines below were written for this page to show the difference.
Plain Suits Tools People Rely On
Banking, health, work and utility apps read best in the plain tone. So does any release that fixes a security problem or follows an outage. A plain line looks like this. Fixed: the elevation chart no longer goes flat after you pause a recording.
Friendly Suits Consumer Apps and Big Releases
Games, hobby apps and social apps can afford warmth, and a release with one feature people asked for deserves it. The same fix in a friendly tone might read like this. Stopped for a snack? Your elevation chart now picks up right where you left off.
Plain Is the Safer Choice for Google Play
With 500 characters, every friendly aside pushes out a fact. Google's rule against promotion and against asking users to act, stated on its Play Console Help page, also leaves less room for enthusiasm than the App Store does.
On the App Store, Thank the People Who Asked
Apple's product page guidance suggests using What's New to let users know you listened when a feature or a fix came from their feedback. If that is true of this release, add the sentence yourself. The generator only knows what you pasted, so include a line such as most requested feature this year in your input.
Keep One Tone Across Versions
A version history that swings from jokes to legal language reads like two different companies. Pick the tone that matches the rest of your listing and stay with it, release after release.
Localizing Release Notes After You Generate Them
The generator returns one set of texts. If your listing is in several languages, each one needs its own notes, and translating them is a step you do after generating.
On the App Store, What's New can be localized. When you add a language, its properties start out as copies of your primary language, except for the description and keywords, according to Apple's page on localizing app information. So a German listing shows your English notes until you replace them.
On Google Play the limit of 500 characters applies to each language separately. Play Console Help shows the format: each language's notes sit between that language's own tags, with the tags on separate lines. The same page describes a button that copies the notes and translations from a previous release into the box, which saves time and makes it easy to announce last month's feature twice.
Two habits prevent most problems. Keep the source text well under the limit, because a translation is often longer than the English. And use the feature names exactly as they appear in the translated app, or the notes will send people looking for a button that is called something else. The steps are set out in full in the section on localization in the app release notes examples.
Release Notes vs Changelog vs Update Announcement
People use the three words for each other, and a changelog generator is often what they find when they wanted store text. They are three documents with three readers.
| Question | Release notes | Changelog | Update announcement |
|---|---|---|---|
| What it is | A few lines on one version, shown in the store | A file or page with a curated list of notable changes for every version, in order of date, as Keep a Changelog defines it | A post, email or message telling people the update exists |
| Who reads it | Users and shoppers on your store page, and App Review | Developers, power users, support staff | Followers and subscribers, many of whom have not opened the app lately |
| Where it lives | App Store Connect and Play Console | Your repository or your website | Social networks, your newsletter, in app messages |
| How long | A few lines. At most 4,000 characters on the App Store and 500 on Google Play | As long as the history of the product | One idea, with a picture |
| What goes in | Changes a user can notice, biggest first | Every notable change, grouped by type, newest version at the top with its date | The single most interesting change and a reason to open the app |
| Does the generator write it | Yes, one text for each store | No | A one line social post to start from |
Keep a Changelog puts its own purpose in one line: "Changelogs are for humans, not machines." The same holds for store notes. Version numbers help you decide how much to write: under Semantic Versioning a patch version means bug fixes, a minor version adds functionality and a major version marks a breaking change. A patch needs notes. A minor or major release also deserves an announcement, and there are worked posts in these app update announcement examples.
Other Ways to Generate Release Notes: GitHub, GitLab, Jira and Git
Developer platforms have release notes generators built in. Most produce a list for other developers. The tool on this page is ours and comes first in the table because it is the one that writes text for the two app stores. Each of the other rows was checked against the vendor's own documentation on October 12, 2026.
| Tool | What it reads | What you get | Best used for |
|---|---|---|---|
| The release notes generator on this page | Any text you paste, up to 3,000 characters | App Store What's New notes, Google Play notes within 500 characters and a one line social post, each with its character count | Store text written for users, with no account |
| GitHub automatically generated release notes | The merged pull requests of a release | GitHub's documentation says the result includes a list of merged pull requests, a list of contributors and a link to a full changelog. Labels can sort pull requests into categories of your choosing | The release page of a repository |
| GitLab changelogs | Commit titles and Git trailers | GitLab's documentation says a commit is included when it carries a Changelog trailer, and that entries are grouped by the trailer's value, such as added, fixed or changed, under a heading with the version and date | A changelog file kept in the repository |
| Jira release notes | The work items assigned to a version | Atlassian's support page says Jira generates notes for all the work items in a version, grouped by work type, which you can copy as markdown or HTML or turn into a Confluence page | A report for stakeholders on what a version contained |
| git shortlog | The commits in a range | A summary of the log grouped by author and commit title, in the terminal | Raw material when you use none of the platforms above |
None of the four platform tools writes for a person browsing a store. Their output is a good thing to paste into the generator above: a list of pull request titles or work items is exactly the kind of rough input it is built to rewrite.
Release Notes Generator on GitHub: Automatic Release Notes and Label Categories
GitHub's built in generator is the one most developers already have. Here is how to get a clean list out of it, every step checked against GitHub's documentation on October 17, 2026, and how to turn that list into store text.
- Step 1
Generate Notes From the Release Form
Open Releases in the repository and click Draft a new release. Choose or create the tag, then, above the description field, pick the previous release in the Previous tag menu and click Generate release notes. GitHub fills in the merged pull requests, the contributors and a link to the full changelog. Its own instruction for the next step is to check that the notes include all, and only, the information you want.
- Step 2
Sort Pull Requests With a Release Config File
Create a file at .github/release.yml. Under changelog, each entry in categories needs a title and a list of labels, and a pull request with one of those labels lands under that title. A label of * works as a catch all for pull requests that matched no earlier category. Under exclude you can list labels and authors to leave out, which is the usual way to keep dependency bots and pull requests labeled ignore for release out of the notes.
- Step 3
Generate Notes From the Command Line
The GitHub CLI does the same job in a script. According to the gh release create manual, the generate notes flag fills the notes through GitHub's release notes API, a notes start tag flag sets the tag to start from, and any text passed with the notes flag is placed before the generated part. That last one is handy for a sentence of your own above the list.
- Step 4
Generate Notes Through the API
The REST endpoint to generate release notes content for a release returns a name and a markdown body covering changes since the last release and the people who contributed. GitHub states that the result is not saved anywhere, so it is meant to be used straight away when you create the release.
- Step 5
Rewrite the List for the Stores
What comes back is written for developers: pull request titles, usernames and links. Copy the titles under your feature and fix categories, paste them into the generator at the top of this page, and you get App Store and Google Play text from the same release in one more step.
GitHub Auto Generate Release Notes Not Working? What to Check
When the generated notes come out empty, too long or oddly sorted, the cause is usually one of these four.
The Previous Tag Is Wrong
The notes cover the range between the previous tag and the new one. If the Previous tag menu points at an older release than the one that really came before, the list includes every release in between. Pick the tag of the release that actually came before.
The Work Was Never a Pull Request
GitHub describes the output as a list of merged pull requests. A change pushed straight to the branch has no pull request to list, so it will not appear. If your team pushes directly, use git log over the tag range instead, as described earlier on this page.
Labels Do Not Match the Config File Exactly
A pull request goes into a category only when it carries one of the labels listed for it. A label named bug will not match a category that lists fix. Add a final category with the * label so anything unmatched still has a heading, then fix the labels at the source.
The File Is in the Wrong Place
The file has to sit in the .github folder. GitHub's release notes API reference says that unless another path is given, it uses .github/release.yml or .github/release.yaml, and falls back to the default layout when neither exists. A file in the repository root is ignored the same way a missing one is.
Release Notes Generator GitHub Action: Release Please, Semantic Release and GitHub CLI
If you want notes produced on every release without anyone clicking a button, these three run inside a GitHub Actions workflow. Each row was checked against the project's own documentation on October 17, 2026. All of them write for developers, so the store text is still a separate step.
| Tool | What it reads | What it does | Store notes? |
|---|---|---|---|
| Release Please | Conventional Commit messages in your git history | Its README says it automates changelog generation, GitHub releases and version bumps by keeping a release pull request up to date. When you merge that pull request, it updates the changelog, tags the commit and creates the GitHub release. A fix maps to a patch version, a feat to a minor one and a type with an exclamation mark to a major one. It does not publish to package managers. | No. Paste the feat and fix lines from its changelog into the generator above |
| Semantic Release | Commit messages, by default in the Angular convention | Its README describes it as automating the whole package release: working out the next version number, generating the release notes and publishing the package. It is meant to run in CI after every successful build on a release branch. | No. It is built for packages, so the notes it writes describe the code |
| gh release create | Merged pull requests since the start tag | A workflow step can run the GitHub CLI with its generate notes flag. It calls GitHub's release notes API, which the API reference says uses the .github/release.yml file when no other configuration file is given, so your label categories apply. | No. Same output as GitHub's button |
Both Release Please and Semantic Release depend on commit discipline. If your commits follow Conventional Commits, the table earlier on this page shows which types belong in store notes. If they do not, a pull request based tool such as gh with labels is the easier fit.
Video: How to Use GitHub Actions
Every tool in the table above runs as a GitHub Actions workflow. GitHub's own beginner episode shows how a workflow is built.
Release Notes With AI: A Prompt for ChatGPT, Claude or Gemini
The generator on this page is one way to write release notes with AI. If you would rather use the assistant you already pay for, the prompt matters more than the model. Most bad AI release notes come from a prompt that says only write release notes for this, which leaves the model free to add adjectives, guess at features and ignore both stores' limits.
A prompt that works sets the same rules this tool follows. You might write: Rewrite the changes below as release notes for app users. Use only what is listed and add nothing. Leave out refactors, dependency updates, tests and anything a user cannot notice. Put the most important change first. Start each line with New, Improved, Changed, Removed or Fixed, and describe fixes by the symptom the user saw. Write two versions: one for the App Store under 4,000 characters, and one for Google Play under 500 characters with no promotion and no request to rate, review or share. Do not mention ticket numbers, internal names or prices. Then paste the changes for one version under it.
Read the answer the way you would read the generator's. Check each line against the build, count the Google Play version yourself, because models are unreliable at counting characters, and take out anything that shipped on only one platform. The mistakes listed above apply to any assistant, not just this tool.
Once the notes are live, the same assistant can help with the post about them. Spreadcast has an MCP server, so Claude or ChatGPT can design an update post in your app's brand and save it as a draft. How to connect it is on the Spreadcast MCP page.
A Release Notes Template for What You Paste
No commit log to hand? Fill in this template and paste it. It is a template for the input. For a fill in the blanks template of the finished notes, see the one in the app release notes examples.
| Line to write | Example | Why it helps |
|---|---|---|
| Version and platforms | Version 2.4, iPhone and Apple Watch | Keeps platform specific changes from leaking into the wrong store's text |
| New, one line for each feature | New: offline maps for saved trails, on the trail screen | Naming the screen lets the notes tell people where to look |
| Improved | Improved: route list loads in 0.6 seconds, was 1.8 | A measured number can be turned into a claim. A vague one cannot |
| Fixed, as the symptom and the situation | Fixed: elevation chart went flat after pausing a recording | The user knows the symptom, never the cause |
| Changed or removed | Changed: export moved from Settings to the Share menu | Returning users look for things where they used to be |
| Where it came from, if you want it said | Offline maps was the most requested feature this year | The generator can only thank users if you tell it there is something to thank them for |
Leave refactors, dependency updates and test work off the list. Never paste passwords, API keys or customer names. Nothing you paste is stored, but none of it belongs in public notes.
Seven Mistakes to Avoid With an AI Release Notes Generator
Publishing Without Reading
The texts come from a model that saw your list and nothing else. It has never opened your app. Read each line as a user would and check it against the build.
Pasting Three Versions at Once
The result will blend them into one update. Paste the changes for the version you are submitting and nothing older.
Pasting Commits That Say Nothing
A line such as fix bug or wip gives the tool nothing to rewrite, and it is told not to invent anything. Spend a minute turning those lines into what was fixed and where.
Leaving a One Platform Change in Both Texts
The worked example above has one: the Apple Watch fix. Take it out of the Google Play text before you paste.
Letting a Feature Release Shrink to a Generic Line
If you trim the result down to bug fixes and performance improvements on a version that adds a feature, you are on the wrong side of guideline 2.3.12 of Apple's App Review Guidelines, which wants significant changes listed.
Choosing Friendly for Bad News
A security fix, a removed feature or an apology after an outage needs the plain tone. Warmth in the wrong place reads as not taking the problem seriously.
Stopping at the Store
The notes are done and the update is live, and nobody outside the Updates tab knows. The one line social post is there to be used. A plan for where to post it is in how to promote an app on social media.
After the Update Is Live, Spreadcast Turns It Into a Post for You
The generator on this page is a free tool from Spreadcast and works without the product. It covers the writing. The product covers what comes next, which is the part most teams skip: telling anyone the update shipped.
You paste your App Store link once at the start page. Spreadcast then checks your App Store listing every day. When a new version appears, it boils the release notes down to two or three points, sets them on a designed image with your app's own screenshot, and publishes the post on the networks you connected, or holds it for one tap of approval. New 5 star reviews and rating milestones become posts the same way. It works with App Store listings today.
Good notes make a better post, since the post is built from them. The Free plan drafts every post for 1 app, and the paid plans are on the pricing page. For the wider plan around a release, read how to market an app or see the product launch post generator.
Frequently Asked Questions
What is a release notes generator?
It is a tool that turns a list of changes into the short text users read about a new version. The one on this page takes commit messages, a changelog or a rough list and returns App Store What's New notes, Google Play release notes and a one line social post.
Is this release notes generator free?
Yes. It is free and needs no account. To keep it free there is a limit of 6 runs in 10 minutes for each visitor.
Can I generate release notes from git commits?
Yes. Paste the commit messages for the version, for example the output of git log with the oneline option described in the git log documentation. The generator rewrites them as notes for users. For a cleaner result, delete housekeeping commits such as refactors and dependency updates first.
Will the AI release notes generator invent features?
It is told to use only what you pasted and not to add anything. A model can still misread a short or unclear line, so read the result against your build before you publish it.
Is what I paste stored?
No. The text is sent to our server so the AI can rewrite it, and it is not stored afterwards. Leave passwords, keys and customer names out of your input all the same.
What is the character limit for release notes on the App Store and Google Play?
What's New on the App Store is limited to 4,000 characters, per Apple's platform version information reference. Google Play allows 500 Unicode characters for each language. The generator keeps each text inside its store's limit and shows the count.
What is the difference between release notes and a changelog?
Release notes are a few lines about one version, written for users and shown in the store. A changelog is the full history of notable changes across every version, usually kept in the repository or on a website for developers and support.
Can I use the same release notes for the App Store and Google Play?
Only if they fit in 500 characters and stay clear of promotion, which Google does not allow in release notes. That is why the generator returns a separate, shorter text for Google Play.
Where These Facts Come From
Every outside number, rule and price on this page links to the page it was taken from.
- Platform version information reference: What's New and App Review notesApple Developer, App Store Connect Help
- Required, localizable and editable propertiesApple Developer, App Store Connect Help
- Localize app informationApple Developer, App Store Connect Help
- Creating your product pageApple Developer
- App Review Guidelines, guidelines 2.3.1(a) and 2.3.12Apple Developer
- How to manually update apps from the App StoreApple Support
- Prepare and roll out a releaseGoogle Play Console Help
- Conventional Commits 1.0.0Conventional Commits
- Keep a Changelog, version 1.1.0Keep a Changelog
- Semantic Versioning 2.0.0Semantic Versioning
- git log documentationGit
- git shortlog documentationGit
- Automatically generated release notesGitHub Docs
- ChangelogsGitLab Docs
- Create release notesAtlassian Support
- Counting characters in postsX Developer Platform
- gh release create manualGitHub CLI
- REST API endpoints for releases: generate release notes contentGitHub Docs
- Release Please READMEGoogle, googleapis on GitHub
- Semantic Release READMESemantic Release on GitHub
- Video: how to use GitHub ActionsGitHub
Researched and written by Spreadcast. Last checked on October 17, 2026.