App Store の審査時間：実際の判定64件、中央値73時間

要点：私の開発者アカウントがこれまでに受け取った App Review の判定メールをすべて集めました。iPhone アプリ21本に対する64件の判定で、期間は2026年9月10日から10月12日。どれにも Apple 自身の「Submitted」タイムスタンプと、判定が届いた時刻が付いています。待ち時間の中央値は 73時間でした。Apple のページには 「提出の少なくとも50%を24時間未満で、90%を48時間未満で審査する」と書かれています。私の場合は 24時間以内が19%、48時間以内が27%。すでにストアにあるアプリのアップデートは中央値 64時間、App 内課金だけの提出は 12時間で、新規アプリ21本のうち最初の提出で承認されたものは0本でした。

検索で来た方のために、短い答えから。2026年にローンチを計画しているなら、アップデートは審査1ラウンドあたり3日、まったく新しいアプリの承認には2〜5日、そして新しいアカウントの新規アプリなら少なくとももう1ラウンドを見込んでください。最初の提出はたいてい質問付きで戻ってくるからです。1週間止まったままの審査は「遅い承認」ではありません。私のデータでは、5.1日を超えた待ちは1件を除いてすべて Guideline 4.3 のスパムとしてリジェクトされました。

まだ「いくらかかるのか」を考えている段階なら、無料の iPhone アプリ開発費計算ツールで機能を時間と金額に換算できます。この記事が扱うのは、どの計算ツールにも出てこない部分、つまり「Submit」から「Ready for Distribution」までのカレンダー上の時間です。私はこれらのアプリを Mac なしの Windows PC で作っています（パイプラインはこちら）。そのため、以下の提出はすべて CI ジョブか App Store Connect のウェブサイトから行い、Xcode は一度も使っていません。

2026年、App Store の審査にはどれくらいかかるのか

実際に遭遇するケースに分けて数字を示します。「待ち時間」は、Apple のメールにある「Submitted」の行から判定メールが届いた瞬間までの時間です。つまり審査担当者がアプリを触っていた数分だけでなく、キューで待っていた時間も含みます。

提出したもの	判定数	待ち時間の中央値	最速	最遅	承認
App 内課金のみ	5	12.2 時間	11.7 時間	13.4 時間	5件中5件
公開中アプリのアップデート	16	64.4 時間	6.3 時間	203.6 時間	16件中11件
新規アプリ（通常のラウンド）	21	51.2 時間	3.1 時間	120.5 時間	21件中8件
新規アプリ（4.3 スパムの2回の一括判定）	22	187.8 時間	167.7 時間	223.3 時間	22件中0件
全体	64	73.1 時間	3.1 時間	223.3 時間	64件中24件

目を引く点が2つあります。新規アプリへのリジェクトや質問は早く返ってきます（通常の13件は中央値27.8時間）。審査担当者は最初の問題で止まるからです。承認のほうが時間がかかります。初回バージョンの承認8件は中央値 69.9時間で、48時間以内に戻ってきたものは1件もありません。つまり統計的には、早い返事は悪い知らせです。

実験：メール1通につきタイムスタンプ1組

App Store Connect は審査にかかった時間の履歴を見せてくれません。でも受信箱にはあります。Apple から届く判定はどれも同じ形をしています。件名は「Review of your App (iOS) submission is complete.」か「There's an issue with your App (iOS) submission.」のどちらかで、本文には Submitted: Oct 08, 2026 at 03:48 PM Pacific Daylight Time のような行があります。メール自体の送信時刻が判定時刻です。データセットはこれで全部です。

2026年10月17日、Gmail で検索演算子を使ったクエリ from:no_reply@email.apple.com newer_than:60d を1回だけ実行しました。69スレッドが返り、そのうち64件が判定です（残り5件は App Store Connect の歓迎メール、API アクセスの承認、「Welcome to the App Store」の案内2通、「Thank you for submitting」1通）。アカウントを開設したのは9月10日なので、これはサンプルではなく全履歴です。続いてパースします。

