Gitのコンフリクトを乗り越えて機能修正を終え、いよいよ初めてのアップデートをApp Storeに申請することになりました。初回の公開審査は一度落ちた経験もあり緊張していましたが、アップデートは想像していたのとは違う部分でつまずきました。今回はその流れの記録です。
1. バージョン番号とビルド番号を混同していた
Xcodeで新しいビルドをアップロードしようとしたら、「同じビルド番号は使えません」というエラーで弾かれました。
Version: 1.0.1 ← ユーザーに見える番号
Build: 3 ← アップロードのたびに増やす内部番号最初はVersion（ユーザーに表示される番号）だけを上げれば十分だと思っていたのですが、Build（内部管理用の番号）も毎回必ず増やす必要があると知りませんでした。アップロードのたびに機械的にインクリメントする番号と、リリースの意味を持つ番号が別物だと理解してからは、迷わず作業できるようになりました。
2. 「審査対象は差分だけ」だと勘違いしていた
アップデートだから、前回審査済みの部分は見られず、変更した箇所だけがチェックされると思い込んでいました。
今回の変更点:
- ダークモード対応
- フィードバック機能の追加しかし実際には、アップデートのたびにアプリ全体が改めて審査対象になります。前回通過した部分でも、ガイドラインの解釈が変わっていたり見落とされていた箇所が今回引っかかったりする可能性は普通にあると知り、「一度通ったから安心」という考えを改めました。差分だけ気にするのではなく、アプリ全体を毎回見直す前提で申請するようにしています。
3. リリースノートを適当に書いて後悔した
急いでいたこともあり、最初は「バグ修正」とだけ書いて申請してしまいました。
✕ バグ修正
○ ダークモードで文字が見えなくなる不具合を修正しました。
ユーザーの声を元に、フィードバック機能も追加しています。公開後、ユーザー（といっても身内ですが）から「何が変わったのか分からない」と言われて初めて、リリースノートはユーザーに向けたメッセージだと気づきました。審査を通すためだけの事務的な文章ではなく、何が良くなったのかが伝わる書き方に変えてからは、更新への反応も少し具体的になりました。
4. 審査中に次の修正を触ってしまい混乱した
審査待ちの間、手持ち無沙汰でつい別の修正をローカルで進めてしまい、審査が通ってリリースする段階になって「今Xcodeにあるコードのどこまでが今回申請した内容か」が分からなくなりました。
git tag v1.0.1-submittedこのとき以来、申請した時点のコードにタグを打っておくようにしました。審査中に別の作業を進めるのは構わないのですが、「どの状態を申請したか」を後から確実に追えるようにしておかないと、リリース時に混乱するのだと学びました。
まとめ
Version（表示用）とBuild（内部管理用）は別物。アップロードのたびにBuildは必ず増やす- アップデート申請でも審査対象はアプリ全体。「差分だけ見られる」わけではない
- リリースノートは審査用の事務文書ではなく、ユーザーへのメッセージとして書く
- 審査中に別の修正を進める場合は、申請時点のコードにタグを打って区別できるようにしておく
初回の公開審査とは違う種類のつまずきが多く、「一度経験したから次は安心」とは限らないのだと実感したアップデートでした。
次は、個人開発を始めて分かった「やってよかったこと」5つをまとめます。
本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。
コメント