The build had uploaded. All that was left was pasting the release notes and sending the update for review. Then a red warning appeared under the text box, and I couldn't move forward.
What I'd pasted was a memo written for my internal testers: every bug fixed, every screen touched, every odd behavior I'd noticed. It was a good memo for me. It was far too long for a store field.
Here's the thing to know up front: Google Play's "What's new in this release" field accepts 500 characters per language. The limit applies to each language separately, so if you've added Japanese and English, one language going over is enough to stall the whole release.
Where to look when the warning appears
Each language has its own box, and the one that's over the limit turns red. English tends to run longer for the same content, so if you translate a Japanese memo, the English box is the one most likely to overflow first.
One more thing that's easy to miss: when you have several languages, scroll through every box and confirm none of them is red before you submit.
The App Store has its own, separate field and limit. I'm only covering Google Play here so the numbers don't get mixed up.
Keep the long memo, write the store version separately
My first instinct was to trim the long memo. It went badly. Every cut felt like losing something important, and I stalled just short of 500.
What I do now is keep the long memo as a memo and write the store text from scratch:
- Save the long memo as a file. Don't throw it away.
- List only what users can see, one feature per line.
- Count characters per language and stay comfortably under 500.
- Save the short version too, so next time you just paste it.
- Wallpapers now load faster
- Adjusted button positions on the settings screen
- Fixed a crash on launch on some devicesInternal context doesn't belong there. "What changed, what got fixed" is enough.
Count before you paste
It's kinder to your nerves to count first than to find out from a red warning at night. This small Python script reads one file per language and flags anything over the limit.
# check_release_notes.py
# Usage: python3 check_release_notes.py notes/ja.txt notes/en-US.txt
import sys
LIMIT = 500 # Play Console limit per language
MARGIN = 30 # cushion for counting differences and pasted line breaks
ng = False
for path in sys.argv[1:]:
with open(path, encoding="utf-8") as f:
text = f.read().strip()
n = len(text) # line breaks count as one character
status = "OK" if n <= LIMIT - MARGIN else ("tight" if n <= LIMIT else "over")
print(f"{path}: {n} chars {status}")
if n > LIMIT - MARGIN:
ng = True
sys.exit(1 if ng else 0)I keep a 30-character margin because emoji and similar characters can be counted differently by the console. Aiming slightly short has been safer than aiming for exactly 500.
len() counts characters, not bytes, so it behaves as expected for Japanese text too.
The second trap: an unpublished draft release
The same day I hit another wall: I couldn't create a new release. The cause was an old draft release I'd started and never published. A leftover draft can block the way to a new one.
I didn't delete it. I opened the draft and swapped in this build and these release notes, and that got me through. If you aren't sure a draft is safe to delete, editing it is the safer move.
What I keep next to me on submission day
- A long memo for me and a short, per-language version for the store, as separate files
- A script run across every language before pasting
- A check the day before for any leftover draft release in the Play Console
Long records are for me; short text is for the user. I try to hold that line even when I'm tired on submission night.
If you'd like to catch other submission-day traps in one pass, see The names you can change, and the ones you can't and Rork Max App Store & Google Play Submission Checklist 2026.
Start with your current release: go through the update notes line by line, keep only what users will see, and save that short version as a file. That's where I started too.