更新版を提出しようとした夜のことです。ビルドのアップロードは終わり、あとは「リリースノート」を貼って審査に送るだけ、のはずでした。
ところが、画面の下に赤い警告が出て、先へ進めません。
貼ったのは、内部テストの仲間に向けて書いた更新メモでした。直した不具合、触った画面、気になった挙動まで、思いつくままに網羅してあります。自分用には良いメモでしたが、ストアの入力欄には長すぎたのです。
最初にお伝えしたいのは、Google Play のリリースノート（「このリリースの新機能」）は、言語ごとに500文字までという点です。しかも制限は言語それぞれに掛かります。日本語と英語を入れていれば、どちらか片方が超えているだけで、リリース全体が先へ進めません。
警告が出たときに見る場所
警告はリリースノートの入力欄のすぐ下に出ます。言語の見出しごとに入力欄が分かれているので、赤くなっている言語を探してください。
英語は同じ内容でも文字数が増えやすいので、日本語のメモを訳して貼る場合は、英語側が先に溢れやすいと思います。
もう一つ、見落としやすい点があります。言語が複数あるときは、全ての入力欄を上から順に見て、どれも赤くなっていないことを確かめてから提出に進んでください。
なお App Store 側の更新内容には、別の上限と別の画面があります。ここでは Google Play の話だけを扱い、数字を混ぜないことにします。
長文を捨てずに、短い版を作る
最初のうち、私は長文を削る方向で直そうとしました。結果は芳しくありませんでした。削るたびに「これも大事」と迷い、500文字の手前で手が止まります。
いまは考え方を変えています。長いメモはメモとして残し、ストア用は最初から別に書く、という線引きです。
手順は短く済みます。
- 長い更新メモを、そのままファイルに保存します（捨てません）。
- ユーザーに見える変化だけを、1機能1行で書き出します。
- 言語ごとに文字数を数え、500文字より余裕を持たせて収めます。
- 短い版もファイルに保存し、次回からは貼るだけにします。
たとえば次のような形です。
・壁紙の読み込みが速くなりました
・設定画面のボタンの位置を調整しました
・一部の端末で起動しない不具合を修正しました内部の事情や開発中の経緯は、ユーザーには要りません。「何が変わって、何が直ったか」だけが残れば十分です。
貼る前に文字数を数えておく
画面で赤くなってから直すより、貼る前に数えておくほうが夜の心臓に優しいです。次の小さな Python スクリプトは、言語ごとのファイルを読み、500文字を超えているものを教えてくれます。
# check_release_notes.py
# 使い方: python3 check_release_notes.py notes/ja.txt notes/en-US.txt
import sys
LIMIT = 500 # Play Console の1言語あたりの上限
MARGIN = 30 # 数え方の差と、貼り付け時の改行に備えた余裕
ng = False
for path in sys.argv[1:]:
with open(path, encoding="utf-8") as f:
text = f.read().strip()
n = len(text) # 改行も1文字として数える
status = "OK" if n <= LIMIT - MARGIN else ("ギリギリ" if n <= LIMIT else "超過")
print(f"{path}: {n}文字 {status}")
if n > LIMIT - MARGIN:
ng = True
sys.exit(1 if ng else 0)余裕を30文字取っているのは、絵文字などの扱いが画面の数え方と食い違うことがあるためです。ぴったり500文字を狙うより、少し短いほうが安全だと感じています。
len() が数えるのは文字の個数です。バイト数ではないので、日本語でも期待どおりに動きます。
もう一つの罠: 公開していない下書きが残っている
同じ日に、別の壁にも当たりました。新しいリリースを作ろうとして、先へ進めなかったのです。
原因は、以前に作りかけたまま公開していない下書きのリリースでした。下書きが残っていると、新しいリリースを作る入口が塞がることがあります。
私は下書きを消さず、その下書きを開いて、中身を今回のビルドとリリースノートに差し替えて使いました。それで先へ進めました。
消してもよい下書きかどうか分からないときは、消すより編集して使うほうが安全です。
提出日の前に、手元に置いておくもの
- 長い更新メモ（保存用）と、言語ごとの短い版（貼る用）を別ファイルで持つ
- 貼る前に、スクリプトで全言語の文字数を数える
- 下書きリリースが残っていないか、提出の前日に Play Console で確認する
長い記録は自分のために、短い文章はユーザーのために。 この線引きは、提出日の夜に疲れていても崩さないようにしています。
ほかにも提出日には、ID の変更不可や審査の要件など、踏みやすい場所がいくつかあります。まとめて確認したい方は、変えられる名前と、変えられない名前 — Rork で最初の1本を公開する前の30分 と、Rork Max で作ったアプリをリリースする前に確認すべきこと をあわせてご覧ください。
まずは今回のリリースの更新メモを1行ずつ見直して、ユーザーに見える変化だけを残した短い版を、ファイルに1つ保存するところから始めていただければと思います。私もそこから直しました。