# media/deepdive/review-time/analyze.py (trimmed)
PT = timezone(timedelta(hours=-7))  # Pacific Daylight Time, as printed in Apple's emails

def sub_dt(s):  # "Oct 08 03:48 PM" from the email body
    return datetime.strptime("2026 " + s, "%Y %b %d %I:%M %p").replace(tzinfo=PT)

for e, app, out, sub, by, kind in ROWS:
    s = sub_dt(sub); d = utc(e)          # e = the email's sent time, UTC
    h = (d - s).total_seconds() / 3600   # hours from Submitted to decision
    recs.append(dict(app=app, outcome=out, kind=kind, hours=round(h, 2), ...))

各行には、提出の中身によるタグも付けています。新規アプリの初回バージョン、アップデート、App 内課金のみ、の3種類です。これはアプリ自体の記録（リポジトリのコミット履歴と私のメモ）から判断し、あいまいな一括提出はメール本文と突き合わせました。本文には提出項目が載っています。たとえば Chain の10月8日夜の提出には In-App Purchases (6) とだけあり、アプリのバージョンは含まれていません。リジェクトの理由はメールにはまったく書かれていない（本文は「We noticed an issue」だけ）ので、保存しておいた Resolution Center の文面と、私が送った返信から拾いました。

この方法で見えないもの：判定前に私がキャンセルした提出（メールがないので行もない）と、審査担当者がアプリを開いた正確な瞬間です。「待ち時間」ではなく「審査中の時間」を知りたいなら、App Store Connect API でバージョンの状態は取れますが、履歴は取れないので、自分でポーリングする必要があります。

Apple の「24時間」と私の数字

Apple の言い回しは慎重です。提出の半数を24時間未満で「審査する」と言っています。それが事実であっても、体感とは一致しないことがあります。理由は3つあり、どれも私のデータに表れています。

1つ目、時計はキューの中で動き始めます。私の承認はほぼ同じ経過時間に固まっています。アップデート16件のうち7件は63.5〜64.5時間で戻ってきました。9月26日土曜日の朝にまとめて提出し、太平洋時間の月曜深夜に32分以内でまとめて判定されたからです。審査そのものにどれだけかかったにせよ、待ち時間を決めたのはキューがそこに到達したタイミングでした。

2つ目、Apple は土曜日には新しい判定を出していないようです。少なくとも私の分については。64件の判定を太平洋時間で見ると、月曜35、金曜10、木曜7、水曜5、日曜4、火曜3、土曜 0。月曜が多いのはスパムの一括判定2回（22件）のせいですが、それを除いても土曜日に届いたものはありません。つまり App Review は日曜日には動いています（日曜の判定4件のうち2件は承認）が、土曜朝の提出はやはり月曜の夜まで待たされました。

3つ目、遅い裾野はランダムではありません。4.3 の一括判定2回を除くと、私の数字は Apple の数字にかなり近づきます。24時間以内が29%、48時間以内が40%です。スパム判定によるリジェクト22件は、それぞれ7〜9.3日かかりました。長い待ちは不運ではなく、シグナルだったのです。

速いレーンは App 内課金です。App 内課金だけの提出5件（公開中の5本のアプリ向けの新しいテーマとパック、10月8日木曜日の深夜に API 経由で送信）は、すべて11.7〜13.4時間後に、互いに95分以内の間隔で承認されて戻ってきました。新しい価格設定やパックを急いで出したいなら、バイナリには手を付けず、単独の提出として出しましょう。

新規アプリ：21本中0本が初回で承認

21本のアプリはどれも、最初の提出が差し戻されました。驚くような話に聞こえますが、理由を読めば印象は変わります。初回ラウンドのメール21通のうち10通は Guideline 2.1 の「Information Needed（情報が必要）」でした（残り11通は後述のスパムの一括判定）。新しい開発者アカウントが受ける定番の質問です。実機でのアプリの画面収録を送る、主な機能を説明する、ログインが必要かどうかを伝える、外部サービスを列挙する。Apple のガイドラインはこれを最初から求めていますが、アカウントが新しいと審査担当者はそれでも改めて聞いてきます。

