匿名化済みアーカイブ
App Storeの審査がチームに与える真のコスト
公開されている開発者の投稿から、51件の拒絶事例をリライトしました。名前、アプリ名、ソースへのリンクは一切含まず、コンテキスト、判明している結果、そして教訓のみをまとめています。
Batch 1 · 44 stories · 2026-10-19更新
- 事例集
- 51
- ガイドライン
- 15
- バッチ
- 1
全51件のストーリーを表示中。
-
4.3(a) スパム iOS ガイドライン 4.3ポートフォリオ全体が一斉にフラグされた
何が起きたのか
同じスタータープロジェクトから複数のアプリを構築した開発者が、すべてのアプリで同一の4.3通知を受け取りました。アプリ間ではバイナリ、メタデータ、コンセプトが似通っており、違いはわずかでした。開発者はアプリを1本ずつ対応していくことにしました。
解決
投稿時点ではまだ進行中。
教訓
4.3(a)は自社アプリ間の重複も対象となります。一つのテンプレートから複数のアプリを展開する場合、単にアイコンや名前を変えるだけでなく、それぞれが明確に異なるコア機能を持つ必要があります。
-
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回につき約1ヶ月かかっており、審査期間の長期化が新規アプリを排除する手段になっているのではないかと疑っていました。
解決
投稿時もまだ審査中でした。
教訓
リジェクト後の次の審査サイクルは、初回よりも大幅に遅くなることがあります。再提出の際は、再度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によるリジェクト
何が起きたのか
数ヶ月にわたる迅速なリリースと好意的なユーザーフィードバックを経て、あるスタートアップのアプリが晩秋にリジェクトされました。理由は、アプリやウェブサイトを横断したトラッキングにユーザーの許可を求めるiOSのプライバシー規則、App Tracking Transparencyに抵触したためです。創業者は後に、このリジェクトが会社全体を危機に陥れたと語っています。
解決
投稿内には記載なし
教訓
提出前に、アプリ内のすべての SDK がトラッキングを行っていないか監査してください。サードパーティ製ライブラリによるものであっても、ユーザーデータと他社のデータを紐付けるものがあれば、トラッキング許可のpromptと、それに対応するプライバシーラベルが必要です。
-
ログイン（ガイドライン番号の記載なし） iOS ログインレビュアーがAppleまたはGoogleでサインインできなかった
何が起きたのか
ボットによる登録を防ぐため、開発者はメールアドレスとパスワードによるログインを廃止し、Sign in with AppleとGoogleのみに絞りました。自身のiPhoneやiPad、さらには別の理由で却下した前回のレビュアーでも動作していました。しかし、次のレビュアーはログインできなかったという理由でアプリを却下しました。
解決
記載なし
教訓
ソーシャルログインのみを提供している場合でも、レビュアーが詰まってしまう可能性があります。レビュー用のメモにデモアカウントやレビュー専用ログインなどの有効な手段を記載し、提出前には必ず新しいデバイスとアカウントでサインインのテストを行ってください。
-
シミュレーションギャンブル（ガイドライン番号の記載なし） iOS シミュレーションギャンブル個人アカウントにおけるゲーム内ステーキング機能
何が起きたのか
シミュレーションギャンブルが含まれているとして、あるゲームがリジェクトされました。プレイヤー同士でゲーム内アイテムを賭ける仕組みがありましたが、これは古典的なオンラインRPGでは一般的なメカニズムです。開発者が法人ではなく個人アカウントで公開していたため、一旦この機能を削除することにしました。
解決
機能を削除して再申請。
教訓
ギャンブル形式のメカニズムは、たとえリアルマネーを伴わなくても厳格に審査されます。Appleが許可するかどうかは、アカウントの種類や提出書類にも左右されます。ステーキング、ルート、賭けなどの機能を実装する前に、ギャンブルに関するルールを確認し、それに基づいたデベロッパーアカウントの種類を計画してください。
-
偽造書類の疑い（ガイドライン番号の記載なし） iOS 偽造書類ユーザーの悪用を理由に却下されたPDFエディタ
何が起きたのか
あるPDFエディタアプリが、偽造IDや偽造書類の作成を可能にするとしてAppleにリジェクトされました。開発者は、同じ論理であれば、悪意のあるユーザーがどのように利用するかを理由に、あらゆる銀行アプリやメッセージングアプリもリジェクトされ得ると反論しました。
解決
記載なし
教訓
汎用ツールは、最悪の利用ケースに基づいて判断されることがあります。公式の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）の両方で、まずアカウント作成を強制していました。
解決
アカウントなしで購入しても、後から任意でサインアップした際に購入情報を引き継げるよう再構築中です。投稿時点では作業中。
教訓
有料機能がデバイス上で動作し、サーバー側の認証を必要としない場合は、アカウントなしで購入・復元できるようにしましょう。サインアップは、クラウドバックアップなど、本当に必要な機能にのみ限定すべきです。
-
ガイドライン 1.4.2 身体的危害 iOS ガイドライン 1.4.2公開中の投与量計算アプリ、規制強化で削除
何が起きたのか
ある開発者が朝起きると、どちらも審査中でもないのに、2つのアプリがガイドライン 1.4.2 に抵触しているとの通知を受け取っていました。どちらもすでに公開済みでした。一つは単体のペプチド投与量計算アプリ、もう一つはその計算機能が組み込まれたトラッカーアプリで、この2つが開発者にとって初めての本格的な収益の成功となっていました。同じ分野の他の開発者も、同時期に同じ通知が届いたと報告しています。通知によると、ペプチドの投与量や再構成を含む薬剤の投与量を計算するアプリは、製薬会社、または病院、保険会社、薬局、大学などの公認機関が公開しなければならないとのことでした。
解決
なし。開発者は安全上の懸念を理解しており、これらのアプリは終わりだと受け止めていました。
教訓
承認は永続的なものではありません。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 に違反している」という警告を受け取りました。通知は過剰な返金リクエストと顧客からの苦情を指摘し、アカウントが停止される可能性があると警告したうえで、収益の支払いをすべて停止し、アプリの移管も無効にしたと伝えていました。返金率は過去2ヶ月でほぼ倍増していました。開発者がデータを調べたところ、返金リクエストのほとんどは「意図しない購入」とされており、主な原因は3日間の無料トライアルが年間プランへ自動移行するのを忘れたユーザーだと考えられました。この警告は、アプリの大規模なリデザインがすでにテスト段階に入っている最中に届きました。
解決
本記事の投稿時点でも未解決のまま。開発者はトライアル期間中のリマインダーを増やし、次回の課金をより分かりやすく表示し、アプリ内でサブスクリプションを管理・解約できる機能を追加し、テストを重ねてリデザインを完了させました。また、状況を見守る間、有料のクリエイターマーケティングはすべて停止しました。
教訓
Appleはバイナリだけでなく、返金率や苦情もチェックしています。無料トライアルがいつの間にか年額課金に切り替わるような仕組みは、規模が大きくなると意図しない購入トラブルに発展しかねません。トライアル終了前に通知を送り、実際の価格を明示し、解約を容易にしましょう。返金率の上昇は、Appleに指摘されるずっと前からアカウントのリスクとして捉えるべきです。
-
メタデータとアプリ内課金の設定 iOS メタデータとIAPコンソールから削除できない画像のせいで3回リジェクトされる
何が起きたのか
ある開発者がApp Store Connectのサブスクリプションにプロモーション画像を追加した際、誤って同じ画像を2回追加してしまいました。その後、その画像が削除も置換もできなくなり、試行するたびに「後でもう一度お試しください」という汎用的なエラーが発生しました。このサブスクリプション設定が原因で、アプリは3回リジェクトされました。開発者は毎回、削除の試行とエラーの内容を画面録画して返信しましたが、レビュアーには無視されているように感じられました。開発者は、App Store Connect自体のバグが根本的な原因だと考えています。
解決
投稿時もまだ解決しておらず、Appleからの修正も入っていない状態。
教訓
App Store Connect自体が修正をブロックしてしまうと、リジェクトのスレッドで返信しても解決できる担当者に届かないことがあります。サブスクリプション画像は慎重に、一度だけuploadするようにしてください。もしコンソールが壊れた場合は、App Reviewへの返信と並行して、Apple Developer Supportへ別途バグとして報告しましょう。
-
ガイドライン 4.3 Spam iOS ガイドライン 4.3一つのジム運営のために開発されたアプリが、3度のリジェクトを受ける
何が起きたのか
ある開発者が、自身のジムを運営するためにiOSアプリを開発しました。約176回のコミットを重ねた成果です。Appleは9月29日にリジェクト、10月7日に再度リジェクト、そして10月13日にはガイドライン4.3のSpamとしてリジェクトしました。同日、彼らはApp Reviewからの9つの質問すべてに回答しましたが、6日後の10月19日になっても何の返答もありませんでした。App Store Connectのアプリ一覧を見ると、同じアカウント内の他のアプリも、iOSとmacOSの両方で同時にリジェクト状態になっていました。
解決
投稿時点でも未解決。回答を送信した後、App Reviewからの返信は途絶えたまま。
教訓
4.3の審査基準は、開発の労力やコミット数で決まるものではありません。特定の企業向けに開発されたアプリであれば、検索結果には表示させず、直接リンクを知っているユーザーのみがアクセスできる「非公開（Unlisted）」設定が可能です。また、Custom App配布を利用すれば、特定の組織のみに利用を制限できます。要件に合ったアクセス制御を選択してください。一般公開する場合は、既存のアプリと何が違うのかを、最初の画面やスクリーンショット、審査用メモで明確に伝えることが重要です。
-
ガイドライン 5.6 開発者の Code に関する行動規範、および 2.5.19 隠し機能 iOS ガイドライン 5.6 開発者 Code 行動規範 ガイドライン 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のノートに記載しましょう。
-
2.1 情報不足 iOS ガイドライン 2.1アプリの対象ユーザーが特定されるまで、審査が一時停止
何が起きたのか
ある開発者がiPadアプリのバージョン1.0を提出したところ、ガイドライン2.1「情報の不足」により審査が止まってしまいました。クラッシュ報告も、機能の不具合も、バイナリの修正要求もありませんでした。Appleが審査を再開する前に求めたのは、たった一つの質問に対する詳細な回答でした。それは、「このアプリは誰が使うのか」という点です。
解決
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日経過しても解消せず、顧客への提供を優先するためにメインリリースからその権限を削除せざるを得ませんでした。
解決
権限の削除、新しいデモ動画の作成、ストア掲載情報の書き換えを経て、ようやく承認されました。
教訓
権限のスコープは、まずリリース可能な最小限の範囲に絞りましょう。たった一つの権限が、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.1App Store外での支払いに該当する「APIキーの持ち込み」
何が起きたのか
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点でした。1つ目は、週払い・月払い・年払いのサブスクリプションを提供しているため、App Storeのページに利用規約への有効なリンクを設置すること。2つ目は、キッズカテゴリのアプリであるため、サードパーティ製アナリティクス、サードパーティ広告、第三者とのデータ共有の有無とその保存場所、およびその他のユーザー・デバイスデータの収集内容と目的に関する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に対し、個別での電話相談を依頼しましたが、返信はなく、4.3によるリジェクトから約2週間後にようやく電話が行われました。開発者の印象では、現在 4.3 は、低品質なAI生成クローンに見えるアプリをフラグ立てするために使われており、自身のアプリはそれに該当しないと主張しています。
解決
開発者は異議申し立てを行いました。執筆時点では、まだ審査待ちの状態です。
教訓
競合の多いカテゴリーでは、レビュアーはスクリーンショット、説明文、そして初回のセッション内容で判断します。既存アプリとの違いを明確にし、App Reviewへの電話リクエストは早めに行いましょう。電話の調整には1週間以上かかることもあるためです。
-
規約未同意（ガイドラインの記載なし） iOS 登録とアカウント審査待ちで1週間、未署名の規約により却下、さらにまた1週間
何が起きたのか
あるアプリが約1週間の審査を経て、アプリ内に何の問題もないにもかかわらず却下されました。原因は、App Store Connectで新しく公開された規約にアカウントが同意していなかったことでした。開発者が同意して再提出したものの、再び審査待ちの列に並び、さらに約1週間を要しました。デベロッパーサポートからは「すべて順調に進んでいます」という返答のみでした。
解決
執筆時点でも、まだ審査待ちの状態です。
教訓
提出前には必ずApp Store Connectを確認し、同意待ちの規約がないかチェックしてください。たった一度のクリック漏れが、審査待ちのプロセスを最初からやり直すことになりかねません。
-
審査中のクラッシュ（ガイドラインの記載なし） macOS ガイドライン 2.1開発者がインストールしていないmacOSバージョンでのクラッシュによりリジェクト
何が起きたのか
あるMacアプリが、開発者がまだ使用しておらずメインマシンへのインストールも望んでいなかったmacOS 27でクラッシュしたため、リジェクトされました。クラッシュの再現方法を探していた開発者は、AppleのVirtualization frameworkを使えばApple silicon上でmacOSの仮想マシンを無料で実行できることを発見し、新しいバージョンでのテスト用に環境を構築しました。
解決
仮想マシンでクラッシュを再現すること以外、詳細は不明。
教訓
App Reviewは最新のOSでテストを行います。メインのマシンをアップグレードせずに審査中のクラッシュを再現できるよう、最新のmacOSを搭載した仮想マシンを常に用意しておきましょう。
-
審査の遅延（ガイドラインの指摘なし） iOS 終わりのない審査2度の緊急審査リクエスト後、12日間「Waiting for Review」が継続
何が起きたのか
すでにApp Storeでのアプリ承認実績がある開発者が、5つのサブスクリプションを含む新アプリのバージョン1.0を提出しました。通常は48時間以内に完了するはずですが、12日経っても「Waiting for 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同一分内に7つのテンプレートアプリが4.3でリジェクト
何が起きたのか
ある小規模チームが、同じテンプレートで構築した7つのアプリを1週間のうちに審査へ提出しました。すると、過去に一度もリジェクトされたことがない2つのアプリを含め、7つすべてが全く同じタイミングで4.3(a)のスパムとしてリジェクトされました。チームは、Appleが個々のアプリではなく、一括提出されたバッチ全体を判断したと結論付けました。
解決
現在、このチームはアプリを一度に1つずつ提出しています。
教訓
codebaseを共有するアプリは、同時に提出するとスパムパターンと見なされる可能性があります。提出の間隔を空け、機能、デザイン、メタデータにおいて各アプリを明確に差別化してください。
次回の投稿に参加する
ストーリーを追加するには、以下に新しいファイルを配置し、 apps/web/src/data/app-store-refusal-stories/stories
既存のパターンに従ってプルリクエストを作成してください。投稿は匿名に保たれます。
このページは法的助言を目的としたものではなく、次回の申請時にAppleがどのような判断を下すかを予測するものでもありません。