リリースノート

アプリの名前を変える — 表示名は変え、識別子は変えない

こども向けの「やること」アプリの名前を、2.0.0 で「でいりんぐ」から ぽんっ！ に変えました。

きっかけは実際の使われ方です。こどもに使ってもらっている場面で、家族が「今日もぽん、がんばろうね」と声をかけていました。スタンプを押す音でアプリを呼んでいたわけです。呼ばれ方がすでに変わっていたので、そちらに寄せました。

検索での見つかりやすさ（ASO）が下がる可能性はありました。旧名にはそれなりの検索実績があり、新しい名前は一般語に近いためです。それでも わかりやすさを優先 しました。こども向けのアプリで、名前を口に出す相手はこどもです。読めない名前・呼びにくい名前は、そもそも選ばれません。

改名は「文字列を置換する作業」に見えますが、設計判断はほぼ一箇所に集まります。何を変えて、何を変えないか の線引きです。

名前と識別子を分ける

先に線引きを決めました。

ストアのアプリ識別子を変えないのが最重要です。変えると ストア上は別アプリになり、既存ユーザーへ更新が届きません。レビューも購入履歴も引き継がれず、名前を変えたいだけの変更が実質的な新規リリースと移行作業に化けます。

言い換えると、識別子は名前の一部ではありません。利用者が読む名前と、システムが同一性を判断する識別子は、別の目的を持つ別のデータ です。同じ文字列を由来にしていたとしても、改名で揃える必要はありません。

署名鍵のファイル名も変えていません。揃えても得るものがなく、事故の余地だけが増えます。

日本語だけ「ぽんっ！」で、英語表示名とその他の識別子は Ponto に揃えました。

両 OS ともロケール別の表示名リソースを標準で持てるので、値の差し替えだけで済みます。コードから参照される名前と、人が読む名前を最初から分けておく と、後者だけを差し替えられます。改名で作業量が読めるかどうかは、ここが分かれているかにかかっています。

コード内のパッケージ名の変更は、import 1500 箇所あまりに及びました。テキスト置換で終わる作業に見えますが、テキストとして扱えないファイルが混ざります。制御文字を含むテストデータは、テキスト検索が対象外にするため一括置換から漏れます。

そこでバイト単位で走査し直し、旧名が1つも残っていないことを確認しました。一括置換は置換の手順ではなく、置換と全数確認をセットにした手順 として設計します。確認の方法を先に決めておけば、置換自体は何回でも安全に繰り返せます。

このアプリは、利用規約のページとアプリ内リリースノートの配信を自社サイトに依存しています。どちらもアプリ側が URL と識別子を持って参照しています。

新しい URL・新しい識別子への切り替えをアプリ側だけ先に出すと、サイト側が新しい名前を知らないあいだ、リリースノートが 0 件になり、規約ページが 404 になります。順序に制約があります。

旧参照を受け続ける期間は 無期限 です。配布済みの旧バージョンは旧 URL と旧識別子を参照し続けます。ストアの自動更新に乗らない端末は残るので、「移行期間を設けて閉じる」ことはできません。改名でリダイレクトを張るときは、期限付きの互換ではなく恒久的な受け口として設計します。

もう一つ決めたのは、順序の制約がある変更を他の変更と同じ PR に混ぜない ことです。混ぜると、掲載画像を差し替えたいだけのリリースが、サイト側のデプロイを待たされます。参照の切り替えだけを独立した変更として切り出し、サイト側の公開後に単独で進めました。

コードの旧名は検索で漏れが分かります。一方で画像に焼き込まれた文字は検索に写りません。ストア掲載画像・SNS 画像・Play のフィーチャーグラフィックは、コードとは別の手当てが必要になります。

ここは根本的には生成器の問題です。ストア用と SNS 用で別の生成器・別のコピー源を持っていると、名前を変えたときに片方が取り残されます。掲載素材の生成器を1本にまとめてコピーの単一情報源から読ませた話は、掲載画像を横長にし、生成器を1本にするに分けて書きました。

2.0.0 にしています。機能追加の量ではなく、利用者の認識が変わるかどうか で決めました。ホーム画面のアイコンの名前が変わるのは、機能が1つ増えるより大きい変化です。

そのぶん、リリースノートは名前の話を先頭に置き、スタンプの記録・育てているキャラクター・家族の連携がそのまま引き継がれること、ログインし直しや設定のやり直しが不要であることを明記しました。

この一文を書けるかどうかは、識別子を変えないという最初の線引きに直結しています。利用者に約束できることが、技術的な線引きで決まる という関係です。