Rork Max の2クリック公開を初めて使ったとき、便利さと同時に少し落ち着かない気持ちもありました。これまで Xcode の Organizer でアーカイブを開き、提出前に中身を一度目で確かめていた工程が、まるごと省かれるからです。送信は速くなりましたが、その分「何を送ったのか」を自分で確認する機会も消えています。
省かれた確認の多くは、不具合ではなく取りこぼしを防ぐためのものでした。用途の説明文言が一つ欠けている、バージョンを上げ忘れている、Bundle ID が前のアプリのまま残っている。こうした小さなズレは、Xcode 時代なら提出前にふと目に入りました。2クリックではそこを通らないので、自己点検を自分の手順として持ち直す必要があります。今回は、提出前に短時間でできる自己点検を、生成物のどこを見るかとあわせて整理します。
なぜ提出後に気づくと高くつくのか
取りこぼしの怖いところは、ビルドが成功してしまう点です。コンパイルは通り、2クリックで送信も完了し、見た目には何も問題がありません。引っかかるのは数時間後の審査か、最悪は公開後のユーザー報告です。提出から発覚までの距離が長いほど、修正の往復コストが膨らみます。
私の感覚では、提出前の自己点検に数分かけるのは、審査差し戻しの待ち時間を一度でも防げれば十分に元が取れます。とくに用途文言の欠落は審査で弾かれやすく、しかも提出前に機械的に検出できる種類のミスです。直前の数分を惜しまない、という割り切りが効きます。
用途の説明文言が全部そろっているか
iOS は、カメラや位置情報など端末機能を使うとき、その理由を説明する文言（Purpose String）を要求します。Rork が生成する設定にこの文言が欠けたまま機能だけ実装されていると、実行時にクラッシュするか、審査で指摘されます。
提出前に、使っている機能と説明文言が一対一で揃っているかを点検します。Expo 系の Rork なら設定ファイルから、Swift ネイティブの Rork Max なら Info.plist から確認できます。
# Rork(Expo) の生成設定から、用途文言キーを一覧する
# app.json / app.config.* のどちらでも拾えるように両方見る
grep -REo 'NS[A-Za-z]+UsageDescription' app.json app.config.* ios/ 2>/dev/null | sort -u
# Rork Max(Swift) の場合は Info.plist を直接見る
plutil -p ios/*/Info.plist 2>/dev/null | grep -i "UsageDescription"出てきたキーの一覧と、アプリが実際に使う機能を突き合わせます。たとえば写真保存があるのに NSPhotoLibraryAddUsageDescription が無ければ、そこが穴です。私は機能を一つ足すたびに、対応する文言を同時に入れる癖をつけていますが、それでも公開直前にこの一覧を一度出して目視するようにしています。実装と設定は別ファイルなので、片方だけ進むことがどうしても起きるからです。
バージョンと Bundle ID の取り違え
二本目以降のアプリを出すときに増えるのが、バージョンの据え置きと Bundle ID の使い回しです。Xcode の Organizer なら提出画面にバージョンが大きく出るので気づけましたが、2クリックでは流れの中で見落としがちです。
確認すべきは二つです。表示バージョン（ユーザーに見える番号）と、ビルド番号（同一バージョン内で増やす内部番号）。App Store Connect は、同じビルド番号の再提出を受け付けません。
# 表示バージョンとビルド番号を一度に確認する
# Expo: app.json の version と ios.buildNumber
grep -E '"version"|"buildNumber"' app.json
# Swift ネイティブ: Info.plist の CFBundleShortVersionString と CFBundleVersion
plutil -p ios/*/Info.plist 2>/dev/null | grep -E "CFBundleShortVersionString|CFBundleVersion|CFBundleIdentifier"Bundle ID は、テンプレートや過去プロジェクトを下敷きにすると前のアプリの値が残りやすい箇所です。私自身、個人開発で似た構成のアプリを続けて作ったとき、Bundle ID が一本前のままで、App Store Connect 側の登録と食い違って提出が止まったことがあります。提出前に、ここがこのアプリ固有の値になっているかを必ず一度見ます。
自己点検を一つのコマンドにまとめる
毎回これらを手で打つと、忙しいときほど省略してしまいます。私は提出前点検を一つのスクリプトにまとめて、公開ボタンを押す前に必ず走らせるようにしています。
#!/usr/bin/env bash
# presubmit-check.sh — 公開前に最低限を機械点検する
set -euo pipefail
echo "== 用途文言 =="
grep -REo 'NS[A-Za-z]+UsageDescription' app.json app.config.* ios/ 2>/dev/null | sort -u \
|| echo "(設定が見つかりません。パスを確認してください)"
echo "== バージョン / Bundle ID =="
grep -E '"version"|"buildNumber"' app.json 2>/dev/null || true
plutil -p ios/*/Info.plist 2>/dev/null \
| grep -E "CFBundleShortVersionString|CFBundleVersion|CFBundleIdentifier" || true
echo "== 確認事項 =="
echo "[ ] 使う機能ぶんの用途文言がそろっているか"
echo "[ ] 表示バージョンを前回から上げたか"
echo "[ ] Bundle ID がこのアプリ固有か"スクリプトにする利点は、点検が「やる/やらない」の判断から外れることです。公開フローの一部に組み込んでしまえば、急いでいても抜けません。Dolice Labs で複数アプリを並行で出していても、この一本を全アプリで共有しているので、新しいアプリでも点検の質が一定に保てます。
2クリック公開が省いてくれたのは手間であって、確認の必要性そのものではありません。省かれた目視を、機械的な自己点検として自分の側に持ち直す。次に Rork Max で公開する前に、まず用途文言の一覧を一度出力してみてください。穴がないと分かるだけで、公開ボタンを押す手が軽くなるはずです。