匿名化済みアーカイブ
App Store審査がチームに実際にかかるコスト
公開された開発者投稿から要約した117件の拒否事例。氏名、アプリ名、出典へのリンクはなし。背景、既知の結果、そして各事例から得られる教訓のみを掲載しています。
バッチ1 · 44件の事例 · 2026-10-19更新
- ストーリー
- 117
- ガイドライン
- 15
- バッチ
- 1
全117件のストーリーを表示中。
-
4.3(a) スパム iOSと ガイドライン 4.3ポートフォリオ全体が一斉にフラグ付け
何が起きたのか
同じスタータープロジェクトから複数のアプリを開発していた開発者は、そのすべてで同一の4.3通知を受け取りました。アプリ同士はバイナリ、メタデータ、コンセプトが似通っており、違いはわずかでした。開発者はアプリを1つずつ対応していくことにしました。
解決策
投稿時点ではまだ進行中です。
教訓
4.3(a) は自社アプリ同士の重複も対象です。1つのテンプレートから複数のアプリを作った場合、アイコンと名前を変えるだけでは足りず、それぞれに本当に異なるコア機能が必要です。
-
4.3(a) スパム iOSと ガイドライン 4.31週間で2度、同じ通知が届く
何が起きたのか
単一目的の小さな写真補助アプリが、深夜に 4.3(a) でリジェクトされました。以前のビルドでまったく同じリジェクト文面を受け取ってから、1週間後のことでした。
解決策
記載なし
教訓
外見だけの修正で再提出しても、4.3の判断は変わりません。コンセプトを変更するか、レビューノートでアプリの差別化ポイントを明確に説明してください。
-
4.3 デザイン / スパム iOSと ガイドライン 4.3競争が激しいカテゴリでの開発
何が起きたのか
毎日ビルドチャレンジを記録していた個人開発者が、4日目に4.3 Design / Spamでリジェクトされ、飽和カテゴリを選んだのは間違いだったのではと疑い始めました。
解決策
記載なし
教訓
Appleが飽和カテゴリーとしている分野は、より厳しく審査されます。レビュー後ではなく、ビルド前にアプリの差別化ポイントを検証しましょう。
-
2.1 必要な情報 iOSと ガイドライン 2.1新規アカウント向けの7つの質問
何が起きたのか
あるチームの初回提出は、2.1 Information Neededで返却されました。内容は7つの質問、画面録画とデモアカウントの提供依頼でした。正直に回答したことで、見落としていた4つの点が明らかになりました。
解決策
彼らは問題を修正して返信しました。
教訓
新しいデベロッパーアカウントでは、これを想定しておくべきです。提出前にデモアカウント、録画、明確なレビュー用メモを用意しましょう。
-
2.1 アプリの完成度 iOSと ガイドライン 2.1レビュアーがアプリの使い方を理解できなかった
何が起きたのか
初めてアプリをリリースした開発者が、公開前に2度リジェクトされました。最初のリジェクトは2.1によるもので、レビュアーがアプリの想定される使い方を把握できなかったことが原因でした。
解決策
実機で録画したデモ動画とステップバイステップのレビュー用メモを追加したことで承認されました。
教訓
レビュアーには数分しかなく、背景情報もありません。どこをタップして、何が表示されるべきかを正確に伝えましょう。
-
メタデータとアプリ内課金の設定 iOSと メタデータとIAP既知のチェック項目で2回リジェクト
何が起きたのか
ある個人開発者が、すでに把握していた理由で2度もリジェクトされました。最初は、アプリ内課金が紐付いていない状態でビルドを提出し、説明文に利用規約へのリンクがありませんでした。数週間後には、スクリーンショットでアプリが無料と記載されていたことが理由でした。
解決策
その都度、修正して再提出しました。
教訓
メタデータ、サブスクリプション、法的リンクの提出前チェックリストを用意しましょう。メタデータによるリジェクトのほとんどは防げます。
-
審査待ちの時間 iOSと 終わりのない審査9日間の待機、その後8日間の審査
何が起きたのか
ある開発者は、ステータスが「Waiting for Review」から「In Review」に変わるまで9日間待ち、その後も8日間、何の更新もないまま審査中でした。
解決策
投稿時点ではなし
教訓
審査時間は保証されません。リリース日やプレス、クリエイターキャンペーンを承認予定日に紐付けないでください。
-
審査待ちの時間 iOSと 終わりのない審査リジェクト・修正・待機ループの20日間
何が起きたのか
20日以上にわたり、ある開発者はリジェクト、修正、審査待ち、リジェクト、修正を経て、投稿時点でもまだ待機中でした。
解決策
保留中
教訓
審査の往復には、毎回数日かかる可能性があります。リジェクト通知の修正は、すべて1つのビルドにまとめましょう。
-
アカウント終了 iOSと アカウント終了最初のレビュー前に閉鎖
何が起きたのか
経験10年の開発者が、何をしたのかも明かされない不正の疑いでデベロッパーアカウントを停止されました。言語学習ゲームはまだ最初のレビュー待ちの状態でした。既存のアプリはすべて消え、ユーザーからは理由を問う声が上がりました。
解決策
報告なし
教訓
アカウントが停止されると、すべてのアプリが一度に削除されます。ストアが消えてもユーザーに連絡できるよう、独自のチャネル（メール、ウェブサイトなど）を確保しておきましょう。
-
アカウント停止の警告 iOSと アカウント終了リジェクトされたバージョンが多すぎる
何が起きたのか
多作の個人開発者が、10日後にアカウントを終了するとの通知を受け取りました。Appleは、リジェクトされたバージョンの多さが理由の一つだと示しました。世間の注目と異議申し立ての後、アカウントは終了されませんでした。
解決策
異議申し立てによりアカウントは存続。
教訓
リジェクトは積み重なります。一言だけ変えた同日再提出や、自作アプリのほぼ同一のクローンは避けましょう。
-
ログイン必須（ガイドライン番号の記載なし） iOSと ログイン要件サインアップ必須：その大手アプリではない
何が起きたのか
ある開発者のソーシャルアプリが、ホームフィードにたどり着く前にアカウント作成を求めたためリジェクトされました。開発者が「全ユーザーにハンドルがないとアプリがそもそも動かない」と説明し、同じ仕組みの大手写真共有SNSを例に挙げたところ、審査官は事実上「あなたのアプリはそのSNSではない」と回答しました。
解決策
記載なし
教訓
大手アプリが許容されているからといって、それが引用できる前例になるわけではありません。サインアップを必須にするなら、アカウントなしではコア機能が動かない理由をレビューノートに書き、審査官やゲストが先に一部のコンテンツを見られるようにすることを検討してください。
-
4.3 スパム iOSと ガイドライン 4.3レビューゼロの状態から、ほぼ全却下へ
何が起きたのか
ある開発者は、自分のアプリが数日間まったくレビューされない状態でした。待っている間の約1週間で、さらに多くの申請を作成。ようやく審査が動き出したとき、そのほとんどがガイドライン4.3のスパムとして却下されました。
解決策
記載なし
教訓
審査キューが停滞していても、それは追加申請の合図ではありません。審査が進まない間に申請を溜め込むと、審査員がまとめて確認したときにアカウントがスパムのパターンに見えてしまいます。
-
4.3 スパム iOSと ガイドライン 4.3無関係なアプリがまとめてリジェクト
何が起きたのか
数ヶ月かけて開発した互いに無関係な複数のアプリが、同時にすべてスパムとしてリジェクトされた開発者がいました。彼はそれが普通なのかを公に問いかけました。
解決策
記載なし
教訓
4.3はアプリごとではなく、アカウント単位で適用されることがあります。複数のアプリが同時にリジェクトされた場合は、それぞれ個別に回答し、レビューノートで各アプリの独自性を明確に説明してください。
-
審査待ちの時間 iOSと 終わりのない審査一度のリジェクト、そして2か月の沈黙
何が起きたのか
一度リジェクトされた後、開発者のアプリは約2か月間審査中のままで、各レビューサイクルには約1か月かかっていました。長いサイクルが新規アプリを締め出す手段になっているのではと疑っていました。
解決策
投稿時もまだ審査中でした。
教訓
リジェクト後の次のサイクルは、初回よりはるかに遅くなることがあります。再提出は漏れなく、ドキュメントも十分に揃えて、2回目の往復でまた1か月を無駄にしないようにしましょう。
-
不適切なコンテンツ iOSと 不適切なコンテンツ修正せず再提出してリジェクト
何が起きたのか
AI写真編集アプリが、Appleが指摘した不適切なコンテンツの問題を修正せず何度も再提出したため、リジェクトされました。
解決策
リジェクトされました。
教訓
審査官が変わることを期待して同じビルドを再提出すると、マイナスに評価されることがあります。再提出する前に、指摘された問題を修正するか、Resolution Centerで確認を求めてください。生成AI機能には、Appleが不適切と判断するコンテンツのフィルターを追加してください。
-
4.3 スパム iOSと ガイドライン 4.3審査開始と同時にリジェクト
何が起きたのか
ある開発者は数週間かけてアプリを構築しましたが、審査開始と同時に4.3のスパムとしてリジェクトされました。その開発者は、レビュアーがアプリではなくニッチ分野そのものを判断したと考えています。
解決策
記載なし
教訓
競合の多いニッチ分野では、詳しく確認される前に4.3で即リジェクトされることがあります。審査メモの冒頭に独自性を書き、レビュアーがそこをすぐ確認できるようにしましょう。
-
4.2.6 テンプレート iOSと ガイドライン 4.2.6使用していないテンプレートでフラグが立った
何が起きたのか
あるチームがガイドライン4.2.6でリジェクトされました。これは商用テンプレートやアプリ生成サービスから作られたアプリが対象ですが、そのチームはテンプレートも生成サービスも一切使っていませんでした。
解決策
記載なし
教訓
4.2.6は誤検知の可能性があります。Resolution Centerで、アプリはカスタムビルドであること、誰がビルドしたかを明記し、ソースや開発履歴を提示する旨を伝えてください。
-
3.1.2 サブスクリプション iOSと ガイドライン 3.1.2月額料金が実際の請求額より大きく表示されていた
何が起きたのか
ある開発者のペイウォールが、長期サブスクリプションの月額換算価格を実際の請求額より目立つ形で表示していたため、リジェクトされました。同じペイウォールは以前のレビューでは指摘なしで通過していました。開発者はルールには同意しつつ、今になって指摘されたことに不満を感じ、請求額を最も強調するデザインにペイウォールを作り直しました。
解決策
新しいデザインで再提出。
教訓
以前通過したペイウォールでも、後からリジェクトされることがあります。必ず請求額と期間を最も目立つように表示し、月額換算の金額は小さく補足的に表示してください。
-
登録（App Reviewのガイドラインではありません） Apple Developer Program 登録とアカウント2ヶ月、そして理由なき拒否
何が起きたのか
ある開発者は登録に2ヶ月以上を費やし、何度もサポートに電話やメールを送り、本人確認、デバイス情報、さらには動画の証拠まで提出しました。しかしAppleは具体的な理由を示さずに登録を却下しました。
解決策
投稿時点ではなし
教訓
登録にはアプリの開発よりもはるかに時間がかかることがあります。リリース計画が登録に依存する前に早めに手続きを始め、サポートとのやり取りはすべて記録に残しておきましょう。
-
5.1.2 データの使用と共有 iOSと ガイドライン 5.1.2スタートアップを脅かした App Tracking Transparency によるリジェクト
何が起きたのか
数か月にわたり素早くリリースを重ね、ユーザーから強い反響を得た後、あるスタートアップのアプリが晩秋に App Tracking Transparency（アプリやウェブサイトをまたいだトラッキングの前にユーザーの許可を求める iOS のプライバシー規則）を理由にリジェクトされました。創業者は後に、会社全体を危険にさらしたリジェクトだったと振り返っています。
解決策
投稿には記載なし
教訓
提出前に、アプリ内のすべての SDK についてトラッキングの有無を監査してください。ユーザーデータを他社のデータと紐付けるものがあれば、そのトラッキングがサードパーティ製ライブラリ由来でも、トラッキング許可の prompt と対応するプライバシーラベルが必要です。
-
ログイン（ガイドライン番号の記載なし） iOSと ログインレビュアーがAppleまたはGoogleでサインインできず
何が起きたのか
ボットによる新規登録を防ぐため、開発者はメールアドレスとパスワードによるログインを廃止し、Sign in with AppleとGoogleサインインだけにしました。開発者自身のiPhoneやiPadでは問題なく動作し、別の理由でアプリを却下した前回のレビュアーでも同様でした。しかし次のレビュアーは、ログインできずにアプリを却下しました。
解決策
記載なし
教訓
アプリがソーシャルログインのみの場合でも、レビュアーがログインできずに詰まる可能性はあります。レビューノートにデモアカウントやレビュー専用ログインなど、動作するログイン手段を記載し、提出ごとに新しいデバイスとアカウントでサインインをテストしましょう。
-
シミュレーションギャンブル（ガイドライン番号の記載なし） iOSと 模擬ギャンブル個人アカウントでのゲーム内ステーキング機能
何が起きたのか
あるゲームが「模擬ギャンブル」を含むとしてリジェクトされました。プレイヤー同士でゲーム内アイテムを賭け合える仕組みで、古典的なオンラインRPGでは一般的なメカニクスです。開発者が法人ではなく個人アカウントで公開していたため、一旦この機能を削除することにしました。
解決策
機能を削除して再申請。
教訓
ギャンブル的なメカニクスは、リアルマネーが絡まなくても厳しく審査されます。Appleが何を許可するかは、アカウントの種類や提出書類によっても変わります。ステーキング、ルート、賭け機能を作る前にギャンブルに関するルールを確認し、それに合わせてデベロッパーアカウントの種類を計画してください。
-
偽の文書（ガイドライン番号の記載なし） iOSと 偽造書類ユーザーの行為を理由に責められたPDFエディタ
何が起きたのか
Appleが、ユーザーが偽のIDや偽造書類を作成できると指摘したことを理由に、あるPDFエディタアプリがリジェクトされました。開発者は、同じ理屈なら銀行やメッセージングアプリも悪意あるユーザーによる利用を理由にリジェクトされ得ると反論しました。
解決策
記載なし
教訓
汎用ツールは、最悪の使われ方で判断されることがあります。公式のIDや証明書に見えるテンプレートやマーケティング素材は避け、レビューノートでアプリの目的と対応していない機能を明確に説明してください。
-
AIによるデータ共有（ガイドライン番号の記載なし） iOSと AIデータの共有サードパーティAIへのデータ共有に同意画面なし
何が起きたのか
あるチームが、ユーザーデータをサードパーティのAIプロバイダーと共有していたことで、初めての審査リジェクトを受けました。Appleは、ユーザーからの明示的な許可に加え、どのデータをどのAIプロバイダーに送信するかを明確に開示することを求めています。チームの悩みは、コンバージョン率を下げずに審査を通過できる同意画面をどう構築するかでした。
解決策
進行中
教訓
アプリがユーザーコンテンツを外部のAIサービスに送信する場合、最初のリクエストを行う前に同意を求め、プロバイダー名と対象となるデータを明示してください。リジェクトされてからではなく、申請前にその画面を実装しておきましょう。
-
Family Controlsエンタイトルメント（ガイドライン番号の記載なし） iOSと メタデータとIAPチェックボックス1つ未チェックで5回リジェクト
何が起きたのか
スクリーンタイム系アプリを手がける開発者が5回リジェクトされました。レビュー指摘が曖昧だったため、当初はデザイン自体に問題があると思い込んでいました。しかし真の原因は、開発者設定でFamily Controlsのチェックが1つ外れていたことでした。チェックを入れると、アプリは承認されました。
解決策
Family Controlsの設定を有効にして再提出したところ、承認されました。
教訓
リジェクト理由が曖昧なままなら、プロダクトを再設計する前にentitlementsと証明書を確認しましょう。Screen TimeやFamily Controlsのアプリは、Xcodeだけでなくデベロッパーポータルでも対応するcapabilityを有効にする必要があります。
-
ガイドライン 5.1.1(v) iOSと ガイドライン 5.1.1 ログイン要件デバイス上で動作する有料機能にはアカウントが必要
何が起きたのか
Webアプリ出身のデベロッパーが、ガイドライン5.1.1(v)でリジェクトされました。Webでは購入を常にアカウントに紐付けていましたが、iOSではAppleが購入を管理するため、購入者はサインアップなしで支払えます。有料プランでは、端末上でのみ動作するオンデバイスフィルターをアンロックできましたが、そのプランのアンロックと購入の復元（Restore purchases）のどちらも、先にアカウント作成を強制していました。
解決策
アカウントなしの購入でも、任意のサインアップ後に購入者に紐付くよう再構築中。投稿時点では進行中。
教訓
デバイス上で動作し、サーバー側のIDを必要としない有料機能なら、アカウントなしで購入・復元できるようにしましょう。サインアップは、クラウドバックアップなど本当に必要な機能だけに残しましょう。
-
ガイドライン 1.4.2 身体的危害 iOSと ガイドライン 1.4.2規制強化により、公開中の投与量計算アプリが削除される事態に
何が起きたのか
ある開発者が朝起きると、2つのアプリがガイドライン 1.4.2 でフラグを立てられていました。どちらも審査中の項目は何もありませんでした。両方ともすでに公開済みで、一つはペプチドの投与量を計算する単体アプリ、もう一つは同じ計算機能を組み込んだトラッカーアプリで、この2つが開発者にとって初めての本格的な収益成功となっていました。同じ分野の他の開発者も、同時期に同じ通知を受け取ったと報告しています。通知には、ペプチドの投与量や溶解（reconstitution）を含む薬剤の投与量を計算するアプリは、製薬会社、または病院、保険会社、薬局、大学などの公認機関が公開しなければならない、と書かれていました。
解決策
特になし。開発者は安全上の懸念を理解し、それでこれらのアプリは終わりだと受け止めました。
教訓
承認は永続的なものではありません。Appleはルールを強化した際、公開中のアプリを再評価することがあります。投与量を計算したり、誰かに危害を及ぼす可能性のある健康ガイダンスを提供したりするアプリなら、開発前にガイドライン 1.4 を確認し、適格な機関を通じて公開するか、計算機能を外す計画を立ててください。
-
ガイドライン 4.3「スパム」および 4.2.6「アプリ生成サービス」 iOSと ガイドライン 4.3 ガイドライン 4.2.6またしても「スパム」扱いされたオフライン・チケットアプリ
何が起きたのか
ある開発者が、スプレッドシートをチケット管理・チェックインシステムに変える小さなアプリを作りました。完全オフラインで動作し、アカウントもサブスクも不要です。このアプリは夏に開催された数百人規模のローカルイベントで、すでに入場管理に使われていました。しかしAppleは4.3と4.2.6を合わせた通知で再びリジェクトし、ストアにある既存アプリとの重複、混雑したカテゴリへの便乗的な亜種、テンプレートやアプリ生成サービス製である可能性を指摘しました。開発者は、同じことをする他のアプリは知らないと述べ、Android版は約1週間前から公開されていたとしています。
解決策
投稿時点でも依然としてリジェクトされたままです。開発者は、そもそもApp Storeで稼ぐつもりはないと話しています。
教訓
4.3の審査員が見るのは、あなたのリスティングとアプリの数分間の動作だけであり、実際のユーザーではありません。本当に他と違うアプリなら、どこがどう違うのかをレビューノートと最初のスクリーンショットで具体的に示し、実世界での利用シーンに触れ、テンプレートやアプリ生成サービスを使っていないことをはっきり伝えてください。
-
ガイドライン 5.6.4 App Quality Apple Developer Program ガイドライン 5.6.4返金率の上昇により支払いが凍結
何が起きたのか
急成長中のサブスクリプションアプリを運営する開発者のもとに、Appleから警告が届きました。ガイドライン5.6.4 App Qualityに基づき、開発者アカウントがDeveloper Code of Conduct（開発者行動規範）に違反しているという内容です。通知は過剰な返金リクエストと顧客からの苦情を指摘し、アカウント停止の可能性に警告したうえで、収益の支払い停止とアプリ移管の無効化を伝えていました。返金率は過去2ヶ月でほぼ倍増。開発者がデータを調べると、返金リクエストの大半は「意図しない購入」とラベル付けされており、主因は3日間の無料トライアルを解約し忘れて年間プランに移行してしまうケースだと考えられました。警告が届いた時点で、アプリの大規模なリデザインはすでにテスト中でした。
解決策
本記事の投稿時点でも未解決です。開発者はトライアル期間中のリマインダーを増やし、次回の課金をより分かりやすく表示しました。アプリ内でサブスクを管理・解約できる機能を追加し、追加テストを経てリデザインを完了。解決を待つ間、有料のクリエイターマーケティングはすべて停止しています。
教訓
Appleはバイナリだけでなく、返金率や苦情も注視しています。無料トライアルがいつの間にか年額課金に切り替わる仕組みは、規模が大きくなると意図しない購入トラブルに発展しかねません。トライアル終了前の通知、価格の明示、簡単な解約手段を用意しましょう。返金率の上昇は、Appleに指摘されるずっと前からアカウントのリスクとして捉えるべきです。
-
メタデータとアプリ内課金の設定 iOSと メタデータとIAPコンソールから削除できない画像のせいで、3回もリジェクトされた話
何が起きたのか
ある開発者がApp Store Connectのサブスクリプションにプロモーション画像を追加した際、誤って同じ画像を2回登録してしまいました。その後、その画像は削除も差し替えもできなくなり、試行するたびに「後でもう一度お試しください」という汎用的なエラーが発生しました。アプリはそのサブスクリプション設定のせいで3回リジェクトされました。開発者は毎回、削除を試みた際の画面録画とエラー内容を添えて返信しましたが、審査員には無視されているように感じられました。開発者は、App Store Connect自体のバグが根本的な原因だと考えています。
解決策
投稿時もまだ解決しておらず、Appleからの修正も入っていません。
教訓
App Store Connect 自体が修正をブロックしている場合、リジェクトスレッドへの返信は解決できる人に届かないかもしれません。サブスクリプションの画像は慎重に、一度だけアップロードしてください。コンソールが壊れたら、App Review に返信しつつ、バグについては Apple の開発者サポートに別途連絡してください。
-
ガイドライン 4.3 スパム iOSと ガイドライン 4.3ジム1軒の運営用に作ったアプリが3度リジェクト
何が起きたのか
ある開発者が自分のジムを運営するために iOS アプリを作り、約176コミット分の作業を重ねました。Apple は9月29日にリジェクトし、10月7日に再びリジェクト、10月13日にはガイドライン 4.3 スパムでリジェクトしました。同日、App Review から届いた9つの質問すべてに回答しました。6日後の10月19日になっても、何の返信もありませんでした。App Store Connect のアプリ一覧では、同じアカウントの他の複数のアプリも、iOS と macOS の両方で同時にリジェクト状態になっていました。
解決策
投稿時点では未解決で、回答を送信後も App Review からの返信はありません。
教訓
4.3が測るのは、開発の労力やコミット数ではありません。特定の企業向けに作られたアプリなら、Unlistedアプリにすると検索結果に出さず、直接リンクを知っている人は誰でもアクセスできます。Custom App配布なら、指定した組織だけに提供を限定できます。必要なアクセス制御に合う方法を選んでください。一般公開する場合は、既存アプリとの違いを最初の数画面、スクリーンショット、審査メモで明確に示してください。
-
ガイドライン5.6「Developer Code of Conduct」および2.5.19「隠し機能」 iOSと ガイドライン5.6「Developer Code of Conduct」 ガイドライン2.5.19「隠し機能」テスト用スイッチが残っていたため、不正行為としてリジェクト
何が起きたのか
2026年9月、ある開発者のiOSアプリが審査でガイドライン5.6「Developer Code of Conduct」に抵触し、リジェクトされました。Appleは、審査中に意図的に隠されたと思われる機能など、不正行為に関連する一連の挙動を確認したと述べています。開発者が調査したところ、原因はリリースビルドに残っていた3つのテスト用スイッチでした。ストア用スクリーンショット撮影モード、エンタイトルメントチェックの遅さをシミュレートするスイッチ、モック購入を有効にするスイッチです。いずれもApp Store版の一般ユーザーには到達できないものでした。Appleは10月16日のApp Review Guidelines更新で、「隠された、休眠状態の、または文書化されていない機能」を独立したガイドライン2.5.19とし、違反すると開発者アカウント全体がリスクにさらされる可能性があるとしています。
解決策
現在、その開発者はアップロード前に、すべてのリリースアーカイブ内の文字列を検査しています。その特定のビルドが最終的に承認されたかどうかについては言及されていません。
教訓
テスト専用の code は、実行時チェックに頼らず、DEBUGフラグなどを使ってコンパイル時にリリースビルドから除外してください。アーカイブされたバイナリに実際に何が含まれるかを確認し、残っているスイッチはApp Review notesに列挙しましょう。
-
2.1 必要な情報 iOSと ガイドライン 2.1Appleがアプリの対象ユーザーを把握するまで、審査が一時停止
何が起きたのか
ある開発者がiPadアプリのバージョン1.0を提出したところ、ガイドライン2.1「情報が必要」により審査が停止しました。クラッシュレポートも、機能の不具合も、バイナリの修正要求もありませんでした。Appleが審査を続行する前に求めたのは、1つの質問に対する詳細な回答だけでした。それは「このアプリを誰が使うのか」です。
解決策
Appleは審査を続行する前に、ターゲットユーザーに関する説明を求めました。
教訓
オーディエンスとユースケースは、後から埋めるマーケティングコピーではなく、審査の入力情報として扱いましょう。最初のバージョンを提出する前に、ターゲットユーザーについて明確に回答しておきましょう。
-
4.3 デザイン / スパム iOSと ガイドライン 4.3飽和したサウンドアプリカテゴリーでは差別化が不十分
何が起きたのか
あるエンターテインメント系サウンドアプリが、ガイドライン4.3(b)に基づきリジェクトされました。開発チームは追加機能で差別化できていると考えていましたが、Apple側は「ストアには類似アプリがすでに十分あり、飽和したカテゴリーにおける重複コンテンツである」と判断しました。
解決策
飽和したカテゴリーでの差別化不足により、4.3(b)でリジェクト。
教訓
Appleが「飽和している」と判断するカテゴリーでは、レビューの最初の1分で新規性を明確に示す必要があります。レビュアーが何度も目にしているようなギミックではなく、そのアプリ独自の強みを前面に出しましょう。
-
メタデータとストア掲載情報のコピー iOSと メタデータとIAP 終わりのない審査ローンチ週を台無しにしたメタデータのループ
何が起きたのか
コンシューマー向け生産性アプリのチームは、クリーンなビルドをリリースした後、9日以上もメタデータの指摘対応に追われました。再提出のたびに前回の指摘には対応しましたが、次の返信では別のフレーズやスクリーンショット、説明文が問題視されるという繰り返しでした。ローンチ、プレス、有料集客の計画がレビュー用コピー待ちの間、code は一切変更されませんでした。
解決策
バイナリを変更せず、スクリーンショット、サブタイトル、レビューノートを書き直して承認されました。
教訓
リリース日を設定する前に、ストア掲載文、スクリーンショット、レビューノートを一度に確定しましょう。バイナリを変更していなくても、メタデータの却下は積み重なる可能性があります。
-
輸出コンプライアンス (App Store Connect) iOSと メタデータとIAP承認されたのに、追加のコンプライアンス質問でブロック
何が起きたのか
B2Bダッシュボードのコンパニオンビルドが承認に到達したものの、チームが輸出に関する質問は回答済みだと考えていた矢先にコンプライアンスのプロンプトが再び表示され、リリースはブロックされたままでした。リリース担当者はロールアウトを停止して法務の文言を集め、App Store Connectの回答を更新。アプリが利用可能になる前に告知が顧客に届く中、もう一度レビューを待つことになりました。
解決策
輸出コンプライアンスに再度回答し、次のレビューを待ってリリースされました。
教訓
輸出コンプライアンスは一度きりのチェックボックスではなく、リリースのゲートとして扱いましょう。リリース日を告知する前に、App Store Connectがリリース可能な状態になっていることを確認してください。
-
Google Playの権限とポリシーレビュー Google Play メタデータとIAP 終わりのない審査権限ポリシーによる時間の浪費
何が起きたのか
ある現場向けAndroidアプリで、1つの画面で使っていた限定的な権限が原因で、大がかりなポリシーレビューが発生しました。チームは機能を文書化し、レビュアー向けの指示を追加し、デモの流れを録画しましたが、13日後、顧客のブロックを解除するためにメインリリースからその権限を削除せざるを得ませんでした。
解決策
権限を削除し、新しいデモを録画し、ストアの宣言を書き換えた後、承認されました。
教訓
センシティブな権限は、まずリリースできる最小限の範囲に絞ってください。権限が1つあるだけで、Google Playの本格的なポリシーレビューに発展することがあります。
-
Google Playのレビューキューのタイミング Google Play 終わりのない審査ポリシー審査の順番待ちで足止めされたホットフィックス
何が起きたのか
あるECチームは、チェックアウトのバグに対する迅速なモバイル修正を必要としていました。しかし、ストアリリースは最悪のタイミングで6日間も審査に止まっていました。ステータスが保留のまま、サポートチケットは増え続けました。チームはまずサーバーサイドで緩和し、その後、緊急対応がすでに週末を丸ごと潰した後にバイナリの承認が届くのを眺めることになりました。
解決策
ネイティブストア側の修正が届いたときには、チームはすでに別の方法でインシデントを緩和していました。
教訓
ストア審査はインシデント対応のチャネルではありません。バイナリが審査待ちの間、緊急のプロダクションバグに備えてストア以外の緩和策を用意しておきましょう。
-
ガイドライン 3.1.1 App内課金および 3.1.3(f) 無料のスタンドアロンアプリ iOSと ガイドライン 3.1.1 ガイドライン 3.1.3トライアル終了でリジェクトされたコンパニオンアプリ
何が起きたのか
ある開発者が、有料のWebベースのメールサービス向けに、無料のiOSコンパニオンアプリをリリースしました。アプリ内で何も販売していませんでした。開発者はApp Reviewに、無料のスタンドアロン・コンパニオンアプリに関する3.1.3(f)の例外規定を提示しましたが、アプリは4回リジェクトされました。異議申し立てを行いましたが、App Review Boardはリジェクトを維持しました。その理由は、サービスが14日間の無料トライアルを提供しているため、iOSユーザーにとってアプリは14日を過ぎると有用性がなくなり、真のスタンドアロン体験とは言えないというものでした。Appleは2つの解決策を提示しました。アプリ単体で成立する十分な無料コンテンツと機能を提供するか、あるいはApp Storeの顧客がIn-App Purchaseでサービスを購入できるようにするかです。開発者は、有名なメールアプリも同じように14日間の制限を設けているようだと指摘しました。
解決策
投稿時点でも未解決です。異議申し立ては退けられ、開発者は最小限の無料枠とIn-App Purchase追加のどちらにするかを検討していました。
教訓
3.1.3(f)のコンパニオン例外は狭く解釈されます。Webサービスに期間限定トライアルがある場合、Appleはトライアル終了後のアプリを実質的なペイウォールとみなす可能性があります。申請前に、トライアル終了後もアプリ内で無料で何ができるかを決めておくか、In-App Purchaseを計画してください。他のアプリも同じことをしていると指摘しても、異議申し立てが通ることはほとんどありません。
-
ガイドライン3.1.1 In-App Purchase iOSと ガイドライン 3.1.1API キーの持ち込みが App Store 外での支払いとみなされるケース
何が起きたのか
iPhone 用の AI アシスタントを開発していた個人開発者が、大規模なクラウドモデルを実行できるように、サードパーティのモデルアグリゲーターから取得した API キーをユーザーが貼り付けられる機能を実装しました。しかし、4回目の審査で App Review により、ガイドライン 3.1.1 に基づいてリジェクトされました。理由は、「キーの持ち込み」オプションが App Store 外で機能の料金を支払う手段であると判断されたためです。開発者の理解では、他所で購入したキーでアプリ内の有料機能を解放できるのは、その販売元が自社の iOS アプリで In-App Purchase を提供している場合に限られ、このプロバイダーには iOS アプリがありませんでした。開発者は異議申し立てをしませんでした。
解決策
開発者は「キーの持ち込み」機能を完全に削除し、モデルを完全にデバイス上で実行するように次のバージョンを作り直し、後日クラウドモデルを In-App Purchase で販売するアプリ内クレジットとして復活させる計画を立てました。執筆時点では、再提出の結果は不明でした。
教訓
アプリ内の有料機能が、他所で取得した認証情報によって解放される仕組みの場合、ビルド前にその販売元が自社の iOS アプリで In-App Purchase を提供しているか確認してください。提供していない場合は、自前の In-App Purchase 導線を用意するか、それがなくても動くモードを計画しましょう。
-
ガイドライン 1.2 iOSと ガイドライン 1.2勝者を決めたことでリジェクトされたコーディネート比較
何が起きたのか
個人開発者が、2つのコーディネートを比較するAIアプリを公開しました。比較後、アプリは一方のスタイルが「勝った」と表示。App Reviewはガイドライン1.2に基づき、この結果を服ではなく人をランク付けしていると解釈してリジェクトしました。開発者もこの指摘に同意しました。
解決策
開発者は「winner」の文言、勝者バッジ、どちらの選択肢でもスコアを大きくしたり強調色を付けたりする表示をすべて削除しました。これで両方のスタイルは同じ視覚的重みを持ち、それぞれにフィードバックが出て、ユーザーが判断する形になりました。修正後のビルドが承認されたかは公表されていません。
教訓
Appleは画面の機能だけでなく、どう感じられるかも審査します。人の見た目に関わるものをスコア化するなら、ランキングなしでフィードバックを提示し、最も厳しい解釈を想定してください。
-
Kidsカテゴリ、ガイドライン3.1.2、プライバシーに関する疑問 iOSと キッズカテゴリ ガイドライン 3.1.2 終わりのない審査リジェクトから1ヶ月、いまだ審査待ちのキッズ向けストーリーアプリ
何が起きたのか
ある個人開発者が、4歳から10歳向けのストーリーアプリを制作しました。子供たちが物語を聞きながら、一時停止して質問ができる仕組みです。Android版はすでに数週間前からリリースされていました。2026年9月19日にApp Storeへ申請しましたが、何度もリジェクトと再申請を繰り返したものの、1ヶ月経っても承認されませんでした。最新の審査でAppleから指摘されたのは2点です。週額・月額・年額のサブスクリプションを販売しているため、App Storeのページに利用規約への有効なリンクが必要であること。そして、アプリが「キッズ」カテゴリであるため、サードパーティのアナリティクス、サードパーティ広告、データの第三者提供の有無と保存場所、その他のユーザー・デバイスデータを収集しているかどうかとその目的、という4つの質問に回答するまで審査を継続できないというものでした。
解決策
開発者は両方の問題を修正して再申請しました。投稿時点ではまだ結果待ちです。
教訓
キッズ・ヘルスケア・金融・教育系のアプリなら、現地のプライバシー法やストアから何を求められるかを早めに確認しましょう。例えば、子供のデータを収集する前に保護者の同意が必要かどうかなどです。初回申請の前に、利用規約のリンクとデータに関する回答を文書で用意しておきましょう。
-
ガイドライン 5.1.1(v) と 3.1.2 iOSと ガイドライン 5.1.1 ガイドライン 3.1.2バージョン 1.0 がサインイン、購入、削除の各フローでリジェクト
何が起きたのか
ある開発者のバージョン 1.0 は、アプリのアイデア自体とは無関係の3つの問題で一度にリジェクトされました。Sign in with Apple で名前が提供されているのに、アプリがまだユーザーに名前を尋ねていました。アカウント削除はアプリ内から開始できる必要がありました。また、サブスクリプションとサポート画面には、価格、更新条件、利用規約へのリンクを表示する必要がありました。開発者自身の結論は、3つすべてがサインイン、購入、削除に関するものだったということです。
解決策
記載なし
教訓
初回提出の前に、レビュアーになったつもりでサインイン、購入、アカウント削除のフローを確認してください。これら3つのフローが初回リジェクトの多くを引き起こします。
-
ガイドライン 5.2.3 オーディオ/ビデオのダウンロード iOSと ガイドライン 5.2.3 オーディオ/ビデオのダウンロードサードパーティ音源の権利により、ヴィンテージ風インターネットラジオが停止
何が起きたのか
個人開発者によるヴィンテージ風のインターネットラジオアプリ（バージョン1.0、5回目のビルド）が、ガイドライン5.2.3によりリジェクトされました。このガイドラインは、サードパーティのソースからオーディオやビデオを再生またはダウンロードするアプリを対象とし、開発者がそのコンテンツの権利を有している証明を求めています。開発者は翌日、Resolution Centerでコンテンツの権利について説明して返信しました。
解決策
投稿時点では、結果はまだ判明していません。
教訓
自分が所有していない放送局やメディアをストリーミングする場合は、許諾を取得するか、利用規約でアプリでの再生を明示的に許可しているソースを使い、提出前にその証拠書類をレビューノートに記載しておきましょう。
-
ガイドライン 4.3（スパム） iOSと ガイドライン 4.36回のリジェクト、4.3 スパム判定、そして通話まで2週間待ち
何が起きたのか
ある個人開発者が、社交の場での会話のきっかけになる初めてのアプリに数ヶ月を費やしました。しかし6回リジェクトされ、最後はガイドライン 4.3（スパム）による却下でした。開発者自身は、ストアにある類似アプリよりも自分のアプリの方が提供できるものがあると感じていました。開発者は App Review に1対1の通話を依頼しましたが、1週間待っても返信はなく、4.3 のリジェクトから約2週間後にようやく通話が実現しました。通話を終えた開発者は、4.3 が今や、手抜きに見える AI 生成のクローンアプリにフラグを立てるために使われているという印象を持ちました。開発者は自分のアプリはそうではないと述べています。
解決策
開発者は異議申し立てを行いました。執筆時点ではまだ結果待ちでした。
教訓
競合の多いカテゴリーでは、レビュアーはスクリーンショット、説明文、最初のセッションから判断します。既存アプリとの違いをそこで明確に示し、App Review との通話は早めに依頼しましょう。通話の設定には1週間以上かかることもあるからです。
-
合意に同意していない（ガイドラインの引用なし） iOSと 登録とアカウント1週間キューで待たされ、未署名の合意で却下され、さらに1週間
何が起きたのか
アプリは約1週間レビューを待った後、アプリ内の問題なしで却下されました。アカウントはApp Store Connectで新たに公開された合意にまだ同意していませんでした。開発者が同意して再提出すると、提出物は約1週間キューに戻りました。開発者サポートからの返信は「すべて順調です」のみでした。
解決策
執筆時点ではまだレビュー待ちです。
教訓
提出前に、App Store Connectで同意待ちの合意がないか確認してください。クリック1つ漏らすだけで、レビューキューを1周するコストがかかります。
-
審査中のクラッシュ（ガイドラインの記載なし） macOS ガイドライン 2.1開発者がインストールしていなかったmacOSバージョンでのクラッシュでリジェクト
何が起きたのか
あるMacアプリが、開発者がまだ使っておらずメインマシンに入れる気もなかったmacOS 27でのクラッシュを理由にリジェクトされました。クラッシュの再現方法を探す中で、AppleのVirtualization frameworkを使えばApple silicon上でmacOSの仮想マシンを無料で動かせると知り、新しいバージョンでのテスト用に環境を構築しました。
解決策
仮想マシンでクラッシュを再現したこと以外、詳細は不明。
教訓
App Reviewは最新のOSでテストします。メインマシンをアップグレードせずに審査中のクラッシュを再現できるよう、最新のmacOSの仮想マシンを用意しておきましょう。
-
審査の遅延（ガイドラインの指摘なし） iOSと 終わりのない審査迅速審査リクエスト2回の後も、12日間「審査待ち」が続く
何が起きたのか
すでにストアでアプリの承認実績がある開発者が、5つのサブスクリプションからなるサブスクリプショングループとともに、新規アプリのバージョン1.0を提出しました。通常は48時間以内に終わるはずが、12日経っても「審査待ち」のままです。開発者は迅速審査（expedited review）を2度リクエストし、サポートにも連絡しましたが返答はなく、App Reviewの予約も拒否されました。
解決策
執筆時点でも、まだ審査待ちのままです。
教訓
「平均48時間」を前提にリリース日を決めないでください。サブスクリプション付きの初版には数週間のバッファを取りましょう。迅速審査のリクエストや予約は確約ではなく、あくまで可能性として扱うべきです。
-
権限プロンプト + スクリーンショットのメタデータ（5.1.1 と 2.3.7 としてよく引用されるルール） iOSと ガイドライン 5.1.1 ガイドライン 2.3.7リリース週: 独自の許可画面とスクリーンショット内の価格
何が起きたのか
リリース週にアプリは2回リジェクトされました。1回目は、システムの権限プロンプトの直前に、独自の「許可」ボタン付き画面を表示していたためです。Apple はこれを認めていません。修正後、2回目は App Store のスクリーンショットに価格が表示されていたためリジェクトされました。両方の修正は小規模でしたが、再提出のたびにレビューキューで約1日かかりました。
解決策
開発者は両方の問題を修正し、再発防止のためプロジェクト内に両方のルールを明文化しています。
教訓
権限リクエスト前の画面でアクセスが必要な理由を説明するのは構いませんが、許可の選択肢はシステムプロンプトだけにしてください。スクリーンショットに価格を入れず、提出のたびに短いチェックリストを確認してください。
-
審査の遅延（ガイドラインの指摘なし） iOSと 終わりのない審査10日間審査が止まった後、再提出から30分で承認
何が起きたのか
アプリが10日以上審査中のまま動かなかったため、開発者が再提出を行った。
解決策
再提出から約30分後に承認された。
教訓
審査が止まっているからといって、それが必ずしもアプリへの評価とは限りません。通常より大幅に時間がかかっている場合は、再提出や迅速審査のリクエストを試す価値はありますが、どちらも確実ではありません。
-
4.3(a) スパム iOSと ガイドライン 4.3同じ1分間に4.3でリジェクトされた7つのテンプレートアプリ
何が起きたのか
ある小規模チームが、同じテンプレートで作った7つのアプリを同じ週に審査へ提出しました。すると、それまで一度もリジェクトされたことのない2つを含む7つすべてが、同じ1分間に全く同じ4.3(a) Spamのリジェクトを受けました。チームは、Appleが個別のアプリではなくバッチ全体を判断したのだと結論付けました。
解決策
現在、チームはアプリを1つずつ提出しています。
教訓
codebaseを共有するアプリは、同時に提出するとスパムパターンと見なされることがあります。提出の間隔を空け、機能・デザイン・メタデータで各アプリを明確に差別化してください。
-
ガイドライン 2.3.6 iOSと ガイドライン 2.3.6Connectの設定が既に一致していたのに年齢制限で却下
何が起きたのか
あるアプリが年齢制限を理由に却下されました。開発者がApp Store Connectで年齢制限のアンケートを開くと、どの回答も却下メッセージの指摘とすでに一致していました。
解決策
Connectの設定は一切変更せず、設定はすでに一致しているとレビュアーに返信して再提出しました。数時間後、アプリは承認されました。
教訓
2.3.6の指摘は、現在の設定と食い違っていることがあります。設定を変更する前にApp Store Connectを確認し、すでに一致しているなら、修正を推測するのではなく返信でその旨をはっきり伝えましょう。
-
ガイドライン 2.1 情報の不足 iOSと ガイドライン 2.1審査履歴の不足：実機での画面録画と有料機能のウォークスルー
何が起きたのか
Google Playの審査を通過していたアプリが、Appleからガイドライン2.1（情報の不足）を理由に差し戻されました。Appleは開発者アカウントの審査履歴が限られていると伝え、実機での画面録画、有料機能のウォークスルー、アプリの機能と利用している外部サービスの書面での説明を求めました。
解決策
投稿時点では、開発者は録画と回答を準備中でした。結果は不明です。
教訓
Google Playの審査に通ったからといって、Appleが通る保証はありません。開発者アカウントが新規、または過去の提出数が少ない場合は、提出前に実機での画面録画、有料機能のウォークスルー、利用しているサードパーティサービスのリストを準備しておきましょう。
-
ガイドライン 2.1、2.3.2、5.2.3 iOSと ガイドライン 2.1 ガイドライン 2.3.2 ガイドライン 5.2.3 オーディオ/ビデオのダウンロード 終わりのない審査初回提出：1ヶ月の間に2.1、次に2.3.2、そして5.2.3
何が起きたのか
ある開発者が初めて提出したアプリは6日間待たされた末、2.1でリジェクトされました。開発者はその日のうちに返信しました。12日後、今度は2.3.2で再びリジェクトされました。再提出すると、その9日後に5.2.3でリジェクトされました。またその日のうちに返信しましたが、2日後もまだ返答待ちでした。毎回、前回とは異なるガイドラインが指摘されていました。
解決策
初回の申請から1ヶ月以上経っても、いまだに審査待ちの状態です。
教訓
審査のやり取りを重ねるたびに新しいガイドラインを指摘され、その対応に1週間以上かかることもあります。初回申請の前に、完全性のルール（2.1）だけでなく、メタデータのルール（2.3）と自分に当てはまるコンテンツ権利のルール（5.2）も読み、見つかった問題は1回のビルドですべて直しておきましょう。
-
ガイドライン4.2 最小限の機能 iOSと ガイドライン4.2祈祷アプリが4.2に基づき、主に「本」であるとしてリジェクトされた事例
何が起きたのか
宗教的な祈祷・信心アプリが、主に「本」であるという理由で4.2に基づきリジェクトされました。開発者は、カレンダー、祈祷回数トラッカー、瞑想タイマー、共有可能なコレクション、ホーム画面ウィジェット、音声検索などのインタラクティブな機能を備えていると説明していました。
解決策
記載なし
教訓
レビュアーがアプリを静的コンテンツと受け取ると、レビュー開始から数分間はインタラクティブな機能が見えない可能性があります。最初の画面とスクリーンショットでそれらを見せ、レビューノートに各機能への到達手順を記載しましょう。
-
ガイドライン 2.3.10 iOSと ガイドライン 2.3.10審査待ち13日間、Androidに関する指摘でわずか7分でリジェクト
何が起きたのか
ある開発者は審査キューで13日間待ち、毎日 App Store Connect とメールを確認し、サポートリクエストを2件送信しました。ようやく審査が始まった矢先、App Store の説明文に「iPhone または Android のあらゆるブラウザで動作する」とあったため、約7分後にリジェクトされました。
解決策
他プラットフォームへの言及を1行削除して再提出。結果はまだ報告されていません。
教訓
Appleは他プラットフォーム名を記載したメタデータをリジェクトします。提出前に、説明文、スクリーンショット、プロモーションテキストに競合プラットフォーム名が含まれていないか確認してください。わずかな文言のミスで、審査キューを一から待ち直すことになりかねません。
-
ガイドライン5（Legal） iOSと ガイドライン5 Legal中国向けメタデータのOpenAI言及によるガイドライン5のリジェクト
何が起きたのか
あるAIアプリが、メタデータにOpenAIへの言及があったため、ガイドライン5（Legal）に基づきリジェクトされました。Appleの説明によると、中国では生成AIおよびディープシンセシス（深層合成）サービスに政府のライセンスが必要ですが、ChatGPTはその許可を得ていないとのことです。開発者は、中国のストアフロント向けにAI機能を削除し、名前、サブタイトル、プロモーションテキスト、説明文、スクリーンショットからOpenAIやChatGPTに関するすべての言及を削除するか、中国本土での配信を停止するかのいずれかを選ぶ必要があります。
解決策
開発者は、それらのサービス名を含むアプリを申請する前に、配信地域で中国本土のストアフロントを選択解除することを勧めています。これで審査サイクルを1回節約できます。
教訓
生成AIプロバイダーを使っているアプリなら、中国での配信可否は最初に決めておきましょう。リジェクトの原因はストアフロントとメタデータであり、code だけではありません。
-
ガイドライン 3.1.2 iOSと ガイドライン 3.1.2アプリ内には利用規約のリンクがあるが、説明文にはない
何が起きたのか
サブスクリプションアプリの初版が、申請から2日後にリジェクトされました。App Store の説明文に利用規約のリンクがなかったためです。アプリ内のペイウォールや設定画面にはあったのですが、メタデータ欄だけ抜けていました。
解決策
修正には5分しかかかりませんでしたが、再提出したビルドは「審査待ち」のまま10日以上反応がありませんでした。報告はまだありません。
教訓
自動更新サブスクリプションでは、初回提出前にApp Storeのメタデータとアプリ内の両方に利用規約（EULA）とプライバシーポリシーへのリンクを入れてください。ちょっとした修正でも、2回目の審査で長く待たされることがあるからです。
-
アカウント終了 iOSと アカウント終了3.2(f)でアカウント停止、保留中の収益は未払い
何が起きたのか
ある開発者のApple Developerアカウントが、Developer Program License Agreementのセクション3.2(f)に基づき停止されました。3か月近く経っても保留中の収益はまだ支払われておらず、その開発者は他の開発者に、アカウント停止後に保留された収益を受け取ったことがある人がいるか尋ねていました。
解決策
報告なし
教訓
アカウント停止は将来の売上だけでなく、すでに得た収益も凍結させかねません。キャッシュランウェイ、入金記録、自前のユーザーチャネルを確保し、アカウントに関する判断ひとつでビジネスが終わらないようにしましょう。
-
ガイドライン2.1と5.1.2 iOSと ガイドライン 2.1 ガイドライン 5.1.2 終わりのない審査25日間の審査を経て、2.1と5.1.2で同時にリジェクト
何が起きたのか
ある個人開発者がiOSアプリの初版1.0を提出しました。しかし、約17日経ってもビルドはレビュー中のまま。合計で約25日が経過した頃、App Reviewはガイドライン2.1（App Completeness）と5.1.2（Data Use and Sharing）に基づき、同じ判断でリジェクトしました。その後App Store Connectは、リジェクトされたバージョンが修正されるまで、提出中の他のすべてのアイテムをブロックしました。開発者によれば、指摘された問題は簡単に修正できるものでしたが、辛かったのは再提出にさらに2〜3週間かかると覚悟しなければならなかったことです。
解決策
両方の問題を修正して再提出しましたが、その後のレビュー結果については報告されていません。
教訓
レビュー待ちがこれほど長引くと、一度のリジェクトが数週間の損失に直結します。提出前に、フローの不備がないか、デモ用アカウントが動作するか、プレースホルダーが残っていないかなど、完全性を徹底的に確認してください。また、プライバシーに関する回答や、SDK のデータ共有がアプリの実際の挙動と一致しているかも必ず確認しましょう。
-
ガイドライン 2.3.1(a) iOSと ガイドライン 2.3.1 メタデータとIAP2.3.1(a)に基づき、リアルマネーのステークが隠れたものとしてリジェクト
何が起きたのか
ある開発者が、習慣と規律のトラッカーを作りました。ユーザーはお金を賭け、目標を逃すとそれを失う仕組みです。2026年10月中旬、App Reviewはガイドライン2.3.1(a)に基づいて却下し、メタデータに記載のない隠れた機能、具体的には金銭を賭ける機能と賭け金の没収が含まれていると指摘しました。通知にはExtended Reviewの警告もあり、同様の問題を抱えた再提出を繰り返すと審査時間が長くなり、ルール違反を繰り返すアカウントはApple Developer Programから削除され得ると述べていました。このアプリは合計5回却下され、別の1回はiPadでの審査中にクラッシュしたことが理由でした。AIコーディングツールで開発したこの開発者は、教訓を次のようにまとめています。ガイドラインを読み、メタデータをアプリの内容に合わせ、機能やデータ収集を隠さず、生成されたcodeを確認し、さまざまなデバイスでテストすること。
解決策
5回の却下後にアプリを作り直した以外は述べられていません。承認されたとの報告はありません。
教訓
実際のお金が動く機能（賭け金や没収を含む）は、説明とApp Reviewのメモに明確に記載する必要があります。iPhone向けでも、審査員はiPadでテストするので、iPadでもテストしてください。
-
ガイドライン4.3(a) iOSと ガイドライン 4.3新機能、新しいスクリーンショット、そして3分で警告付きの4.3(a)
何が起きたのか
ゼロからアプリを開発するのに約2か月を費やした開発者が、すでに4.3（スパム）でリジェクトされていました。次の申請では新機能を追加し、すべてのスクリーンショットを差し替え、より多くのデバイスサイズに最適化したうえで、レビューノートとプレミアムテストアカウントを添えて再提出しました。しかし、レビュー開始からわずか3分後に再びGuideline 4.3(a)でリジェクト。今回は延長レビューに関する通知が添えられ、「同様の問題を含む申請を繰り返すとレビュー時間が長引き、こうしたアプリを出し続けるアカウントはApple Developer Programから削除される可能性がある」と結ばれていました。再提出がアカウント全体を失うことにつながるのではと恐れた開発者は、アプリを諦めるか、App Reviewに電話を依頼するか、判断を迫られていました。
解決策
投稿時点では未解決。
教訓
延長レビュー通知が出た後は、すぐの再提出が最も危険な選択です。まずApp Reviewとの電話を依頼し、何を類似と見なしているか分かってから再提出しましょう。
-
ガイドライン 4.3(b) iOSと ガイドライン 4.33分でリジェクト、異議申し立ては3週間沈黙
何が起きたのか
ある開発者のアプリは、審査に入って約3分後にガイドライン4.3(b)でリジェクトされました。開発者はApp Review Boardに異議を申し立てましたが、3週間経っても回答もステータス変更もなく、一切の連絡がありませんでした。
解決策
未解決。
教訓
異議申し立ては、フィードバックがないまま数週間放置されることがあります。混雑したカテゴリの中でアプリを差別化できる要素に並行して取り組み、異議申し立てだけを待って足止めされないようにしましょう。
-
アカウント終了 iOSと アカウント終了あるアプリがウェブサイトのように見えたことで、数十ものアプリが姿を消しました
何が起きたのか
10年以上にわたり80本以上のアプリを公開してきたスタジオの開発者アカウントに、終了対象のフラグが立てられました。スタジオによると、理由はアプリの1本が既存のウェブサイトと類似していると見なされ得るというものでした。警告も、そのアプリだけを削除する選択肢もありませんでした。クライアント向けに構築した無関係なライセンス付きアプリを含め、すべてのアプリがApp Storeから削除され、アップデートもブロックされました。
解決策
未解決。スタジオはこの決定に公に異議を唱えました。
教訓
開発者アカウントが1つしかないと、それが単一障害点になります。クライアント向けにアプリを構築する場合は、クライアント自身の開発者アカウントで公開してください。そうすれば、あなたのアプリの1本をめぐるトラブルで、クライアントのアプリまで削除されることはありません。
-
第3.2(f)条（Developer Program License Agreement） iOSと アカウント終了タイトル更新の後、3.2(f)条の終了通知
何が起きたのか
ある個人開発者がアプリの単純なタイトル変更を申請したところ、セクション3.2(f)に基づきアカウント停止通知を受け取りました。すべてのアプリがストアから削除され、公式に異議申し立てを行いましたが、15日が経過しても担当者からの返答はありませんでした。
解決策
未解決。
教訓
3.2(f)の通知を招くアップデートが、Appleが実際に反応している対象とは限りません。異議申し立ての前に、各アプリの所有者と運営者を証明する明確な証拠を揃え、回答には数週間かかると想定しましょう。
-
第3.2(f)条（Developer Program License Agreement） iOSと アカウント終了ペイウォールの修正1回で、1週間後に3.2(f)の停止通知
何が起きたのか
ある個人開発者のアプリが、ペイウォールでの年額・週額の表示方法を理由に一度リジェクトされました。そのペイウォールは、AIコーディングアシスタントがコピーしてきたテンプレートによるものでした。開発者は code で修正し、新しいビルドを提出して1週間ほど待ちました。しかし返ってきたのは審査結果ではなく、セクション3.2(f)に基づく終了予告通知でした。開発者メンバーシップ全体にフラグが立てられ、数年間にわたって構築してきたすべてのアプリがApp Storeから削除され、支払いも凍結されました。開発者は、提出後にアプリを一切変更しておらず、それを裏付けるログもあると主張し、アカウントを取り戻せた人がいるか公に問いかけました。
解決策
投稿時点では未解決。
教訓
ペイウォールや価格表示に関するリジェクトは、単なる形式ではなく警告として捉えてください。最初の提出前に、テンプレートや生成されたペイウォールの code で、価格やトライアル条件がどう表示されるか確認しましょう。また、アカウントが問題視されたときに何を提出したかを正確に示せるよう、ビルドログと変更ログを残しておきましょう。
-
ガイドライン3.1.1 In-App Purchase macOS ガイドライン 3.1.1ストリーミング配信されるゲーム内の購入を理由に、3.1.1に基づきリジェクトされた無料のクラウドゲームクライアント
何が起きたのか
ある開発者が、大手コンソールメーカーのクラウドゲーミングサービス向けに無料のリモートプレイアプリを開発し、App Storeへ申請しました。しかし、Mac版がガイドライン3.1.1に基づきリジェクトされました。App Reviewの指摘は、「ストリーミング配信される一部のゲームが、App Store外でのデジタルコンテンツ購入にユーザーを誘導する可能性がある」というものでした。開発者の認識では、そのゲーミングサービスはストリーミング中に決済を完了させる仕組みにはなっていません。一部のゲームに購入オプションが表示されることはあっても、ストリーミング中は決済ができない仕様です。開発者は、同様のストリーミングアプリが既にストアに多数存在することを指摘し、異議申し立てを行いました。
解決策
投稿時点では異議申し立て中。
教訓
ストリーミングアプリやクライアントアプリの場合、App Reviewはあなた自身の code だけでなく、配信コンテンツ内でユーザーが見られるものも審査します。異議申し立てまで先送りせず、最初の申請前にスクリーンショットを添えて、ストリーム内で購入がどう動作するかをレビューノートで具体的に説明しましょう。
-
iPadでのログイン（ガイドライン番号の記載なし） iOSと ログインバックエンド障害中にiPadでログインできず、3度目のリジェクト
何が起きたのか
あるフィットネスアプリを開発する小規模チームが、iOSアプリの審査で3度目のリジェクトを受けました。原因は、レビュアーがiPadでログインできなかったことでした。しかし、問題はアプリの code 側ではありません。レビュアーが試した時点で、ホスティングしているバックエンドプロバイダーに認証障害が起きており、サインインに失敗しただけだったのです。チームはメールアドレスとパスワードのデモアカウントを用意していましたが、チームの説明では、レビュアーはその後そのアカウントで再試行しなかったとのことです。チームにはテストに使えるiPadもMacもありませんでした。バックエンドの復旧後、チームは再申請しました。Appleは、再度リジェクトされても優先審査（expedited review）が続くと伝えていましたが、3営業日経ってもまだ審査待ちでした。
解決策
再申請済み。投稿時点ではまだ審査待ちです。
教訓
レビュアーはiPadでテストすることが多く、ログインの試行は通常一度きりです。ビルドが審査中の間は、バックエンドや認証プロバイダーのステータスを監視しましょう。提出前にiPadサイズの画面でデモアカウントの動作確認を行い、レビューノートには、サインインに失敗した場合の連絡先を書いておきましょう。
-
ガイドライン 5.1.1(i) と 5.1.2(i) iOSと ガイドライン 5.1.1 ガイドライン 5.1.2 AIデータの共有利用規約に埋め込まれたAIへの同意は、5.1.1(i)および5.1.2(i)の要件を満たせなかった
何が起きたのか
ある開発者のジャーナルアプリが、ユーザーデータをAIサービスと共有することに関するガイドライン5.1.1(i)および5.1.2(i)に抵触し、iOSでリジェクトされました。その処理への同意はすでにアプリの利用規約に含まれていましたが、App Reviewはそれを認めませんでした。開発者は同意をアプリ内の明示的な画面に移し、モデルがエントリーを1件でも読み取る前に最初に表示するようにしました。さらに、エントリーがモデルに到達するすべての code パスを洗い出し、同意が得られていなければリクエスト自体が構築されないよう、各パスにゲートを設けました。バックグラウンドジョブは同意していないアカウントをスキップし、失敗させる代わりに待機するようになり、同意画面に記載のないAIホストをアプリが呼び出している場合はリリースチェックで失敗するようになりました。
解決策
修正して再提出。投稿時点でAppleの判定はまだ不明でした。
教訓
利用規約の一行は、AIデータ共有への同意にはなりません。最初のリクエストの前にアプリ内でユーザーに確認を求め、プロバイダーとデータを明示してください。そして、ユーザーコンテンツを送信するすべての code パスが、その回答を確認していることを徹底してください。
-
メタデータのリジェクトが繰り返された後の、セクション 3.2(f)（Developer Program License Agreement） iOSと アカウント終了 メタデータとIAP新しいライブラリ1つ、8回のリジェクト、アプリ名変更、そしてアカウント停止通知
何が起きたのか
ある個人開発者が、リリースから3年近く経ち、6桁の収益を上げ、低い返金率で多くのアップデートを配信してきたiOSアプリを運営していました。半年以上前、彼らは新しいライブラリを1つ追加しただけの小さなアップデートを申請しました。しかしApp Reviewは8回以上もリジェクトを繰り返し、その理由は毎回メタデータに関するものでした。1年以上公開されていたキーワード、あるローカライズのサブタイトル、次にスクリーンショット、そしてまた同じ指摘が繰り返され、最後には検索トラフィックの大半を占めていたアプリ名そのものにまで及びました。彼らはApp Reviewとの通話を求め、レビュアーは「アプリ名が最後に残った問題だ」と告げました。そこで彼らはアプリ名を全面的に変更して再申請しました。しかし3日後、返ってきたのはサブタイトルとスクリーンショットの問題を指摘する定型的なリジェクト通知でした。結局、彼らはそのアップデートは不要だと判断し、取り下げました。数ヶ月後、同じ古いレビュースレッドに、アカウント停止の予告通知が届きました。そこには、レビュープロセスを回避しようとしてガイドラインに繰り返し違反しており、以前のメッセージでの指摘が未解決のままであると記されていました。アプリはストアから削除され、アカウント全体が削除対象としてフラグを立てられました。
解決策
App Review Boardへ異議申し立て済み（投稿時点では保留中）
教訓
放置された申請でも、アカウントに不利にカウントされる可能性があります。レビューが堂々巡りする場合は、残りの課題を電話だけでなくレビュースレッドで書面によりすべて確認してください。アップデートを中止する場合は、スレッドでその旨を返信し、リジェクトを未解決のままにせず、レビューからビルドを削除してください。
-
ガイドライン1.1「安全性：不適切なコンテンツ」、続いてセクション3.2(f) iOSと 不適切なコンテンツ アカウント終了1.1リジェクトが2件、どの画像かという質問、続いてアカウント終了通知
何が起きたのか
ある開発者のiOSアプリは、不適切なコンテンツ（ガイドライン1.1）を理由にリジェクトされました。しかし、どの画像が問題なのかは示されませんでした。開発者は接触や身を寄せる動作のない、控えめなサンプル画像に変更し、約5日後に一度再提出しました。その4日後、再び同じ理由でリジェクトされました。新たなビルドを送る代わりに、どの画像が問題なのかをAppleに問い合わせるメールを送りました。約10日間返信がないまま、アプリはストアから削除され、開発者にはアカウント終了予告の通知が届きました。彼らの理解では、Appleは修正と再提出の繰り返しを審査を回避しようとする試みとみなしたようです。支払いは停止され、アカウント内の全アプリが危険にさらされ、異議申し立ての期限は30日間でした。同じ通知を受けた開発者によるフォーラムのスレッドを読むと、ほとんどの異議申し立ては数週間回答なしで放置されており、唯一見つかった復帰事例は、実際の原因を明示し、その他すべてを開示した2度目の異議申し立てによるものでした。
解決策
投稿時点で異議申し立てを準備中。
教訓
現在では、同じガイドラインによる2度のリジェクトだけで、アカウントが危険にさらされる可能性があります。コンテンツに関するリジェクト内容が曖昧な場合は、再提出する前にApp Reviewに対し、具体的な画面やアセットを特定するよう求めてください。また、すべての変更を記録し、2度目のリジェクトを受けた際は、再挑戦するのではなく一旦止まるべきサインとして捉えてください。
-
ガイドライン2.3.7、5.2.5、4.8 iOSと ガイドライン 2.3.7 メタデータとIAP ログイン要件Macでは承認されたのに、同じアプリのiPhone版が2.3.7、5.2.5、4.8で拒否された
何が起きたのか
ある開発者が、大手サードパーティのカレンダーサービス向けカレンダークライアントを開発し、まずMac版をリリースしました。Mac版は、ストアの掲載情報にそのカレンダーサービスと連携していると記載するだけでも正式な異議申し立てが必要で、なぜSign in with Appleが不要なのかもすでにApp Reviewへ説明済みでした。しかし、Mac版と同じBundle ID、同じApp IDでiPhone版を追加したところ、3つのガイドラインで同時に拒否されました。アプリ内イベントに表示した価格で2.3.7、アプリがiPhone、iPad、Mac向けだと書いた文言で5.2.5、カレンダーサービス独自のログインの隣にSign in with Appleを出していないことで4.8です。ガイドライン4.8には、特定のサードパーティサービスのクライアントであるアプリ向けの例外があり、このアプリはまさにそれに当たりますが、Mac版で示した説明は引き継がれませんでした。プラットフォームごとのターゲットはゼロから審査されました。
解決策
投稿時点では明記されていません。
教訓
同じApp ID内でも、新しいプラットフォームは新しい審査です。すでに勝ち取った説明や例外はすべて各プラットフォームの審査メモにコピーし、提出前にアプリ内イベントや説明文の価格とAppleデバイス名を確認してください。
-
ガイドライン3.1.2(c)、およびSiriのテキスト内でのApple商標使用（ガイドライン番号は未記載） iOSと ガイドライン 3.1.2 終わりのない審査9日間の待機、3.1.2(c)のペイウォールによるリジェクト、そしてSiriのテキストを理由に42秒でバイナリがリジェクト
何が起きたのか
新規アカウントのデベロッパーが執筆習慣アプリの初版を提出し、約9日間待機した後に「審査中」へと移りました。しかしその50分後、ガイドライン3.1.2(c)でリジェクトされました。年額プランで、計算上の月額料金が実際に請求される年額よりも大きいフォントで表示されていたためです。デベロッパーはペイウォールのフォントサイズを修正し、新しいビルドをアップロードしました。ところがそのビルドは42秒で自動リジェクトされました。SiriショートカットのヘルプテキストがAppleのアプリをブランド名で挙げており、Siriインテント内のテキストでは「Apple」という語を使えないためです。デベロッパーは特定のアプリ名を避けて「メモアプリ」と一般的な表現に書き換え、再度ビルドをアップロードしました。
解決策
再提出済み。投稿時点では結果は不明。
教訓
初回提出前に、全プランで請求額を最も目立つ価格にし、Siri、Shortcuts、ウィジェットのテキストを含むすべてのユーザー向け文字列にAppleの商標がないか確認してください。自動チェックなら数秒で見つかりますが、各ラウンドでキューの順番を1つ失います。
-
セクション3.2(f)（Developer Program License Agreement）、旧名称での拒否を引用 iOSと アカウント終了 メタデータとIAP名称の拒否を修正して承認された後、約1年後に不正行為による終了通知が届いたケース
何が起きたのか
小規模な会社アカウントを運営する個人開発者が、約1年半で8本のアプリを公開していました。その約1年前、アプリの1本が、名前に含まれるある単語をAppleが問題視したためリジェクトされました。開発者は名前を変更し、再審査の結果承認されました。その後のアップデートも承認されています。共有された審査履歴では、バージョン1.0が2日連続でリジェクトされた翌日に承認され、その約2ヶ月後のアップデートも初回で承認されています。その後、そのアプリは約9ヶ月間更新されませんでした。その後、同じアカウントの新しいアプリがリジェクトされ、セクション3.2(f)に基づく「不誠実または詐欺的な活動」を理由とするアカウント終了予告が届きました。内容は、審査を回避しようとする繰り返しのガイドライン違反と、過去のメッセージで指摘された問題が未解決であるというものでした。新たな問題の指摘はなく、事前の警告や質問もありませんでした。問題のなかったアプリを含むすべてのアプリで収益の支払いが停止され、新しいアカウントも終了される可能性があるとの警告も添えられていました。唯一の返答手段は2,000文字制限のあるWebフォームのみで、送信しても自動返信が返るだけで、その後は音沙汰なしでした。開発者は対象アプリの削除を受け入れ、同日中にサーバーを停止し、すべての提出を中断、初日に正式な異議申し立てを送りました。
解決策
異議申し立ては初日に送信済み。公開時点では自動返信のみでした。
教訓
修正して承認されたリジェクトでも、数ヶ月後にパターンの一部として再び引用されることがあります。各リジェクトのメッセージ、行った正確な変更、その後の承認をすべて残しておきましょう。短い異議申し立てフォームで全履歴を示せるようにするためです。提出後は、いつ完了するか分からないものと考えてください。
-
ガイドライン4.3（スパム）と4.2.6 iOSと ガイドライン 4.3 ガイドライン 4.2.6個人で作ったゲームがスパムとテンプレートを理由に2度リジェクト、9回回答するも返信なし
何が起きたのか
夜に個人でゲームを制作している開発者が、オリジナルのゲームを提出したところ、10月初旬に4日間隔で2度リジェクトされました。理由はガイドライン4.3（スパム）と、商用テンプレートやアプリ生成サービスから作成されたアプリを対象とする4.2.6でした。テンプレートは一切使っておらず、すべてのコードは開発者自身が書いたものです。どちらのリジェクトも同じテンプレート文言で、類似しているとされるアプリ名すらありませんでした。その後、Appleからゲームの制作方法について9つの質問が届き、開発者は2度目のリジェクトの翌日にすべて詳しく回答しましたが、返信はありませんでした。約9日後にApp Review Boardへ異議を申し立て、その1週間後もまだ待っていました。開発者自身は、数ヶ月の間に複数のゲームをリリースしていると審査官からは「アプリ工場」のように見えるのではないかと推測していました。その間、開発者はブラウザ上でゲームを無料で遊べるようにしました。
解決策
App Review Boardへの異議申し立て（Appeal）は投稿時点で係属中。最初のリジェクトから約3週間後。
教訓
4.3と4.2.6は、単一のバイナリではなくアカウント全体で判断され得ます。短期間に複数のタイトルをリリースするなら、初回申請の時点で各タイトルのどこがオリジナルなのかを、どのように作ったかのレビューノートと短いゲームプレイ動画を添えて示してください。リジェクト文がテンプレート化されると、詳細な回答は数週間読まれないままになるからです。
-
ガイドライン2.1（App Completeness）、続いてガイドライン5（Legal / 中国での提供可否） iOSと ガイドライン 2.1 ガイドライン5 Legal 終わりのない審査レビュアー用の無料ライセンスがペイウォールを隠してしまい、その後6日間キューで待たされ、中国のAIによるリジェクト
何が起きたのか
ある開発者が、定期的な支払いを管理する個人向けファイナンスアプリを初めてiOS向けに提出したところ、ガイドライン2.1（App Completeness）でリジェクトされました。原因は、良かれと思ってしたことが裏目に出たことでした。審査員用のメールアドレスに有料ライセンスを付与していたため、審査員がペイウォールをスキップし、購入フローを確認できなかったのです。開発者は審査員向けにスクリーンショット付きの手順PDFガイドを作成して再提出し、今回はiOS版とMac版を同時に送りました。新しい申請はIn Reviewに移るまで6日待たされ、その後再びリジェクトされました。今回は、アプリを中国本土でも配信していた状態でChatGPTに言及していたことが理由でした。
解決策
この記事を投稿した時点でもまだリジェクト状態にありますが、新しいビルドはTestFlightを通じてテスターに提供されています。
教訓
App Reviewには、ペイウォールを含め、新規ユーザーが見る画面を正確に見せてください。購入フローを隠す無料ライセンスではなく、動作するデモまたはサンドボックスアカウントと分かりやすいメモを審査員に渡しましょう。アプリやストア掲載情報でChatGPTなどのAIプロバイダー名を出している場合は、提出前に中国本土が配信対象に含まれているか確認してください。再提出のたびに審査キューで数日待つことになるためです。
-
ガイドライン2.3.10 Accurate Metadata iOSと ガイドライン 2.3.10 メタデータとIAP 終わりのない審査初回レビューまで10日、Google Playへの言及、さらに2週間の待機
何が起きたのか
10月初旬、新しい開発者アカウントで新しいアプリを提出した開発者がいました。ユーザーが自分の画像を公開アップロードできるアプリで、開発者はコンテンツモデレーションの追加審査を受けると予想していました。初回レビューは10日後にiPadで実施され、ガイドライン2.3.10「正確なメタデータ」に基づき却下されました。アプリまたはそのメタデータにサードパーティのプラットフォームが言及されており、次のステップはGoogle Playへの言及を削除することでした。開発者は、その言及がアプリ内購入を説明するテキストにあることを特定しました。修正後、アプリはキューに戻り、2週間後でもまだレビュー待ちでした。初回提出から24日が経過しても、まだ公開されていません。
解決策
投稿時点ではまだレビュー待ちで、初回提出から24日が経過しています。
教訓
初回提出前に、アプリ内購入の説明を含むすべてのテキストフィールドを検索し、他のストアやプラットフォームの名前がないか確認してください。新しいアカウントでは、1回の往復でキュー待ちに1週間以上かかる可能性があるため、たった1語の言及がローンチを数週間遅らせることになります。
-
ガイドライン2.1 アプリの完全性（必要な情報） iOSと ガイドライン 2.1 終わりのない審査審査待ち24日、その後届いたのは画面全体の録画を求めるガイドライン2.1のリジェクト
何が起きたのか
ある開発者が、新しいiOSアプリのバージョン1.0.0を、サブスクリプショングループと年払い・月払いの2つのサブスクリプションと共に提出しました。24日間待たされた後、Appleが審査した結果、ガイドライン2.1（App Completeness）に基づいてリジェクトされました。開発者はこれに困惑したと述べています。アプリのバージョンがリジェクトされたため、同時に提出していたサブスクリプションも承認されず、「Ready for Review」のままとなりました。リジェクトの通知内容は、開発者が初めて受け取った「2.1 Information Needed」の要求でした。最新のOSを搭載した実機で、起動から登録、ログイン、アカウント削除、UGCがある場合はその通報・ブロック機能、有料コンテンツへのアクセスといった典型的なユーザーフローを示す画面録画が求められました。また、目的とターゲット層の説明、ログイン情報を含むセットアップ手順、AIサービスを含む、アプリが依存している外部サービス一覧、地域による違い、規制対象業界や第三者の保護された素材に関するドキュメントも求められました。さらに、これらの回答は今後の提出に備え、App Store ConnectのReview Notesに追加しておく必要がありました。
解決策
投稿時点で、開発者は録画と回答の準備に戻っていました。結果は不明です。
教訓
数週間キューで待った後に「Information Needed」の要求が来ると、さらに一往復のやり取りが必要になります。新しいアプリを提出する前に、実機での操作を録画し、その回答をレビューノートに書いておきましょう。特にサブスクリプション、アカウント、ユーザーコンテンツがあるアプリでは。拒否されたバージョンは、一緒に提出されたものもすべて止めてしまうからです。
-
第3.2(f)条（Developer Program License Agreement） Apple Developer Program アカウント終了 終わりのない審査6回連続で承認されたアップデート、その後通常のアップデートと3.2(f)によるアカウント停止
何が起きたのか
あるインディー開発者は6回連続でアップデートが承認されていました。共有されたレビュー履歴では、最新の提出が「レビュー中」、それ以前のものはすべて「レビュー完了」となっています。その後10月中旬に通常のアップデートを提出しましたが、レビューで止まったままです。レビュー結果の代わりに、開発者アカウント全体が3.2(f)条項に基づいて停止されました。App Store Connectでは、その提出日の日付が付いたメッセージが複数のバージョンに紐づけられ、「未解決の問題」としてマークされていました。開発者はアプリがネイティブで、承認されたアップデートの履歴に問題がないと説明し、Appleサポートが異議申し立てを調査中だと述べています。
解決策
投稿時点では異議申し立てを調査中。
教訓
審査を連続で通過していても、3.2(f)による契約終了を防げるわけではありません。提出物、レビューメッセージ、承認結果はすべて日付付きで記録し、各審査後にApp Store ConnectのMessagesセクションを確認してください。そうすれば、異議申し立てが可能になった瞬間に全履歴を送れます。
-
App Reviewの情報提供依頼（デモアカウントと画面収録） iOSと ログイン提出から5分後に削除されたデモアカウント、そして2度目のリジェクトを防いだ画面収録の依頼
何が起きたのか
ある代理店が、App Review用のデモアカウント付きでクライアントのアプリを提出しました。提出から5分後には、App Reviewがそのデモアカウントを削除していました。その後Appleからアプリの画面収録を求められ、収録中にチームはアプリ内の見落としていたセールスコピーを発見しました。そのままなら再びリジェクトされていたでしょう。
解決策
投稿時点では最終結果は公開されていません。
教訓
アカウント削除が機能するかを確認する際などに、レビュアーが提供したデモアカウントを削除してしまう可能性があります。再作成できる手段を用意するか、複数のアカウントを提供しておきましょう。提出前に自分でレビュー用のウォークスルーを録画しておくのもおすすめです。レビュアーと同じようにアプリを見ることは、次のリジェクトにつながる文言を手軽に見つける方法です。
-
第3.2(f)条（Developer Program License Agreement） Apple Developer Program アカウント終了 メタデータとIAP5回の初期リジェクト、4回のアップデート承認、そして1年以上たってからの3.2(f)通知
何が起きたのか
10年近いアプリ開発歴を持つ個人iOSデベロッパーが、2025年4月にAI画像から動画を生成する新アプリを提出しました。ユーザーは自分の写真をアップロードし、最初の生成を無料で利用でき、その後はサブスクリプションなしで、単発のアプリ内課金でクレジットを購入できました。最初の提出は、主にスクリーンショットとメタデータが理由で5回リジェクトされました。スクリーンショットはマーケティング色が強すぎると判断され、カップルがキスしているスクリーンショットと、その差し替えのプロポーズのスクリーンショットが「不適切なコンテンツ」ガイドラインに抵触すると指摘されました。スクリーンショットとそのテキスト、ビルドを変更した後、アプリは承認され、その後4回のアップデートも一度もリジェクトされず、最後は2025年8月でした。それ以降、アップデートは提出されていません。14ヶ月以上経った頃、「Pending Termination Notice」が届きました。アカウントからの提出物が審査を回避しようと繰り返しガイドラインに違反しており、複数回の再提出後も違反が解消されていない、という内容で、5バージョンすべてに添付されていました。デベロッパーによると、App Store Connectには過去のリジェクトを再現するのに十分な詳細が表示されなくなっていました。通知が真夜中頃に届き、その約30分後に2,000文字以内で異議申し立てを行いましたが、後になって、待ってからもっと明確に書けばよかったと思いました。
解決策
投稿時点では異議申し立て中。
教訓
承認されても案件は終わりません。却下メッセージ、引用されたガイドライン、変更内容、承認日はすべて自分の手元にコピーしておいてください。App Store Connectでは後から古い詳細が表示されない可能性があるからです。通知が届いたら、最初の1時間で送るのではなく、文字数制限に収まる明確な異議申し立てを書く時間を取りましょう。
-
第3.2(f)条（Developer Program License Agreement） Apple Developer Program アカウント終了 メタデータとIAPタイトル内のキーワード、3.2(f)によるアカウント停止、そしてストリーミングへの言及を指摘した異議申し立てへの回答
何が起きたのか
ある個人開発者が、セクション3.2(f)に基づきデベロッパーアカウント全体を停止されました。開発者の話では、事前の警告もメタデータの却下も一切なく、原因はアプリタイトルのキーワードミスだと考えていました。開発者は異議申し立てを行いました。App Review Boardは、調査の結果ガイドライン違反が確認されたと回答しました。開発者のアプリの1つに、ユーザーがストリーミングサービスを提供していると誤認するような誤解を招く記述があり、Appleはこれを悪質だとしたのです。通知は、人を操るような、または誤解を招く行為のパターンを指摘し、収益の支払いを止めたままにし、停止が正式になれば、開発者は理由と計画している改善点を説明してApp Review Boardに復帰を申し立てられると述べていました。
解決策
異議申し立ては却下されました。正式にアカウントが終了した後は、復帰申請が可能です。
教訓
タイトルやキーワードに、アプリが提供していない機能（ストリーミングなど）を想起させる言葉が含まれていると、単なるメタデータのミスではなく「誤解を招く表現」と判断されます。その場合、リジェクトなしで即座にアカウント停止に至ることもあります。申請前に、タイトル、サブタイトル、キーワードがアプリの実態と一致しているか必ず確認してください。
-
ガイドライン 4.1(a) コピーキャット iOSと 終わりのない審査15日間の審査の末、公開 API の映画ポスターが原因で4.1(a) コピーキャットとしてリジェクト
何が起きたのか
ある開発者が、映画選びをサポートするiOSアプリを制作しました。このアプリは、公開されている映画データベース API から取得したタイトルとポスターを表示し、アプリ内でクレジットを明記しています。また、視聴ボタンを押すと、アプリ内で再生するのではなく、公式のストリーミングアプリが開く仕様です。しかし、15日間の審査を経て、Appleはガイドライン4.1(a)「コピーキャット」に基づきリジェクト。ポスターを第三者のコンテンツと見なし、使用権の証明または削除を求めました。なお、同じポスターを使用した同じアプリは、AndroidやTVデバイスのアプリストアでは承認されていました。
解決策
投稿時点では未解決。開発者は他の開発者に、API の利用規約が証拠として認められるのか、それともポスターを外す必要があるのかを尋ねていました。
教訓
アプリ内のクレジット表記や他ストアでの承認は、App Review では権利として認められません。アプリで API のポスター、アートワーク、ロゴを表示する場合は、提出前に表示許可の書面を用意するか、それらを外したバージョンを計画してください。
-
メタデータの拒否（ローカライズされたキーワード） iOSと メタデータとIAPAIで5言語に翻訳したアプリにキーワードが紛れ込み、リジェクトされた話
何が起きたのか
ある開発者がAIモデルでアプリをさらに5言語に翻訳しました。そのうち1つの言語で、翻訳によって誤読されかねないキーワードが紛れ込み、それが原因でリジェクトされました。1週間経っても回答はなく、他の開発者から3.2(f)によるアカウント停止の話を次々と聞かされる中、修正が承認されても後からアカウントの不利に働くのではないかと懸念していました。
解決策
投稿時点では、Appleからの回答待ちです。
教訓
提出前に、各言語を読める人に、ローカライズしたキーワード、タイトル、サブタイトルをすべて確認してもらってください。機械翻訳は速いですが、App Reviewはどのロケールの言葉も、あなた自身が選んだものとして審査します。
-
Appプレビューのメタデータ（価格に関する言及） iOSと メタデータとIAPAppプレビューに「無料トライアルあり」と記載されていたため、アップデートが却下された
何が起きたのか
ある個人開発者が、Appプレビュー動画内に「無料トライアルあり」という言葉を含むアップデートを提出しました。Appleは、プレビュー内での「free（無料）」という表現を価格に関する言及とみなし、アップデートを却下しました。開発者は動画を再編集して再提出しました。
解決策
動画は再編集して再提出済み。投稿時点では最終結果は共有されていません。
教訓
アプリのプレビューには、実際にトライアルがある場合でも、価格や「無料」という言葉を入れないでください。トライアル条件はアプリ内のペイウォールに表示してください。
-
ガイドライン 2.5.1 ソフトウェア要件（HealthKit） iOSと 終わりのない審査6日間待機した末、Health同期にApple Healthバッジがなかったため2.5.1でリジェクト
何が起きたのか
インディー開発者が、初めてApple Health同期を追加した大型アップデートを提出しました。6日間「審査待ち」のままでした。その時になって初めて、アカウント内に署名待ちの新しい開発者契約があることに気づきました。署名すると、その日の午後に審査が開始されましたが、両者に関係があるかは分からないとのことです。その後、アプリUIでHealth機能が明確に示されていなかったとして、ガイドライン2.5.1でリジェクトされました。開発者はApple Healthバッジの存在を知りませんでした。
解決策
同期トグルの横に「Works with Apple Health」バッジを追加し、審査用のメモと実機で撮影した画面録画を添付しました。次の提出で承認されました。
教訓
アプリがHealthデータを読み書きするなら、最初の提出からApple HealthバッジをUIにはっきり表示してください。審査が数日止まったままなら、まずApp Store Connectで未署名の契約がないか確認しましょう。
-
ガイドライン1.1 不適切なコンテンツ iOSと 不適切なコンテンツ1年以上リジェクトなしで公開されていたのに、警告なしに1.1で削除された
何が起きたのか
あるインディー開発者のアプリは1年以上App Storeで公開されていました。一度もリジェクトされたことがなく、月額サブスクリプションでささやかな収入も得ていました。そんな中、事前の警告もなく、ガイドライン1.1（不適切なコンテンツ）違反としてストアから削除されたというメッセージがAppleから届きました。
解決策
開発者は再申請しないとAppleに伝え、デベロッパーアカウントを危険にさらしたくないという理由で、アプリもそのニッチ市場もまるごと諦めてしまいました。
教訓
審査履歴がクリーンであっても、後からアプリが削除されるリスクはあります。コンテンツルールは、長期間承認されていたアプリにも適用されるからです。もしあなたのアプリがセンシティブな領域にあるなら、削除通知を受けてからではなく、今すぐガイドライン1.1に照らしてコンテンツやスクリーンショットを見直してください。
-
バグによる却下（ガイドラインの指定なし） iOSと 終わりのない審査100秒のマッチングタイムアウトがバグとして報告され、その後6日間返信を待つことになった事例
何が起きたのか
ある開発者がマルチプレイヤーゲームを提出しました。レビュアーはバグを理由に却下しましたが、実際に起きていたのはクラッシュではありませんでした。対戦相手とのマッチング待ちが100秒経過すると検索が停止する仕様を、レビュアーは「動作不良」と判断したのです。開発者はマッチングの仕組みを説明し、ゲームからタイムアウト処理も削除して返信しました。しかし6日経っても、返事は一件も返ってきませんでした。
解決策
返信で説明し、タイムアウトも削除しました。投稿時点でもまだ回答待ちです。
教訓
レビュアーは一人で、しかも半端な時間帯にプレイすることが多いため、マッチングキューが空になっている可能性が高いです。ボット対戦やデモモードなど、レビューチームが実際にゲームをプレイできる手段を用意し、提出前にレビューノートで説明しておきましょう。
-
メタデータリジェクト（利用規約とプライバシーポリシーのリンク） iOSと メタデータとIAPCode を別のアプリから再利用しており、利用規約とプライバシーポリシーのリンクも古いアプリを指したままだった
何が起きたのか
ある開発者が、以前作成したアプリの一部を再利用して新しいアプリを構築しました。しかし、アプリ内の利用規約とプライバシーポリシーのリンクが古いアプリを指したままだったため、App Reviewでリジェクトされました。開発者によると、リジェクトメッセージには修正すべき箇所が明確に記載されていたとのことです。
解決策
リンクを修正して再提出しました。開発者によると、優先審査（expedited review）は通常1日ほどで結果が返ってくるものの、使いすぎは避けるべきとのことです。
教訓
古いプロジェクトからビルドしたアプリを提出する前に、引き継いでいるリンク、bundle名、法務ページをすべて確認してください。リジェクトのメッセージには修正すべき点が具体的に書かれていることが多いので、しっかり読みましょう。
-
ガイドライン 2.1 情報の不足 iOSと ガイドライン 2.1レポートにバグはなく、ただの「2.1 Information Needed」。89秒の画面録画を添えて回答しました。
何が起きたのか
ある開発者が2つ目のアプリを提出したところ、バグの指摘は一切なく、ガイドライン「2.1 Information Needed」として返ってきました。App Review側は、画面録画に加えて、誰向けのアプリか、どう使われるか、依存している外部サービス、対象地域についての回答を求めていました。開発者はシミュレーターで、起動からメイン機能を一通り使ってペイウォールに至るまでを89秒間録画し、レビューメモの質問すべてに回答して、その日のうちに再提出しました。
解決策
録画と回答は当日送信。最終結果は投稿時点では共有していません。
教訓
新規アプリの場合は、2.1の情報リクエストを想定して準備しておきましょう。最初の審査が質問で止まらないよう、メインフローの短い録画と、対象ユーザー、利用方法、外部サービス、対象地域に関する回答を、提出前にレビューノートへ用意しておいてください。
-
ガイドライン 2.5.4 ソフトウェア要件（バックグラウンドモード） iOSと 終わりのない審査消し忘れたチェックボックス1つ、オーディオのバックグラウンドモードが原因でリジェクト。次のアップデートには10日かかった
何が起きたのか
ある小規模チームが、すでにリリース済みのアプリのアップデートを提出しました。App Reviewは、アプリ内でオーディオのバックグラウンドモードが有効になっていたものの、その機能が不要であるとして、ガイドライン2.5.4に基づきリジェクトしました。チームはその日のうちにバックグラウンドモードを外して再提出し、ロスは約1日で済みました。しかし次のアップデートは審査に約10日かかりました。
解決策
オーディオのバックグラウンドモードを削除し、その日のうちに再申請しました。次のアップデートは審査で約10日間待つことになりました。
教訓
バックグラウンドモードは本来の目的にのみ許可されます。申請のたびに Background Modes のケイパビリティを開き、アプリが実際に使っていないものはすべて外してください。チェックボックスが1つ残っているだけでもリジェクトされますし、次の審査にどれだけかかるかは予測できません。
-
ガイドライン 4.3(a) スパム iOSと ガイドライン 4.3ラッパーに入れたWebアプリが4.3(a) スパムでリジェクトされ、開発者はネイティブアプリとして作り直しました
何が起きたのか
ある開発者が、ネイティブラッパーにWebアプリを組み込んだ形でアプリの初版を申請しました。しかし App Review はガイドライン4.3(a) のスパム規則に基づきこれをリジェクトしました。開発者はAppleの指摘が正しいと認め、アプリを本物のネイティブアプリとして作り直し、バックエンドを自前で運用するリレーサーバーへ移し、ソース code を公開しました。
解決策
セルフホストのリレーサーバーを使い、ネイティブアプリとして再構築しました。再構築版の結果は、その投稿では共有されていませんでした。
教訓
Webサイトを薄くラップしただけのアプリは、App Reviewでスパムと見なされやすいです。App Storeにリリースするなら、ラップしたサイトが通ることを期待するのではなく、初回提出の時点からアプリに本当のネイティブな価値を持たせてください。
-
不適切なコンテンツによるリジェクト（スクリーンショット、続いてサブタイトル） iOSと 不適切なコンテンツ メタデータとIAP成人向け要素が一切ないゲームなのに、スクリーンショットが不適切と判定され、続いてサブタイトルも指摘されたケース
何が起きたのか
ある小規模スタジオは、成人向けテーマやギャンブル、暗号資産を含まないシンプルなストーリーゲームをiOS向けに制作していました。プレイヤーがハリウッドでの成功を目指すセレブを演じるゲームの1本が、スクリーンショットの不適切なコンテンツを理由にリジェクトされました。スクリーンショットには、服を着たゲーム内キャラクターしか写っていませんでした。スタジオはすべてのスクリーンショットを差し替えて再提出。次は、ゲームをセレブの生活とドラマのゲームと説明しただけのサブタイトルが、不適切なコンテンツと判定されてリジェクトされました。レビューには毎回数週間かかりました。
解決策
9月にアプリを初提出しましたが、10月末になってもまだ承認されませんでした。
教訓
App Reviewが理由を明かさずにメタデータを不適切だと指摘した場合は、全部やり直す前に、App Store Connectでどの要素がなぜ問題なのかを具体的に問い合わせてください。再提出の前にはスクリーンショット、サブタイトル、キーワードをまとめて見直しましょう。1つ直すと次が見えてくるからです。
-
ガイドライン 5.2.5 法的事項、知的財産権 iOSと ガイドライン5 Legal メタデータとIAPスクリーンショットに使われていたデバイスがiPhoneに似ていたため、5.2.5でリジェクトされました
何が起きたのか
ある開発者がガイドライン5.2.5でリジェクトされました。App Reviewは、スクリーンショット内の画像がiPhoneに似ており、Apple製品と混同される可能性があるとして、メタデータにその画像が含まれていると指摘しました。表示されていたデバイスはApple製ではなく、Apple製品に似たものだけでした。同じ種類のデバイス画像を使った別のアプリがすでに承認されていたため、開発者は驚きました。
解決策
投稿時点では最終的な結果は共有されていません。返信した別の開発者は、App Reviewはプラットフォームに合わないデバイスフレームや、実際のiPhoneと見た目が異なるレンダリングも問題視することがあると指摘しました。
教訓
1つのアプリの承認は、次のアプリの先例にはなりません。iPhoneに酷似したデバイスのモックアップは、Apple製品と紛らわしいほど類似しているとみなされる可能性があります。デバイスフレームなしのスクリーンショットを使うか、Appleがマーケティング用に提供するデバイスフレームだけを使い、プラットフォームに合っていることを確認してください。
-
ガイドライン 2.1 情報の不足 iOSと ガイドライン 2.1最初のiOSアプリで2.1の情報提供依頼が来て、修正はすべてを見つけやすくすることでした
何が起きたのか
Android版がすでにGoogle Playで公開されている個人開発者が、初めてのiOSアプリを提出しました。アプリにはアプリ内課金が3つとユーザー生成コンテンツ（UGC）がありました。App Reviewは即座にリジェクトしたわけではなく、ガイドライン2.1に基づく情報提供を求めました。開発者は、すべてのアプリ内課金をレビュアーが確認でき、動作する必要があるガイドライン2.1を読み返し、UGC（1.2）とアカウント削除（5.1.1(v)）のルールも確認しました。翌日、開発者は新しいビルドを再提出しました。すべてのユーザーコンテンツに通報・ブロック機能を表示し、投稿前にユーザーが同意するコミュニティルール、サインアウトとアカウント切り替えを用意し、課金・安全ツール・アカウント管理の場所を示す画面録画を添えました。
解決策
リクエストの翌日に新しいビルドを提出。投稿時点では結果は不明。
教訓
レビューは、限られた時間で見知らぬ人と行うユーザビリティテストだと考えましょう。すべての購入、通報・ブロック機能、アカウント管理機能は数秒で見つけられるようにし、レビューノートに添える録画でそれぞれの場所を示すべきです。Google Playで公開済みでも、App Reviewを通過できるとは限りません。
-
ガイドライン 4.3(a) デザイン、スパム iOSと ガイドライン 4.3 終わりのない審査新規アプリが27日間キューに滞留した後、4.3(a) スパムでリジェクト
何が起きたのか
ある開発者が新規アプリを申請し、App Reviewの審査を27日間待ちました。ようやく結果がApp Store Connectに表示されたのは、ガイドライン4.3(a)「Design, Spam」によるリジェクトでした。その後、その開発者は、4.3(a)のリジェクトを乗り越えたことがある人がいるか、他の開発者に尋ねました。
解決策
投稿時点では解決策は共有されていませんでした。その開発者は、4.3(a)を経験した他の開発者からのアドバイスを求めていました。
教訓
審査に時間がかかるからといって、そのアプリが安全である証拠にはなりません。審査待ちがこれほど長いと、数週間後に4.3(a)でリジェクトされると丸一ヶ月が無駄になります。新しいアプリを申請する前に、同カテゴリーの既存アプリと何が違うのかを正直に説明し、審査用メモとメタデータに明確に記載しましょう。
-
ガイドライン 4.3(a) デザイン、スパム macOS ガイドライン 4.3iPhoneアプリはすでに公開中でしたが、Mac版がスパムとしてリジェクトされました
何が起きたのか
ある開発者は、App Storeですでに公開中のiPhoneアプリについて、同じアプリのネイティブデスクトップ版をMac向けに作りました。App Reviewはガイドライン4.3(a)に基づいてMacアプリを却下しました。メッセージには、そのアプリが他の開発者の提出したアプリとバイナリ、メタデータ、コンセプトが似ており、違いはわずかしかないとあり、独自のコンテンツと機能を備えたユニークなアプリを提出するよう促していました。開発者はコミュニティに、4.3に直面した他の開発者にとって何が有効だったかを尋ねました。
解決策
投稿時点では、解決策は共有されていませんでした。
教訓
各プラットフォームは個別に審査され、iPhoneアプリが承認されてもMacには引き継がれません。4.3(a)のメッセージは、あなたのアプリを他の開発者のアプリと比較しています。返信する際は、類似アプリにないことを具体的に説明し、あなたのアプリにしかない機能を挙げてください。
-
終わりのない審査 iOSと 終わりのない審査審査に14日以上かかった末に却下され、再提出後はさらに2週間待ちました
何が起きたのか
ある開発者によると、前回のレビューは14日以上かかって拒否されたそうです。10月21日に再提出したものの、2週間近く経ってもまだ「レビュー待ち」の状態が続いていました。Appleは通常、レビューに24〜48時間かかると述べています。
解決策
投稿時点ではまだレビュー待ちの状態でした。
教訓
平均的なレビュー時間は最悪のケースを反映していません。拒否されると、遅いキューの最後尾に戻ることになります。リリースは数週間の余裕を持って計画し、初回提出をできるだけ完全なものにすることで、拒否による待機時間の二重化を防ぎましょう。
-
アカウント削除要件（ガイドライン 5.1.1(v)） iOSと ガイドライン 5.1.1最初のレビュアーが複数のアカウントを削除したにもかかわらず、アカウント削除機能の欠如を理由に拒否されました
何が起きたのか
公開ユーザー生成コンテンツを軸にしたアプリを開発していた開発者が、アカウント削除機能の欠如を理由に2回目の審査でリジェクトされました。ログを見ると、1回目の審査ではレビュアーが複数のアカウントを問題なく作成・削除していました。開発者は、このリジェクトは機能の欠如よりもカテゴリの厳格さが原因だと感じました。
解決策
投稿時点では、解決策は共有されていませんでした。
教訓
機能が動作していても、レビュアーがすぐに見つけられる必要があります。アカウント削除の導線を審査メモに書き、タップする画面を正確に示して、短い録画も添付しましょう。ユーザー生成コンテンツがあるアプリでは、報告・ブロック・モデレーションも示してください。これらのカテゴリは最も厳しくチェックされるためです。
-
ガイドライン2.1(a) App Completeness macOS ガイドライン 2.1ログインキーチェーンの読み取りで2.1(a)によりリジェクトされたMacアプリ、そして消えた過去のリジェクトメモ
何が起きたのか
ある開発者がMacアプリを提出したところ、アプリがログインキーチェーンから読み取っていたため、ガイドライン2.1(a)に基づきApp Reviewからリジェクトされました。修正はアップデート1回で完了。しかし開発者を面食らわせたのはApp Store Connect自体でした。直近10件の提出分しか表示されないため、古いリジェクトメッセージは履歴から静かに消えていきます。
解決策
修正はアップデート1回で完了。この開発者は今では、すべてのリジェクトメッセージを、それを修正するコミットにコピーしています。
教訓
過去のリジェクト記録としてApp Store Connectに頼らないでください。古い提出分は表示されなくなります。同じ問題が再発したときに正確な文言を確認できるよう、リジェクトの全文を修正内容と一緒に、コミットやチケット、リリースノートに保存しておきましょう。
-
ガイドライン1.4.1 身体的危害（健康および医療） iOSと 終わりのない審査ヘルスケアアプリが審査に10日。その後1.4.1でリジェクトされたが、出典ページを追加して午後のうちに修正完了
何が起きたのか
ヘルスケアアプリを開発していたインディー開発者が、App Storeの審査で10日以上待たされた。結果は、健康・医療アプリを対象とするガイドライン1.4.1によるリジェクトだった。修正は小さく、アプリ内の健康情報の出典を示すページを追加しただけで、作るのに半日しかかからなかった。
解決策
引用付きの出典ページを追加し、半日で完了した。再提出が承認されたかは投稿で明かされていない。
教訓
ヘルスケアアプリにはより高い基準が課され、長く待たされた末に、提出前に満たせたはずの要求が返ってくることがある。健康情報や医療情報を表示するアプリなら、初回提出前にアプリ内へ明確な出典を入れておこう。返信したある開発者は、医師への相談を促す目立つリマインダーもよく求められると指摘していた。
-
In-App Purchaseに審査員がたどり着きにくい（ガイドライン番号は明記なし） iOSと メタデータとIAPペイウォールが奥すぎてリジェクトされたゲームアップデート。アンロックをタイトル画面に移したら、26時間で審査を通過した。
何が起きたのか
あるインディー開発者は、iOSゲームのバージョン1.0が承認されるまでに33日と2回のリジェクトを経験しました。最初のアップデート1.0.1も、ペイウォールがゲームの奥深くにありレビュアーがたどり着けなかったためリジェクトされました。開発者はタイトル画面にアンロックボタンを追加して再提出。今回はプロセス全体で約26時間、実際のレビューは約12分だけでした。
解決策
タイトル画面にアンロックボタンを追加。アップデートは再提出から約26時間後に承認されました。
教訓
レビュアーは、あなたが何を売っているかを見つけるために20分もゲームをプレイしたりしません。すべての購入導線は数秒でたどり着ける場所に置くか、レビューノートに正確な手順を書いて、レビュアーが探し回らずにテストできるようにしましょう。
-
App内課金のメタデータ不一致（ガイドライン番号は明記なし） iOSと メタデータとIAPペイウォールでは「1か月無料」と表示されていたのに、Apple側では年間課金が表示されたためリジェクトされました
何が起きたのか
ある開発者が、TestFlight での数週間のテストから App Store での一般公開へ移行した際、ペイウォールが原因でビルドが 1 件リジェクトされました。ペイウォールには「1 か月無料」とありましたが、Apple の購入画面では同日から年額課金が始まると表示されていました。レビュアーは週次プランも見つけられませんでした。開発者はペイウォールの文言とプランの表示を修正し、別のビルドを提出して、再びレビューを待ちました。
解決策
無料トライアルの文言が購入シートと一致し、週次プランに到達できるようにペイウォールを修正しました。その後、アプリは App Store で公開されました。
教訓
ペイウォールで約束する内容は、トライアル期間や課金開始タイミングを含め、Apple の購入シートに表示される内容と一致させる必要があります。レビュアーがテストに必要なすべてのプランを数タップで到達できる場所に置き、提出前に新規インストールでその導線を確認してください。
-
ガイドライン 2.1「アプリの完全性」（起動時クラッシュ） iOSと ガイドライン 2.1追加のパフォーマンス修正を盛り込んで再提出したビルドが起動時にクラッシュし、丸 1 日を無駄にした
何が起きたのか
最初のApp Store拒否が追加情報の要求だけだった後、開発者はパフォーマンス修正を同じ再提出にまとめました。自信があったあまり、ゲーミング向けデバイス用のハードウェアゲートまで削除しました。ビルドが起動時にクラッシュし、クラッシュログもなく自動メッセージだけだったため、App Reviewは再びビルドを拒否しました。開発者はメモリキルと推測し、ゲートを戻して、パフォーマンスを落とさずにアセットの縮小、読み込みの遅延、リソースの解放に1日を費やしました。
解決策
ハードウェアゲートを戻し、メモリフットプリントを削減し、翌日の3回目の提出に備えました。3回目の最終結果は投稿では共有されていません。
教訓
レビューからの質問に答えるための再提出に、無関係な修正を詰め込まないでください。拒否理由に答える最小限の変更だけを提出し、サポート対象としている最も低スペックなデバイスでも安定性ゲートを維持し、再アップロード前にそのデバイスでコールドスタートを確認してください。
-
ガイドライン4.3(a)「デザインスパム」 iOSと ガイドライン 4.3同時に提出された複数の小規模ゲームがすべて4.3(a)に該当し、その後2件は異議申し立てで覆りました
何が起きたのか
ある開発者が、同じ時期に複数の小型ゲームをApp Storeに提出しました。すべてがスパムと判断され、ガイドライン4.3(a)に基づき拒否されました。その後、プロセスを変更し、現在は一度に1つのゲームのみ提出しています。これらの拒否のうち2件は、App Review Boardへの異議申し立ての結果、覆されました。
解決策
一度に1件の提出に変更しました。4.3(a)による拒否のうち2件は、App Review Boardへの異議申し立てで覆されました。
教訓
類似アプリを同じレビュー期間にまとめると、セット全体がスパム判定される恐れがあります。一度に1つずつ提出し、4.3(a)の拒否が不当だと思ったら、各アプリがどう異なるかを明確に説明してApp Review Boardに異議申し立てをしてください。
-
ガイドライン1.1 安全性、不適切なコンテンツ（アプリのメタデータ） iOSと 不適切なコンテンツ メタデータとIAPあるリカバリーアプリが、マーケティングで支援する習慣の名称を明示したため、ガイドライン1.1に基づき拒否されました
何が起きたのか
ポルノや性欲の克服を支援するアプリが、ガイドライン1.1に基づき拒否されました。App Reviewは、メタデータ（説明、スクリーンショット、キーワード）に問題のあるコンテンツへの言及があると指摘しました。詳細を求めたところ、App Reviewはキーワード「porn」を特定し、これが全てではないと述べ、再提出時は完全な審査が行われること、同じマーケティングやコンセプトで再提出または新規アプリとして提出しても同様の、あるいはより多くの違反が指摘されると警告しました。開発者は、ストアに既に存在する類似アプリが性的誘惑への支援をオープンにマーケティングしていることを指摘しました。
解決策
投稿時点では未解決です。App Reviewは、完全な再審査の前にメタデータから問題のあるコンテンツへの言及をすべて削除するよう求め、開発者は類似アプリが異なる扱いを受ける理由を公に疑問視しました。
教訓
成人向けの習慣をやめることを支援するアプリは、意図ではなく、自らのマーケティングに使われる言葉で判断されます。キーワード、説明、スクリーンショットで悪習の名称を明示するのではなく、「リカバリー」や「自制心」などの目標を説明し、再提出前にApp Reviewに拒否をトリガーした正確な用語を確認してください。次の提出では完全な審査が行われるためです。
-
アプリアイコンが不適切と判定された（ガイドライン番号は明記なし） iOSと 不適切なコンテンツ メタデータとIAP承認済みのアプリアイコンが、肌露出が多すぎるとして却下された
何が起きたのか
あるAIアプリは、クロップトップを着用し胸とお腹の一部が見えるイラストキャラクターをアプリアイコンとして使用していました。同じアイコンは以前App Reviewを通過していました。しかし、後の提出でAppleは胸とお腹の露出が過剰だと判断し却下しました。開発者はキャラクターを両方を覆うフルトップに描き直し、再提出しました。
解決策
アイコンを描き直し、トップで胸とお腹を覆いました。投稿には新しいレビューにどのくらい時間がかかったかは記載されていませんでした。
教訓
以前の承認はアイコンやスクリーンショットを固定しません。各提出は再評価される可能性があるためです。アート内のキャラクターが肌を見せる場合は、より厳格なレビュアーがフラグを立てる可能性を想定し、露出が少ないバリアントを用意しておきましょう。修正が差し替えで済み、再デザインにならなくなります。
-
サブスクリプションのキャンセルフロー（ガイドライン番号は明記なし） iOSと メタデータとIAPキャンセル時の「よろしいですか」確認ステップが追加されていたため拒否。Apple がリテンションメッセージ機能をリリースする1週間前
何が起きたのか
あるサブスクリプションアプリは、ユーザーがキャンセルしようとした際に独自の「よろしいですか」画面を表示していました。App Review はこれを理由にアプリを拒否しました。それから1週間も経たないうちに、App Store Connect はリテンションメッセージ機能を発表しました。この機能により、開発者はサブスクリプションのキャンセルを試みた際に、メッセージ、任意の画像、またはリテンションオファーを表示できるようになります。
解決策
その投稿には、拒否がどのように修正されたかは記載されていませんでした。新しい App Store Connect 機能により、キャンセル時にメッセージを表示するための Apple 承認済みの方法が提供されるようになりました。
教訓
サブスクリプションのキャンセルの前に、独自の摩擦（手間）を設けないでください。ユーザーが直接キャンセルフローに到達できるようにし、最後にユーザーを留めたい場合は、カスタム画面ではなく Apple のリテンションメッセージやオファーを使用してください。
-
ガイドライン5.6「Developer Code of Conduct」および2.5.19「隠し機能」 iOSと ガイドライン5.6「Developer Code of Conduct」 ガイドライン2.5.19「隠し機能」サブスクリプションSDKにバンドルされたチェックアウトcodeが非表示機能と判定され、5.6に基づき拒否されました
何が起きたのか
個人開発者がiOSの目標管理アプリをリリースまでに7回拒否されました。以前の拒否理由の一つは実在のお金への賭けでした。最後の拒否は開発者Codeに基づき、アプリに非表示または誤解を招く機能があると指摘され、どの機能か特定せずにすべて削除するよう求められました。アプリにはリモート機能フラグも、ダウンロードされたcodeも、レビュアー向けの特殊な挙動もありませんでした。推測する代わりに、開発者はリリースバイナリをスキャンし、自分が書いたことのない決済プロバイダーのWebチェックアウトcodeを発見しました。これはそのSDK Webプラットフォーム用のサブスクリプションSDKにバンドルされており、iOSアプリでは一切使用されていませんでした。以前のお金への賭けに関する拒否を踏まえ、開発者はこれが非表示の決済経路のように見えたのではないかと疑いました。
解決策
code を一切変更せずに、開発者は App Review に事実のみで返信しました。アプリが何をするか、しないか、実在のお金がかからないこと、チェックアウトのcodeの出所、未使用のSDK Web codeと未使用の写真ライブラリ権限を次のビルドで削除すること、そして指摘された画面名を特定するよう依頼しました。約9時間後、App Review は審査を継続すると通知し、アプリは公開されました。
教訓
App Review はビルドの内容を評価し、あなたが何と呼ぶかは気にしません。SDK が他のプラットフォーム用に含めるcodeも含め、バイナリに何が同梱されているかを把握してください。5.6で拒否された後、推測して再提出しないでください。具体的かつ冷静に返信し、どの画面や動作が指摘されたのかを問いましょう。
-
ガイドライン 2.3.4 正確なメタデータ（App Previews） iOSと メタデータとIAP10月に審査を通過した App Preview が、1ヶ月後に 2.3.4 の枠組みに関する理由で拒否された
何が起きたのか
ある開発者が iOS アプリのアップデートを提出し、ガイドライン 2.3.4 に基づいて拒否されました。App Review は、App Preview ビデオに画面キャプチャの周囲に枠があるとして拒否しました。同じビデオは前月に審査を通過していました。開発者は、ストア内の他のアプリ（アプリ自体の映像がほとんどない、または全くない App Preview を使用している、アプリではなく人物を表示する有名なアプリを含む）を指摘しました。
解決策
開発者はApp Previewの動画を完全に削除し、アップデートを再提出しました。投稿には、新しい審査の結果については記載されていませんでした。
教訓
一度承認されたApp Previewでも、後続のアップデートで拒否される可能性があります。すべての提出物は再審査されるためです。プレビューは装飾的なフレームなしのアプリのスクリーンショットに留め、フラグが立てられた場合は、再作成中にアップデートをブロック解除する最速の方法として削除することをお勧めします。
-
第3.2(f)条（Developer Program License Agreement） macOS アカウント終了 終わりのない審査アイコンの問題を修正したmacOSのアップデートが約45日間審査待ちとなり、その後3.2(f)の通知が届いた
何が起きたのか
独立系開発者のmacOSアプリは、ブランディングに関する懸念からApp Reviewでフラグが立てられていました。2026年9月15日、フィードバックに対応したアップデート（完全なアイコンの再デザインを含む）を提出しました。その後、約45日間審査待ちのまま決定がなく、開発者は公式チャネルを通じて2回の優先審査を依頼しました。2026年10月30日、修正済みアップデートがまだ待機中である間に、セクション3.2(f)に基づき「開発者アカウント停止保留通知」が届きました。
解決策
投稿時点で異議申し立ては係争中でした。開発者は正式な異議申し立てを行い、Developer Supportにも別途連絡しましたが、実質的な回答は得られていませんでした。
教訓
キューで待機中の修正は、過去の提出物に対する措置を止めません。すべての拒否、それに応じた変更、優先処理の依頼を日付付きで記録し、異議申し立てで何をいつ修正したかを正確に示せるようにしてください。
-
ガイドライン 3.2.2 不適切なビジネスモデル iOSと ガイドライン 3.2.2有料のステップチャレンジアプリが 3.2.2 で拒否され、App Review との通話でモデル全体が不可と確認された
何が起きたのか
すでに数千人のユーザーを持つフィットネスアプリを運営していたチームが、有料のステップチャレンジを軸にした2つ目の iOS アプリを開発しました。ユーザーはウォーキングチャレンジへの参加料を支払い、これはストアに既にある複数のフィットネスアプリと同じ基本モデルです。App Review はガイドライン 3.2.2 に基づきこれを拒否しました。説明では、ペナルティベースのモデルは、チャレンジ開始前に支払う場合でも目標未達後に請求される場合でも許可されないとされました。チームは App Review チームと面談して変更点を尋ねましたが、特定の画面やフローのステップではなく、コンセプト自体が許可されないと言われました。
解決策
チームは、開発者アカウントにリスクを負いたくないため、異議申し立てを行わなかった。投稿時点ではアプリはストアには掲載されておらず、同じモデルのアプリがなぜ今もライブなのか、彼ら自身も理解できていない。
教訓
すでにストアにある類似アプリは、App Review が受け入れる前例にはならない。なぜなら、あなたのビルドは、ガイドラインが「今日」どのように解釈されるかに対して評価されるからだ。ユーザーが目標を達成したかどうかで金銭のやり取りが発生するモデルの場合は、製品全体をそのモデルに依存させる前に、例えば App Review に直接質問するなどして、3.2.2 に対して確認すること。
-
ガイドライン5.6「Developer Code of Conduct」 iOSと ガイドライン5.6「Developer Code of Conduct」隠された機能により 5.6 で拒否されたアップデートは、約3週間かかった2回目のレビューでも、まったく同じ拒否理由で却下された
何が起きたのか
ある開発者がiOSアプリのアップデートを提出したところ、開発者Code（行動規範）に違反したとして拒否されました。通知には、App Reviewが不正行為と関連する異常な行動パターンを確認したとあり、具体的にはレビュー中に意図的に隠蔽されたように見える機能が含まれていると記載されていました。開発者はアプリ内に隠されたものはないと主張し、トリックや誤解を招くような挙動も使用していないと説明しました。アプリの正確な動作を説明した上で再提出し、2回目のレビューを約3週間待ちました。しかし、前回と全く同じ理由で拒否され、特定の機能や画面が指摘されることはありませんでした。
解決策
投稿時点では未解決です。開発者は異議申し立てを行う予定だと述べています。
教訓
特定の機能を特定しない一般的な5.6の拒否通知は、同じビルドに説明を加えても通ることが稀です。スレッド内でApp Reviewにどの画面や挙動がフラグされたかを確認し、バイナリに含まれるすべてのSDKが何を配信しているかを確認してください。返信が進展しない場合は、正式な異議申し立てを利用してください。
-
ガイドライン 4.3(a) スパム iOSと ガイドライン 4.3インディーシリーズの新作ゲームが、開発者自身の過去のゲームと酷似しているとして4.3(a)に基づき拒否されました
何が起きたのか
あるインディペンデント開発者が、自らのシリーズの新作ゲームのiOSリリースを準備中でした。同時に、より多くの言語への翻訳も進めていました。App Reviewは、ガイドライン4.3(a)に基づき、iOS版がスパム（開発者の過去のゲームと酷似している）として却下しました。開発者はコアとなるバトルシステムを大幅に作り直していましたが、シリーズから引き継いだ基本インターフェース、アイコン、ロゴなどが以前のタイトルと非常に似通っていることを認めていました。App Reviewからは標準的な却下メッセージのみが届き、詳細な説明を求めた1週間後にもなお返信はありませんでした。
解決策
投稿時点では未解決です。開発者はApp Reviewに対し、新作ゲームが以前のタイトルとどのように異なるかを説明しており、iOS版がいつ、あるいはリリースされるかどうかは判断できないと述べていました。
教訓
4.3(a)では、ご自身のバックカタログが比較対象となります。そのため、ゲームプレイが変わっていても、以前のゲームのインターフェース、アイコン、ブランディングを再利用した続編は重複とみなされる可能性があります。ビルドとスクリーンショットで新しい部分を明確にし、提出前にレビュアー向けのメモにそれらをリストアップしてください。
-
ガイドライン5.2.5および2.3.10 iOSと ガイドライン5 Legal ガイドライン 2.3.10ストア用スクリーンショット作成アプリが、自社のアイコンにApp Storeロゴを使用していたため却下された事例
何が起きたのか
ある開発者が、App StoreとGoogle Playの両方用のスクリーンショット作成を支援するアプリを構築しました。最初のiOSビルドは、2つのガイドラインに抵触して却下されました。5.2.5では、アプリのアイコンにApp StoreのロゴとGoogle Playのロゴが並んで表示されており、リストのサブタイトルが「App Store」の文字で始まっていました。2.3.10では、iOSビルド自体（バイナリ、アイコン、スクリーンショット）にGoogle Playが含まれていました。開発者は数週間毎日そのアイコンを見ていたのに、問題に気づきませんでした。
解決策
開発者はアイコンを描き直し、サブタイトルを書き換えました。さらに、iOS版ではオンボーディングからエクスポート、設定やエラーメッセージに至るまで、Google Playの表示をすべて非表示にするスイッチを1つ追加しました。保存済みのプロジェクトには影響を与えず、Androidでは両方のストアを維持します。変更点はレビューノートに1行で説明しました。投稿時点で、2回目のビルドは少なくとも3日間レビュー待ちの状態でした。
教訓
Appleは、画面と同様に厳格にアイコンとサブタイトルを審査します。アプリがアプリストアに関するものであっても、アイコンやリストにAppleのマークを含めず、iOSビルドやスクリーンショットのどこにも他のストア名が表示されないことを確認してください。
-
In app purchase failure（ガイドライン未記載） iOSと メタデータとIAP 終わりのない審査リリース日発表から3日後、レビュアーがオフライン状態で購入に失敗したため、ゲームが拒否されました
何が起きたのか
インディー開発者はゲームのリリース日をすでに発表していました。ビルドはレビューに1週間弱かかり、急ぎのレビューを依頼して初めて進みました。最終的に、発表日から3日後に拒否されました。拒否に添付されたスクリーンショットから、レビュアーはアプリ内購入を試みた際にインターネット接続がなかったことがわかります。アプリは購入失敗のエラーを表示していましたが、メッセージは曖昧でした。
解決策
開発者は異議申し立てましたが、約1ヶ月経っても回答はありませんでした。その間、インターフェースを再設計し、何が問題だったかをより明確に説明するようエラーメッセージを書き直し、改善版の再提出を計画しました。
教訓
レビュアーもネットワーク不良に遭遇することがあります。接続なし、およびストアリクエスト失敗時の購入をすべてテストし、アプリが明確なメッセージと再試行手段を表示することを確認してください。ビルドが承認される前にローンチ日を発表することは避けてください。
-
クラッシュ、サブスクリプション、EULA、ペイウォールによる拒否（ガイドライン番号は記載なし） iOSと ガイドライン 2.1 ガイドライン 3.1.2 終わりのない審査最初のiOSアプリは37日と4回のリジェクトを経て、各審査で新たな問題が発覚した
何が起きたのか
ある開発者が10月1日に、サブスクリプションを販売する初のiOSアプリを提出した。8日後にクラッシュでリジェクトされた。翌日再提出したが、約2週間後にサブスクリプションの問題でリジェクトされた。次の再提出は2日後にEULAの問題でリジェクトされた。11月5日の4回目のリジェクトは、ペイウォールのリンクとプレビューに関するものだった。どの回も、以前の審査では指摘されなかった問題が浮き彫りになった。
解決策
11月7日、初回提出から37日後に承認された。開発者はリリースを喜んだが、インディー開発者にとって審査はもっと速く、透明性が高まるべきだと述べた。
教訓
リジェクト通知には、ビルド内のすべての問題が必ずしも列挙されない。初回提出前に、実機での起動確認、サブスクリプションの詳細、利用規約（EULA）リンク、ペイウォールリンクをまとめてチェックしておこう。追加の審査ラウンドは1週間以上かかる可能性があるため。
今後のバッチに寄稿する
ストーリーを追加するには、下記に新しいファイルを置き、 apps/web/src/data/app-store-refusal-stories/stories
既存のパターンに従ってプルリクエストを作成してください。投稿は匿名にしてください。
このページは法的助言ではなく、次回の申請におけるAppleの判断を予測するものでもありません。