Rork で作ったアプリを App Store に出すと、最初の1〜2回はかなりの確率でリジェクトを食らいます。私自身も Rork で生成したアプリを4本リリースする中で、最初の3本は1回以上リジェクトされました。落ち込みますが、Apple のリジェクトは「直し方」がほぼパターン化されているので、コツを掴めば2回目以降の申請通過率は大きく上がります。
以下は、私が実際に経験したリジェクト理由と、その時に取った対処を Guideline 番号別に整理したものです。再申請前に確認すべきチェックリストも入れています。2026年8月時点の審査傾向を踏まえ、9月から必須になる年齢レーティングの回答についても項目を設けました。
まず最初に: リジェクトメッセージの読み方
App Store Connect でリジェクトされると、メッセージに Guideline 番号（例: 2.1, 4.0, 5.1.1）が必ず書かれています。最初にすべきは、この番号を Apple のガイドラインページで確認することです。
ガイドラインページ自体は長文ですが、Guideline 番号で検索すれば該当箇所がピンポイントで見つかります。リジェクトメッセージの英語に圧倒されず、まず番号を引くのが最初の一歩です。
私が遭遇したリジェクトを多い順に並べると、次のようになります。番号から「どこを最初に開けばいいか」がすぐ引けるよう、対応表にしました。
| Guideline | 典型的な症状 | 最初に開く場所 | 再申請までの目安 |
|---|---|---|---|
| 2.1 Performance | 起動直後にクラッシュ・白画面で固まる | 指定機種のシミュレータとクラッシュログ | 半日〜2日（原因次第） |
| 4.0 Design | タップ領域が小さい・iOS の慣習から外れる | 指摘された画面のレイアウト定義 | 数時間 |
| 5.1.1 Privacy | 権限の用途説明が汎用的すぎる | Info.plist の Usage Description 群 |
1〜2時間 |
| 2.3.1 Accurate Metadata | スクリーンショットの機能がビルドにない | App Store Connect のメディア管理 | 数時間〜（実装が要る場合は数日） |
| 4.3 Spam | 自分の他アプリと似すぎと判定される | コンセプト・アイコン・配色の設計 | 数日〜（作り直しになりやすい） |
表のいちばん右の列が、実は精神衛生上いちばん大事です。2.1 と 4.3 は「今日直して明日出す」が通用しないことがある、と分かっているだけで、リリース予定日の置き方が変わります。
なお、そもそもビルドが審査に届かず App Store Connect の「処理中」で止まっている場合は、審査以前の問題です。その切り分けはRorkで書き出したアプリがApp Store Connectで「処理中」のまま止まるにまとめています。
Guideline 2.1（Performance）— ビルドが起動しない、クラッシュする
最も多いリジェクト理由です。Apple のレビュー端末（多くは iPhone の旧モデル + 最新 OS）で、起動直後にクラッシュしたり、特定の操作で固まったりすると即リジェクト。
私が経験したケースでは、
「iPhone 12 mini で起動すると、Splash Screen の後で白画面のまま固まる」
というメッセージでした。手元の iPhone 15 では再現せず、最初は「再現できないので問題ない」とリプライしようとしましたが、それは悪手です。Apple は再現環境の詳細を書いてくれているので、その環境を再現して直すのが正解です。
対処法:
- Xcode の Simulator で同じ機種（iPhone 12 mini）と同じ iOS バージョンを選んで起動
- クラッシュログを取得（Window → Devices and Simulators → View Device Logs）
- 原因を特定して修正
- 再申請のメッセージに「指摘いただいた現象を再現し、原因（ライブラリの初期化順序ミス）を特定して修正しました」と具体的に書く
抽象的な「修正しました」より、具体的な原因を書く方が再審査の通過率が上がります。
手元に Xcode がない場合の再現手段
Rork Max のようにクラウド上の Mac でビルドする経路を使っていると、そもそも手元に Xcode がありません。この場合の再現は次の順で試しています。
まず、ブラウザに配信されるシミュレータで機種と OS を指定機種に合わせます。ここで再現すれば話は早い。再現しなければ、TestFlight で該当機種を持つ人に配布し、フィードバックとクラッシュログを回収します。それも難しければ、App Store Connect の「クラッシュ」タブに集まる分を待つことになりますが、審査中のビルドについては件数が少なく、待つ価値はあまりありません。
起動直後に固まる系は、ウォッチドッグによる強制終了（0x8badf00d）として記録されていることがあります。ログの読み方はiOS の 0x8badf00d ウォッチドッグ強制終了に Rork アプリが落ちるときの対処で扱っています。
Guideline 4.0（Design）— UI が iOS のガイドラインに合っていない
Rork で生成したアプリに多いのが、これです。「ボタンのサイズが小さすぎる」「タップ可能要素の判定がない」「ナビゲーションが iOS の慣習から外れている」など。
実際に受けたメッセージ:
「Buttons in the settings screen are too small to be tapped reliably. Apple Human Interface Guidelines recommend a minimum tappable area of 44 × 44 points.」
対処法:
- Rork のプロンプトで「全てのタップ可能要素は最低 44 × 44 ポイント以上にする」と明示
- 既存の画面は手動で確認し、小さいボタンを大きくする
- 修正前後のスクリーンショットを App Store Connect のメッセージに添付して再申請
「指摘されたボタンを 44 × 44pt に拡大しました。同様の問題を全画面で確認・修正しました。」と具体的に書きます。
指摘されるのは1画面でも、生成時のプロンプトが原因なら同じ寸法が全画面に散っています。指摘箇所だけ直して再申請すると、次は別の画面で同じ番号が返ってくる。私はこれを2往復やってから、プロンプト側を直すようになりました。
Guideline 5.1.1（Privacy）— プライバシー情報の説明不足
これも頻出。「カメラ・位置情報・通知の許可を求めるが、なぜ必要かの説明が不十分」というケース。
実際のメッセージ:
「Your app requests camera permission, but the purpose string ("カメラへのアクセスを許可してください") does not explain why the camera is needed.」
対処法:
Info.plistのNSCameraUsageDescriptionなどを「何のために」「ユーザーにとって何のメリットがあるか」を明記する形に書き換える- 例: 「プロフィール写真を設定するためにカメラを使用します」
- App Privacy セクション（App Store Connect）の入力内容も再確認
私の場合、Rork が生成したデフォルトの説明文が「アクセスを許可してください」のような汎用的なものだったため、すべて手動で書き直しました。これだけで通過したことが何度かあります。
厄介なのは、自分が書いた覚えのない権限やトラッキング宣言が、依存ライブラリ側から入り込んでいるケースです。SDK の連鎖まで遡って洗う手順はRork 生成 Expo アプリの Privacy Manifest を SDK 連鎖まで監査するに分けて書きました。
Guideline 2.3.1（Accurate Metadata）— スクリーンショットと実機が違う
これは Rork のような自動生成系で起こりやすい。「スクリーンショットに写っている機能が実機にない」「スクリーンショットのデザインがアプリと一致しない」など。
実際のメッセージ:
「The screenshots show a 'Premium subscription' button, but no such functionality exists in the submitted build.」
対処法:
- スクリーンショットを実機の画面と一致するように差し替える
- 機能を追加する予定だった場合、その機能を実装してから再申請する
- 「将来追加予定」のフレーズはサブタイトルや説明文でも使わない
ここでよくあるミスは、ASO のために魅力的な機能を画像に載せてしまうこと。実装が追いついていないと容赦なくリジェクトされます。キーワードフィールドの方で戦う設計に切り替えたほうが安全です（Rorkで作ったアプリのApp Storeキーワードフィールドを100文字で最大化する設計術）。
2026年9月から必須になる年齢レーティングの回答
メタデータ関連で、今年のうちに手を打っておきたい変更があります。App Store Connect の年齢レーティング質問票に、アプリのソーシャル機能に関する設問が追加されました。Apple の告知では、2026年9月以降、新規アプリの申請・アップデートの申請、および代替配信向けの notarization 申請で、この回答の提出が必須になるとされています。
ここでいうソーシャル機能とは、ユーザー生成コンテンツをフィードやそれに類する導線で再配布・増幅したり、相互にやり取りできる仕組みを指すと説明されています。該当すると判断されたアプリは、プロダクトページに Social Media のコンテンツディスクリプタが表示されます。
Rork で作ったアプリで見落としやすいのは、「SNS を作ったつもりはない」タイプです。私が確認した限りでは、次のような機能が判断の分かれ目になります。
- ユーザーが投稿した画像やテキストを、他のユーザーが一覧で閲覧できる
- コメント欄・レビュー欄など、ユーザー同士が反応を返せる場所がある
- 「みんなの作品」のようなギャラリーやランキングを持っている
生成 AI に「投稿ギャラリーを付けて」と一言頼んだだけの機能でも、実装としては上のどれかに当たることがあります。ここでの回答と実際の実装がずれると、Guideline 2.3 系の「実態と異なる情報」として跳ね返ってきます。
回答自体は現時点でも入力できるようになっています。9月の締切前に駆け込むより、いま自分のアプリのどの画面が該当するかを棚卸ししておくほうが、精神的にずっと楽です。要件は変わることがあるため、実際に申請する際は必ず Apple Developer の最新情報で確認してください。
Guideline 4.3（Spam / Duplicate）— 量産系アプリの判定
ASO 対策で複数の似たアプリを出すと、「Spam」として判定されることがあります。Rork の生成スピードを活かして「壁紙アプリを5本出す」のような戦略は、Apple から見ると重複と見なされやすいです。
実際のメッセージ:
「This app appears to be similar to other apps in the App Store. Apple does not allow apps that share the same concept and only differ in minor ways.」
対処法:
- アプリのコンセプトを明確に差別化する（ターゲット層、機能、ジャンル）
- UI / アイコン / カラースキームを大きく変える
- 同じデベロッパーアカウントで似たアプリを連続で出さない（少なくとも1〜2ヶ月空ける）
私はこれで1本却下されたあと、「猫の写真が使える壁紙アプリ」と「ミニマルデザインの壁紙アプリ」のように、コンセプトを明確に分けるようにしました。それ以降は通っています。
この番号だけは、直して出し直すというより、企画に戻る類のものです。生成が速いぶん「とりあえず出す」の誘惑が強いのですが、ここで一度立ち止まれたことは、結果的に良かったと思っています。
再申請メッセージの書き方
リジェクトを修正して再申請する時、App Store Connect の「Notes」フィールドに何を書くかが重要です。私が使っているテンプレートは次の通り。
We have reviewed your feedback and made the following changes:
1. [Guideline 番号]: [何を直したか1行で]
2. [Guideline 番号]: [何を直したか1行で]
For [指摘された項目1], we [具体的な対処] (see attached screenshot).
For [指摘された項目2], we [具体的な対処].
We have also tested on [指摘された機種・OS] and confirmed the issue is resolved.
Thank you for your review.
具体的な箇条書きと、テスト確認した旨を1段落で書く。これで再審査担当者が直したポイントを素早く把握でき、通過率が上がります。
逆に書かないほうがよいものもあります。事情の説明、スケジュールの都合、前回の審査への異議。読む側が確認したいのは「指摘した箇所がどうなったか」だけです。文章が長いほど確認に時間がかかり、追加の質問が返ってくる確率が上がります。
再申請前の最終チェックリスト
私が毎回確認している6項目です。上から順に潰していきます。
- 実機で起動から主要操作までクラッシュしないことを、複数の機種で確認しました
Info.plistのすべての Privacy Usage Description が、目的を具体的に書いた状態になっています- スクリーンショットに写っている機能が、提出するビルドですべて動作します
- タップ可能要素が 44 × 44pt 以上になっています
- In-App Purchase がある場合、テストアカウントで購入フローが完走します
- アプリ説明文に、過剰な表現や競合他社の名前など、ガイドライン違反になり得る表現が入っていません
これに加えて、9月以降は年齢レーティングの回答が実装と一致しているかを7項目目として足すことになります。
この6項目を満たしてから再申請すると、私の経験ではほとんど跳ね返ってきません。通過したあとの配信をどう刻むかはRork アプリの段階的リリース戦略にまとめています。
リジェクトをポジティブに捉える
最後に、心構えの話を少しだけ。
リジェクトを受けると最初は落ち込みます。私も最初の数回は、自分の作ったものを否定されたように感じていました。でも本質的には、Apple のレビュアーは「ユーザー保護」のために動いています。リジェクトは品質改善の機会であり、通過したアプリは確実にユーザーにとって良いものになります。
それと、リジェクトの理由を直すと「他のアプリでも同じミスをしなくなる」というメタな学びがあります。私は2本目以降、同じ理由でのリジェクトを受けていません。1本目のリジェクトは将来の自分への投資、と考えると気が楽になります。
迷ったときはこの記事の対応表とチェックリストを開いて、項目ごとに潰していってみてください。確実に前に進めます。