効果があった対策は、審査メモを形式的なものとして扱うのをやめることでした。今ではどのアプリにも Store/review-notes.md があり、パイプラインがそれを App Store Connect の審査情報に送り込みます。審査担当者が1分以内にたどれる手順書として書き、有料画面すべてへのたどり着き方も含めています。

# chain/Store/review-notes.md (trimmed)
No account, login or network connection is required.

IN-APP PURCHASES (StoreKit 2, all optional, Restore in Settings):
- Chain Unlimited (existing non-consumable): add three habits, tap New habit again; ...
- Streak Repair, $0.99 consumable: when a chain of 2+ days breaks, Today shows a
  "chain broke" banner and the rescue sheet opens. ... To see it on a fresh install:
  add a habit, open Week, tick the two days before yesterday, leave yesterday empty,
  then relaunch.

PRIVACY: no data is collected. No accounts, analytics, ads or third-party SDKs.

最初の 2.1 ラウンドのあと、Chain、Ironbook、Quiver を9月22日の太平洋時間午前4時21分に回答と画面収録を付けて再提出したところ、3本とも51〜67時間後に承認されました。ストアに出られた8本について、最初の提出から最初の承認までの時間の中央値は 4.4日（範囲は3.75〜7.2日）です。新しいアカウントの新規アプリのローンチ計画に書くべき正直な数字は、24時間ではなく、平日1週間に近い値です。

初回ラウンドのその他の理由も知っておく価値があります。どれも安く防げるからです。

• 5.1.1 プライバシー、同じアプリで2回。Minder は、アニメの目が顔を追いかけることもできる集中タイマーです（目のアニメーションはこの SwiftUI の記事で紹介しています）。顔のデータを具体的に何を収集し、保持し、共有するのかを質問されました。答え（Apple のオンデバイス Vision フレームワークから得る x/y 座標1つだけで、保存はしない）は、返信だけでなくプライバシーポリシーにも書く必要がありました。1週間後、今度はプライバシーポリシーの URL そのものが表示されなくなっていたため、再びリジェクトされました。ホスティングを直し、メールから6分後に再提出したところ、24.8時間後に承認されました。
• 1.4.1、健康に関する主張には出典が必要。Race Fuel は、持久系レース向けに炭水化物、水分、ナトリウムの目標量を出すアプリです。Guideline 1.4.1 は、医療に近い数値を引用で裏付けることを求めています。対策として、DOI リンク付きの論文7本を載せた出典画面を作り、すべての数値の下にリンクを付けました。

Guideline 4.3：1週間の沈黙、そして30秒で11件のリジェクト

私のアプリ11本（車の整備記録、駐車タイマー、家財の目録、食料品の価格記録、ペットの投薬管理、家事分担表、チップ記録、成績計算、ボルダリング記録、ランニングのペース計算、カフェインの摂取期限計算）を9月26日に提出しました。キューの中で8.7〜9.3日待たされたあと、10月5日月曜日、11本すべてのリジェクトメールが米東部時間の午後5時29分32秒から5時30分02秒の間に届きました。文面はどのアプリも同じで、Guideline 4.3 のスパムと 4.2.6（テンプレートやアプリ生成サービスで作られたアプリ）に該当するとして、9つの質問に答えるよう求めるものでした。Resolution Center では、どのメッセージにも午後5時29分のタイムスタンプが付いていました。

リジェクトの文面は、次に何をすべきかを明確に書いていました。アプリがすでに準拠していると考えるなら再提出はせず、メッセージに返信して9つの質問すべてに答えること。私はそれぞれに返信し（公開ベータはなし、テストは自動化した Simulator 実行で実施、StoreKit の購入クラスとテストドライバーを共通化していることも開示）、11本すべてについて App Review Board への異議申し立てを行い、さらに同じ日の午後に11本すべてを再提出しました。この再提出が間違いでした。7日後の10月12日月曜日、27秒以内にさらに11件のリジェクトが届きました。どれも再提出からちょうど7.0日後です。

