作っているiOSのボードゲームアプリを、App Storeに出したいと考えました。ただ、提出までに何をそろえればよいのか、どこまでできているのかが、自分では分かっていませんでした。この記事では、Claude Code に提出に必要な項目を棚卸しさせた方法と、そこで見つかった抜けを書きます。
作りたかったもの
作りたかったのは、アプリそのものではなく「提出の準備がどこまでできているか」が一目で分かる一覧です。
App Storeに出すには、アイコン、スクリーンショット、プライバシーポリシーなど、アプリの中身以外にも用意するものがあります。私はそれを断片的にしか知りませんでした。思いつくものから手を付けると、あとで大きな抜けが見つかるかもしれません。
そこで、先に全体を洗い出すことにしました。完了の条件は「提出に必要な項目ごとに『済/不足/未確認』を判定した一覧がある」ことです。アイコンを作る、スクリーンショットを撮る、実際に提出する、といった作業はこの回には含めませんでした。
AIへの頼み方
作業は Claude Code に任せました。頼んだのは、次の2つです。
- アプリのファイルとビルドの設定(アプリを組み立てるときの設定)を実際に読んで、いまの状態を確かめること。
- 提出の決まりは、Appleの公式資料で確かめること。
もう1つ、根拠の種類を項目ごとに書き分けるようにしました。分け方は次の3種です。
- 実地確認:ファイルとビルドの設定を読んで確かめた。
- 公式確認:Appleの公式資料を読んで確かめた。
- ChatGPT指摘:ChatGPT に相談したときに挙がったが、公式資料ではまだ確かめていない。
根拠を分けたのは、一覧の中で「確かなこと」と「言われただけのこと」が混ざらないようにするためです。AIの答えは、もっともらしく見えても間違っていることがあります。どの項目がどこまで確かなのかが見えれば、次に何を調べればよいかも分かります。
次の図は、1つの項目がどう判定されるかを表しています。
flowchart TD
A["提出に必要な項目"] --> B{"根拠はどれか"}
B -- "ファイルや設定を読んだ" --> C["実地確認"]
B -- "Appleの資料を読んだ" --> D["公式確認"]
B -- "ChatGPTに言われただけ" --> E["ChatGPT指摘"]
C --> F["済・不足・未確認を付ける"]
D --> F
E --> F
F --> G["誰が動けば進むかを付ける"]
Claude Code は、Macのコマンドでアプリの状態を読み取りました。たとえば、ビルドの設定を一覧で出すコマンド(xcodebuild)、アプリの設定ファイルの中身を読むコマンド(PlistBuddy)、画像の大きさを調べるコマンド(sips)です。音源ファイルの形式と長さも調べ、ライセンスや出所を書いた資料があるかどうかも探しました。
つまずいたところ
Appleの資料がそのままでは読めなかった
Appleの開発者向けの資料は、ふつうにページを取りに行くと本文が取れませんでした。そこで、同じ資料をJSON(データをやり取りするための書き方)の形で配っている場所から読みました。読んだのは次の4つです。
- iPadの全画面の設定についての技術ノート(TN3192)
- 暗号の使用を申告する設定についての説明
- スクリーンショットの仕様
- App Storeの審査ガイドライン
設定のずれは、見ただけでは気づけなかった
いちばん意外だったのは、バージョン番号のずれです。アプリの設定を書いたファイル(project.yml)では 0.1.0 になっていました。ところが、別の設定ファイル(Info.plist)に 1.0 が直接書かれていました。実際にできあがったアプリを調べると、バージョンは 1.0 になっていました。
設定ファイルだけでなく、完成したアプリそのものを調べたことで、このずれが分かりました。2つのファイルで数字が食い違っていると、どちらの番号で提出されるのかが分かりにくくなります。
iPadの画面の向きが、今後の決まりに合っていなかった
アプリはiPadでも動く設定でした。ただ、画面の向きは縦だけに対応していました。また、全画面で固定する設定(UIRequiresFullScreen)も入っていませんでした。
iPadでは、複数のアプリを並べて使ったり、アプリの窓の大きさを変えたりできます。全画面の設定は、これを断るための古い方法でした。AppleのTN3192によると、この設定は iPadOS 26 から非推奨(使わないよう勧められている状態)になりました。iOS 27 と iPadOS 27 からは、この設定を入れても窓の大きさの変更を断れません。
そのうえで資料は、すべての画面の向きに対応することを求めています。縦だけに対応しているこのアプリは、この点が合っていません。向きを固定したい画面があれば、その画面の間だけ固定したいとシステムに伝える方法も紹介されています(必ず守られるとは限らない、と書かれています)。
音源とアイコン画像の出所を示すものがなかった
アプリで使っている音源5本と、アイコンの画像について、出所や使ってよい根拠を書いた資料がリポジトリ(作ったファイルと変更の履歴をまとめて置く場所)に1つもありませんでした。ファイルそのものはあります。けれど、あとで「これはどこから来たものか」と聞かれても、答えられる記録がない状態でした。
どう判断したか
誤った心配は、はっきり「誤り」と書いた
アイコンについては、以前「PNG画像が1枚だけでは足りないのでは」という心配がありました。調べると、アイコンは 1024×1024 の大きさで、透明な部分を持たない形式でした。1枚の画像から各サイズを作る設定(Single Size)になっていて、問題はありませんでした。
心配が外れたことも、一覧に残しました。「不足」と思い込んだままだと、要らない作業をしてしまうからです。
スクリーンショットは、必須のサイズだけを用意する
Appleのスクリーンショットの仕様を確かめると、すべての画面サイズの分を撮る必要はありませんでした。一覧では、iPhoneの6.5インチ用(1284×2778)と、iPadの13インチ用(2064×2752)を必須としました。ほかのサイズは、これを縮小して使われます。
なお、Appleの仕様の書き方では、6.5インチ用は「6.9インチ用を出さない場合に必要」とされています。6.9インチ用(1260×2736)を出すなら、そちらが使われます。
プライバシーポリシーは「要る」と決めた
アプリが何も集めていなくても、プライバシーポリシーは要ります。審査ガイドラインの 5.1.1(i) に「All apps must include a link(すべてのアプリはリンクを含めること)」とあり、全アプリに必須です。App Store Connect(提出の情報を入力するAppleの管理画面)の入力欄と、アプリの中の両方にリンクを置くよう求められています。
子ども向けにするかどうかで、変わる点を表にした
このアプリは、App Storeの「Kids」カテゴリ(子ども向けの区分)に出すか、一般のカテゴリに出すかで、守ることが変わります。そこで、ガイドラインの 1.3 と 5.1.4 をもとに、公開の方針ごとの違いを表にしました。
たとえば一般のカテゴリに出す場合、アプリ名や説明文、スクリーンショットに「For Kids」のような、主な利用者が子どもだと思わせる言葉を使えません。どちらにするかはまだ決めていないので、決めるときの材料として残しました。
分からないことは「未確認」のまま残した
調べても一次資料(Appleなど、決まりを作っている側の資料)に行き着かなかったものは、推測で埋めずに「未確認」にしました。残したのは次の4つです。
- いまの画面の向きの設定で、提出のときの検査で止められるかどうか。
- Kidsカテゴリの年齢の区切りについての一次資料。
- iOS 26 のSDK(アプリを作るための開発キット)が必須になるという告知の一次資料。
- App Store Connect の画面の中身。これは Claude Code からは見られません。
できたもの
できたのは、App Storeの公開に必要な項目を20件に分け、それぞれに「済/不足/未確認」と「誰が動けば進むか」を付けた一覧です。各項目には、実地確認・公式確認・ChatGPT指摘のどれを根拠にしたかも書いてあります。
コマンドで確かめたことは、主に次のとおりです。
- 開発チームの設定(アプリの持ち主としてAppleに登録したチームを指定する設定)がまだ入っていない。
- アプリに署名する(作った人を証明する)ための証明書は有効なものが1件あるが、プロビジョニングプロファイル(アプリを端末や審査に出すための許可証)は0件。
- 暗号の使用の申告(ITSAppUsesNonExemptEncryption)、全画面の設定、アプリのカテゴリの設定が、設定ファイルに入っていない。
- iPhoneとiPadの両方で動く設定になっている。
- アイコンは 1024×1024 で、透明な部分がない。
暗号の使用の申告は、アプリがアメリカの輸出の規則で免除されない暗号を使っているかどうかを、Appleに伝えるための設定です。
この記事で取り上げた主な発見は、バージョン番号のずれ、iPadの画面の向き、音源と画像の出所の記録、プライバシーポリシーの4つです。署名の準備や暗号の申告のように、まだ入っていない設定もほかにあります。
まとめ
- 作業を始める前に、AIに「いまの状態」を棚卸しさせると、思いつきで進めるより抜けが見つかりやすいです。
- AIの答えは、根拠の種類(自分で確かめた・公式資料で確かめた・言われただけ)を分けて書かせると、どこを疑えばよいかが分かります。
- 設定ファイルだけでなく、できあがったアプリそのものも確かめると、ファイル同士のずれに気づけます。
次は、この一覧の「不足」と「未確認」の項目を、1つずつ埋めていきます。
参考にした資料
- TN3192: Migrating your iPad app from the deprecated UIRequiresFullScreen key(Apple Developer Documentation)
- ITSAppUsesNonExemptEncryption(Apple Developer Documentation)
- Screenshot specifications(App Store Connect ヘルプ)
- App Review Guidelines(Apple Developer)
この記事は、筆者の開発記録をもとにAI(Claude)が下書きし、筆者が確認して公開しています。