The "What's New" field on the App Store and Google Play is the quietest part of release management. No one praises you for writing it, but readers click through more often than you would expect.
I'm Masaki Hirokawa — an artist and indie developer who has been shipping apps since 2014. Over the last three weeks I ran a small experiment: write the release notes for all six of my wallpaper apps in the same week, at the same tone, with Rork as the source of truth. These are the things I noticed.
Why bother syncing six apps
The honest answer is that I did not bother for the first several years. Each app got its release notes whenever I happened to remember. With cumulative downloads passing 50 million across the portfolio, I started looking at the review pages side by side, and the tone was completely inconsistent. One app spoke in emojis. Another said only "Bug fixes." It did not feel like the same author had written them.
Both of my grandfathers were temple carpenters in Japan, and I grew up watching how things from a single workshop stayed consistent even where no one would ever look. Release notes feel like the same kind of place — the parts no one inspects are the parts worth lining up.
The rules I held for three weeks
The whole protocol fits in three lines.
- Only include changes that can ship in the same week — no single app gets a flashier note than the others.
- Use the same three-block structure across all six apps: one headline change, two or three improvements, one behind-the-scenes fix.
- Keep Japanese and English in lockstep at minimum, expanding to more locales through templates rather than translating from scratch.
Over three weeks that meant 18 individual release notes (six apps, three rounds). The first week took half a day because I was still inventing the template. By the third week I could produce all 18 in about half an hour.
What I changed on the Rork repository side
Because Rork manages the codebase, I put release notes in the same repository as the app and reviewed them through pull requests. The layout looks like this:
release-notes/
├── 2026-05-08/
│ ├── en.txt # App Store US / Google Play en-US
│ ├── ja.txt # App Store Japan / Google Play ja-JP
│ └── meta.json # Build number and target app
├── 2026-05-15/
│ └── ...
└── README.md # Template and writing rules
The meta.json carries the app identifier, version number, and intended release date. I have a separate App Store Connect API job using JWT to push the What's New text automatically, but the scope of this three-week experiment was just "land the six text files in the same place every week."
Three things I did not see coming
The official documentation did not warn me about any of these.
1. App-specific feature names refuse to translate cleanly
Each of the six apps has its own internal name for a feature — "Favorite Lock," "Shuffle Play," "Auto Wallpaper Rotation." Translating them into English diverged across apps. The single biggest time saver was creating a shared feature-name glossary that all six release notes look up. Review time across the 18 notes dropped by roughly a third the moment I added that.
2. Build numbers and What's New drift apart
After saving a What's New entry on App Store Connect, swapping the underlying build sometimes attached the old text to the new binary. EAS Build auto-increments numbers, but What's New is a manual step. I had to lock in the order: write the What's New first, then upload the build. Reversing those two steps was where I lost time.
3. Same tone, every week, starts to sound robotic
By week three the template had become a little too efficient. Every note read like a changelog. I started intentionally reserving one sentence per release for something the template could never produce — for example, "Added 50 wallpapers of spring flowers." A human line, mechanical in nothing but length.
What the numbers showed
Three weeks is too short for any AdMob eCPM or DAU shifts to surface. The one signal I could read was that the average review length across the six apps moved from 38 to 51 characters. Users mentioned the new release more often, which I take as a sign that someone is actually reading the What's New.
Designing for a four-post-a-day life
I run four technical blogs in parallel, and on top of that I ship app updates. That means I write a lot of short outputs every day. Release notes are the shortest and most frequently read of them. When something is that short, hesitation kills the cadence.
What three weeks taught me is that a template that survives needs two parts: a mechanical scaffold and one line a human must write by hand. Fully automate it and the personality disappears. Fully handwrite it and the cadence collapses. I think this principle generalizes to any indie developer running six or more apps in parallel.
What I plan to try next
There are three follow-ups already on the bench.
- A CI job that posts the
release-notes/content to App Store Connect through the JWT-authenticated API. - Expanding from two locales to six (Japanese, English, Chinese, Korean, Spanish, French).
- Aggregating feature names that appear in user reviews each week and feeding them back into the next What's New.
Twelve years into building apps alone, this is still a corner I was undervaluing. If you also run several apps in parallel, the cheapest experiment is the smallest one: write all your release notes in the same week.