“Bug fixes and improvements” is costing you installs.

It's the most-shipped sentence in software, and it survives because of a belief that's half true: nobody reads release notes. Your existing users mostly don't — updates install themselves overnight. But the field renders on your product page with a date stamped next to it, and the people deciding whether to install your app at all? They read it.

Who actually reads release notes

Start with who doesn't. Both stores turn automatic updates on by default, and Apple removed the Updates tab back in iOS 13 — pending updates now sit behind the profile icon, where nobody wanders by accident. The casual "what did this update do?" reader you're picturing barely exists anymore. Updates arrive silently, and silence is fine.

That leaves three readers, and none of them is casual. First, and biggest: a prospective user on your product page, mid-decision, scrolling past your screenshots toward the install button. Second: an existing user who hit a bug and is checking whether you fixed it — which is another way of saying they're deciding whether to keep your app or delete it. Third: the user an update once burned, who now reads before allowing anything to change. Every one of them is at a decision point, holding your release notes as evidence.

What the field says when you say nothing

On the App Store, the What's New section carries the version number and how long ago it shipped; Google Play prints an "Updated on" date in the listing. Before anyone reads a word, that date answers the question every prospective user quietly asks: is this thing alive? An app last touched eleven months ago reads as risk — will it work on this year's OS, is the developer still around, will a support email ever get answered. A recent date plus a specific, human sentence reads as a product with someone behind it. The date does more work than the text, which is exactly why the text next to it shouldn't squander the moment.

"Bug fixes and improvements" answers none of the questions those three readers brought. The prospect learns nothing about momentum. The bug-checker learns nothing about their bug — was the crash fixed, or wasn't it? And paired with a frequent update cadence, boilerplate reads as automated: the store equivalent of a status page that always says "operational." Compare the listing whose latest note says "Fixed the crash when importing more than 50 photos — thanks to everyone who wrote in." One line, and it answers the entire trust question: bugs here get found, reported, and fixed, and the developer is listening.

Big apps write boilerplate. Their excuse isn't yours.

The boilerplate habit trickles down from apps with real reasons for it. A team shipping on a weekly release train writes notes before the release is even cut, so there's nothing specific to say yet. Features behind server-side flags mean what's actually "in" a given build differs from user to user. And every sentence has to be localized into dozens of languages on a deadline. For a company like that, "bug fixes and improvements" is arguably the honest option.

None of that describes an indie developer shipping every few weeks, who knows exactly what changed and answers their own support email. Copying the big-app format imports the constraint without the reason — and skips the part where those apps don't need their product page to earn the install. Instagram converts on its name. You convert on your page.

Writing a note that earns its slot

Lead with the one change a user would notice, in outcome language. The same rule that governs screenshot headlines governs the first line here: not "Refactored sync engine" but "Sync no longer loses edits made offline." If the release genuinely contains nothing user-visible, say what the work was for — "Groundwork for folders, coming next month" beats pretending nothing happened.

Name the bugs you fixed. This feels like admitting weakness; it's the opposite. Every reader already knows software has bugs — the open question is whether yours get fixed, and how fast. "Fixed the widget going blank after midnight" tells affected users you fixed their bug specifically, and tells prospects this is an app where problems get handled.

Write for the fold. Apple gives the field 4,000 characters and Google Play gives it 500, but both stores collapse it to a few lines behind a "more" control — and almost nobody taps "more." Two to five short lines, the most important first. If a line reads like a press release, cut it: the person reading is closer to your actual product here than anywhere else on the page, and marketing voice at that distance rings false.

Don't bother stuffing keywords. Apple's search index reads your name, subtitle, and keyword field — What's New isn't part of it. Like promotional text, it's a pure conversion surface: its only job is the reader in front of it.

Write it when you cut the release, not in the submission form. On iOS the field is version-locked: it ships with the build and can't be edited once the version is live, part of the same split we mapped in what you can update without a build. On Play it rides the rollout. Either way, the 11pm submission screen is the worst place to compose it — put "write the note" on the release checklist next to "tag the build."

The note is one line of a bigger page

Release notes convert when the rest of the page holds up its end — screenshots that lead with outcomes, a subtitle that says something, a description written for the store that actually indexes it. ShotCanvas treats the listing as one system: design your screenshot set from templates or let AI compose it, generate the metadata, and publish straight to App Store Connect and Google Play from one place. The free tier covers your first sets, no credit card.