きれいな話ばかりでは嘘になるので、いちばん泥くさい話も書いておきます。STIL. は、App Store の審査に 3 回落ちました。4 回目で、ようやく公開できました。
個人開発でアプリを出すとき、最後に立ちはだかるのが審査です。コードが動くことと、ストアに並ぶことのあいだには、思っていたより距離がありました。
1 回目 ── 権限とアカウント
最初の指摘は、権限まわりと、アカウントの扱いについてでした。「なぜこの権限が要るのか」「アカウントを消す手段はあるか」。ここは説明と実装を足して対応しました。今思えば、入り口の作法の話です。
このときの宿題が、のちに「そもそもアカウントを持たない」という決断につながっていきます（その話は別の回で書きました）。
2 回目 ── 課金まわりの不備
2 回目は、課金まわりでした。アプリ内課金が審査に正しく結びついていないこと、そして利用規約（EULA）へのリンクが足りていないこと。
Paywall（課金画面）に規約リンクを正しく置き、課金商品を紐づけ、サブスクリプションを管理する導線を足す。有料アプリとして成立するための、事務的だけれど落とせない作法が、まだ足りていませんでした。一つずつ埋めて、また提出しました。
3 回目 ── いちばん効いた指摘
3 回目が、いちばん効きました。指摘はこうです。「課金画面で価格が表示されないことがある」「アップグレードのボタンを押しても反応しないことがある」。
調べて、青ざめました。これはルールの問題ではなく、私のコードの弱さでした。課金商品の情報を取りに行く処理が、何らかの理由で失敗したとき、画面が黙って固まってしまう。うまくいくときは動く。でも、通信が不安定なときや、情報が取れないとき、ユーザーには「壊れたアプリ」に見える。審査は、その「うまくいかないとき」を、きちんと突いてきました。
直したのは、機能ではなく堅牢性です。読み込み中だとわかる表示を出す。失敗したらエラーを知らせて、もう一度試せるようにする。「うまくいかなかったとき、どう振る舞うか」を、ちゃんと作る。これがすっぽり抜けていました。
4 回目 ── 承認
その堅牢性を足したビルドで、4 回目を提出しました。今度は通りました。落ちはじめてから、ここまで一週間ほど。短いようで、一回ごとに半日へこんでいたので、体感はもっと長かったです。
落ちることが、教えてくれたこと
振り返ると、審査は「敵」ではありませんでした。むしろ、自分では気づけなかった穴を、毎回正確に指してくれる相手でした。とくに 3 回目の「うまくいかないときの振る舞い」は、自分一人だと、たぶん見落としたまま世に出していたと思います。
個人開発は、褒めてくれる人も、止めてくれる人も、基本的にいません。だからこそ、審査という外の目で「ここが甘い」と言われることには、意味がありました。3 回落ちたのは、回り道ではなく、そのぶん丈夫になったということだったのだと思います。
次回は、その「一人で全部やる」という話そのものを。なぜひとりで作っているのか、どうやって回しているのか。
STIL. のことは stil.photo、本体は App Store に置いてあります。