自分のローンチを計画している読者として、4.3 についてデータが示していること：

• 待ち時間が手がかりになります。私のデータでは、5.1日を超えた審査は1件を除いてすべて 4.3 のリジェクトでした。例外は Clear the Strait 1.1.1 で、審査担当者に聞かれてゲームの仕組みを長文で説明して再提出したものです。8.5日かかって承認されました。
• 判定はアプリ単位ではなく開発者単位です。2回とも30秒以内にまとめて届きました。審査がどんなものだったにせよ、11本のアプリに対する11回の別々のセッションではありませんでした。
• 変更なしで再提出しないこと。Apple 自身のメールに、大きな変更のない再提出は再びリジェクトされると書いてありました。実際そうなり、7日周期だったので1ラウンドごとに1週間を失いました。

以前、これらのアプリが実際にどれだけ Swift のコードを共有しているかを測りました。アカウント内のほかのアプリとの重複の中央値は34.5%で、アカウント内で最も似ている2本（ゴルフの記録アプリとテニスの記録アプリ）はどちらも公開中です。コードの類似度だけでは、どれが引っかかったかを説明できませんでした。数字は iPhone アプリ開発費の記事にあります。私の解釈（あくまで解釈です）：新しいアカウントから単機能のユーティリティ11本が同じ朝に提出されれば、画面がどれだけ違っていても、キューからはアプリ工場に見えます。小さなアプリのアイデアがいくつもあるなら、まず1本出してレビューとアップデートを積み重ね、残りは間隔を空けて出すか、App 内課金付きの1本のアプリにまとめましょう。後者はまさに Guideline 4.3(a) が勧めていることです。

カレンダー全体を1枚で

カレンダーとして見ると、パターンは一目瞭然です。最初の2週間は短い赤いバー（素早い 2.1 の質問）のあとに2〜5日の緑のバーが続きます。9月26日以降、アカウントは2つに分かれます。すでに公開中のアプリは約64時間でアップデートが通る一方、新しいユーティリティ11本は2本の長い赤いバーに並び、どちらも同じ30秒の枠の中で終わります。

承認後：数分で公開

メールには、承認されたものが表示されるまで「最大24時間かかることがある」と書かれています。私の公開中アプリ8本では、一般公開のタイムスタンプはずっと早く付きました。これは Apple 自身の iTunes Search API から読み取ったもので、開発者がストアに出しているすべてのアプリについて currentVersionReleaseDate を返してくれます。

# every app on the account, with the release time of its current version
curl -s "https://itunes.apple.com/lookup?id=6810582483&entity=software&country=us"

承認メールと比べると、公開時刻は8本すべてで承認の 0.7〜7.5分後、中央値2.5分でした。ローンチ日が重要なら（プレス、広告キャンペーン、Product Hunt の枠など）、手動リリースを選んでおきましょう。そうすれば、午前2時に承認されても告知より先に公開されることはありません。

待っている間、App Store Connect を開かずに状態を知りたくなるはずです。これは私のアプリのリポジトリすべてに入っているステータス確認で、App Store Connect API に直近5つのバージョンとビルドを問い合わせます。

# chain/Store/asc.py
def status():
    app = find_app()
    if not app:
        print("no app record for", BUNDLE_ID)
        return
    print(f"{app['attributes']['name']}  ({BUNDLE_ID})  id={app['id']}")
    versions = call(
        "GET", f"/v1/apps/{app['id']}/appStoreVersions", params={"limit": 5}
    )
    for v in (versions or {}).get("data", []):
        a = v["attributes"]
        print(f"  version {a.get('versionString')}: {a.get('appStoreState')}")

提出そのものは、CI ジョブの最後にある fastlane の upload_to_app_store の呼び出し1つです。3つの submission_information の回答は見た目以上に重要です。輸出コンプライアンス、広告識別子、コンテンツの権利に関する質問で、コードで答えておけば、誰かがフォームをクリックするのを待って提出が止まることがなくなります。

