Rork で作ったアプリを App Store に出すと、最初の1〜2回はかなりの確率でリジェクトを食らいます。私自身も Rork で生成したアプリを4本リリースする中で、最初の3本は1回以上リジェクトされました。落ち込みますが、Apple のリジェクトは「直し方」がほぼパターン化されているので、コツを掴めば2回目以降の申請通過率は大きく上がります。
この記事は、私が実際に経験したリジェクト理由と、その時に取った対処を Guideline 番号別に整理したものです。また、再申請前に確認すべきチェックリストも入れています。Apple の最新審査傾向（2026年4月時点）を踏まえています。
まず最初に: リジェクトメッセージの読み方
App Store Connect でリジェクトされると、メッセージに Guideline 番号（例: 2.1, 4.0, 5.1.1）が必ず書かれています。最初にすべきは、この番号を Apple のガイドラインページで確認することです。
ガイドラインページ自体は長文ですが、Guideline 番号で検索すれば該当箇所がピンポイントで見つかります。リジェクトメッセージの英語に圧倒されず、まず番号を引くのが最初の一歩です。
私が遭遇したリジェクトを多い順に並べると、Guideline 2.1（Performance）、Guideline 4.0（Design）、Guideline 5.1.1（Privacy）、Guideline 2.3（Accurate Metadata）、Guideline 4.3（Spam）でした。以下、それぞれ実例で説明します。
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）
- 原因を特定して修正
- 再申請のメッセージに「指摘いただいた現象を再現し、原因（ライブラリの初期化順序ミス）を特定して修正しました」と具体的に書く
抽象的な「修正しました」より、具体的な原因を書く方が再審査の通過率が上がります。
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 に拡大しました。同様の問題を全画面で確認・修正しました。」と具体的に書きます。
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 が生成したデフォルトの説明文が「アクセスを許可してください」のような汎用的なものだったため、すべて手動で書き直しました。これだけで通過したことが何度かあります。
Guideline 2.3.1（Accurate Metadata）— スクリーンショットと実機が違う
これは Rork のような自動生成系で起こりやすい。「スクリーンショットに写っている機能が実機にない」「スクリーンショットのデザインがアプリと一致しない」など。
実際のメッセージ:
「The screenshots show a 'Premium subscription' button, but no such functionality exists in the submitted build.」
対処法:
- スクリーンショットを実機の画面と一致するように差し替える
- 機能を追加する予定だった場合、その機能を実装してから再申請する
- 「将来追加予定」のフレーズはサブタイトルや説明文でも使わない
ここでよくあるミスは、ASO のために魅力的な機能を画像に載せてしまうこと。実装が追いついていないと容赦なくリジェクトされます。
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段落で書く。これで再審査担当者が直したポイントを素早く把握でき、通過率が上がります。
再申請前の最終チェックリスト
私が毎回確認している項目です。
実機で起動から主要操作までクラッシュしないか、複数の機種で確認した。Info.plist のすべての Privacy Usage Description が「目的を具体的に書いた」状態になっています。スクリーンショットに写っている機能が、提出するビルドで全て動作します。タップ可能要素が 44 × 44pt 以上になっています。In-App Purchase がある場合、テストアカウントで購入フローが完走します。アプリ説明文に Apple のガイドライン違反になり得る表現（「最高」「ベスト」など過剰な表現、競合他社の名前）が入っていありません。
これら6項目を満たしてから再申請すると、私の経験では95%以上が通過します。
リジェクトをポジティブに捉える
最後に、心構えの話を少しだけ。
リジェクトを受けると最初は落ち込みます。私も最初の数回は「俺のアプリが否定された」と感じていました。でも本質的には、Apple のレビュアーは「ユーザー保護」のために動いています。リジェクトは品質改善の機会であり、通過したアプリは確実にユーザーにとって良いものになります。
それと、リジェクトの理由を直すと「他のアプリでも同じミスをしなくなる」というメタな学びがあります。私は2本目以降、同じ理由でのリジェクトを受けていません。1本目のリジェクトは将来の自分への投資、と考えると気が楽になります。
迷ったときはこの記事のチェックリストを開いて、項目ごとに潰していってみてください。確実に前に進めます。