# chain/fastlane/Fastfile, lane :release (trimmed)
upload_to_app_store(
  api_key: asc_key,
  app_identifier: APP_IDENTIFIER,
  ipa: "build/Chain.ipa",
  # Submit, rather than leaving it sitting in Connect for a human to press
  # the button on. This is the last step and it is the irreversible one.
  submit_for_review: true,
  force: true,
  precheck_include_in_app_purchases: false,
  submission_information: {
    add_id_info_uses_idfa: false,
    export_compliance_uses_encryption: false,
    content_rights_contains_third_party_content: false
  }
)

App Store の審査は週末も動いているのか

部分的には動いています。64件の判定のうち4件は太平洋時間の日曜日に届きました。9月20日午後4時05分の Pocket Beings の初回承認と、10月11日夜の3件です（1.2 アップデート2件の差し戻しと、午後10時42分の Chain 1.2 の承認）。土曜日に届いたものは1件もありません。9月26日土曜日に行った19件の提出は、すべて月曜の夜以降に判定されました。10月8日木曜日に送ったアップデート5件は、日曜の夕方と月曜の早朝に戻ってきました。選べるなら月曜から水曜に提出しましょう。木曜以降に送ったものは、週末明けに届くと考えておいてください。

あなたのプロジェクトなら、こうします

1. 日数ではなくラウンドで計画する。1ラウンドはアップデートで約3日、新規アプリで2〜5日。新しいアカウントの新規アプリは2ラウンド必要なので、最初の提出から承認まで平日1週間を見込んでください。
2. 審査メモはテスト手順書のように書く。ログイン（または「ログイン不要」）、有料画面がどこにあるか、エッジケースの起こし方、収集するデータ。最初の提出に画面収録を添付すれば、2.1 で聞かれることはなくなります。
3. 提出のたびにプライバシーポリシーの URL が表示されるか確認する。リンク切れ1つで、私は丸々1ラウンドを失いました。
4. スピードが大事なときは App 内課金を別に出す。12時間、5件中5件承認です。
5. 5日を超える審査は警告とみなす。必要になる前に、4.3 の9つの質問への回答を準備しておきましょう。
6. Apple が「返信して」と言うときは再提出しない。変更なしの再提出で手に入ったのは、7日後の同じ時刻に届いた、まったく同じリジェクトでした。
7. 問題が具体的なら、すぐに直して再提出する。Minder のプライバシーリンク切れは、6分で再提出し、25時間で承認されました。
8. もっと早く必要なら？Apple には、重大なバグ修正や時期が重要なイベント向けの審査の迅速化リクエストがあります。私は使ったことがないので、それについての数字はありません。
9. 自分の数字を測る。同じ Gmail のクエリを自分のアカウントで実行してください。10分で自分の本当の審査カレンダーが手に入り、それはどんな平均値よりも、この記事の数字よりも役に立ちます。

データと再現方法

すべて1つのフォルダに入っています。emails.py（メールから書き起こした64行、Gmail のクエリと取得時刻付き）、analyze.py（中央値、区分、一括判定、承認から公開までの遅延）、summary.json（この記事で計算したすべての数字）、make_charts.py（グラフ）です。取得は2026年10月17日の米東部時間午後10時15分ごろ、iTunes の lookup は午後10時20分ごろに実行しました。Apple の主張は同じ夜に developer.apple.com/distribute/app-review で確認し、提出の流れは Apple のヘルプページ Submit for review に説明されています。開発者アカウント1つ、アプリ21本、5週間。小さなサンプルですが完全なデータで、審査時間のデータとしては実際に検証できる唯一の種類のものです。

Windows で開発していて、同じパイプライン（クラウドビルド、署名、スクリーンショット、fastlane での提出、審査メモのテンプレート）を自分のリポジトリにセットアップしたいなら、No-Mac iOS Pipeline（$299）があります。Windows PC から最初の TestFlight ビルドまで5営業日です。アプリ丸ごとお任せいただく場合は、固定価格での開発を /build/ でご案内しています。