App Store 审核要多久：64 次真实审核结果，中位数 73 小时

太长不看：我把开发者账号收到过的每一封 App Review 结果邮件都翻了出来：21 款 iPhone App 的 64 次审核结果，时间跨度是 2026 年 9 月 10 日到 10 月 12 日，每一封都带有 Apple 自己写的“Submitted”时间戳，以及结果送达的时间。等待时间的中位数是 73 小时。Apple 的页面上说，它会在 “at least 50% of submissions in less than 24 hours and 90% in less than 48 hours”（至少 50% 的提交在 24 小时内、90% 在 48 小时内完成审核）。我的数据：24 小时内 19%，48 小时内 27%。已上架 App 的更新，中位数是 64 小时；单独提交的内购项目只要 12 小时；而 21 款新 App 里，首次提交就通过的是 0 款。

先给搜索过来的朋友一个简短答案。如果你在规划 2026 年的上线，更新版本请按每轮审核 3 天预留；全新 App 的过审按 2 到 5 天预留；新账号上的新 App 还要至少多留一轮，因为第一次提交通常会被打回来问问题。一次审核拖了一周，并不是“慢慢在通过”。在我的数据里，所有超过 5.1 天的等待，除了一次之外，最后都以 guideline 4.3 spam 被拒告终。

如果你还在“这要花我多少钱”的阶段，免费的 iPhone App 成本计算器可以把功能换算成工时和美元；这篇文章讲的是计算器算不出来的部分：从点下“Submit”到“Ready for Distribution”之间的日历时间。我是在一台没有 Mac 的 Windows PC 上开发这些 App 的（流水线在这里），所以下面每一次提交都是通过 CI 任务或 App Store Connect 网站发出的，从没用过 Xcode。

2026 年 App Store 审核要多久？

下面是数据，按你实际会遇到的情况拆分。“等待”是指从 Apple 邮件里“Submitted”那一行到结果邮件到达的时间，所以它包含了排队时间，而不只是审核员看 App 的那几分钟。

提交内容	结果数	等待中位数	最快	最慢	通过
仅内购项目	5	12.2 h	11.7 h	13.4 h	5 / 5
已上架 App 的更新	16	64.4 h	6.3 h	203.6 h	11 / 16
新 App（正常轮次）	21	51.2 h	3.1 h	120.5 h	8 / 21
新 App（两批 4.3 spam）	22	187.8 h	167.7 h	223.3 h	0 / 22
全部	64	73.1 h	3.1 h	223.3 h	24 / 64

有两点很显眼。新 App 的被拒和提问回来得很快（13 次正常的被拒，中位数 27.8 小时），因为审核员一碰到问题就停下了。通过反而更慢：8 次首版通过的中位数是 69.9 小时，没有一次在 48 小时内回来。所以从统计上说，回复来得快，往往是坏消息。

实验方法：每封邮件一对时间戳

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，返回 69 个会话；其中 64 个是审核结果（另外五个是 App Store Connect 欢迎邮件、API 权限批准、两封“Welcome to the App Store”和一封“Thank you for submitting”）。这个账号是 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 的首个版本、更新，或者单独的内购项目。这些信息取自 App 自己的记录（仓库的提交历史和我的笔记），有歧义的那一批我对照邮件正文核对过，正文会列出提交项：Chain 在 10 月 8 日晚上的那次提交写的是 In-App Purchases (6)，没有 App 版本。邮件里根本没有被拒原因（正文只写“We noticed an issue”），所以这些原因来自我保存的 Resolution Center 文本和我发出的回复。

这个方法看不到的东西：在出结果之前被我取消的提交（没有邮件，也就没有记录），以及审核员打开 App 的确切时刻。如果你想要的是“审核中的时间”而不是“等待的时间”，App Store Connect API 会暴露版本状态，但不提供状态历史，所以你得自己去轮询。

Apple 的 24 小时 vs 我的数据

Apple 的措辞很讲究：它说的是一半的提交在 24 小时内审核完。这句话可以是真的，同时又和你的体感对不上，原因有三，在我的数据里都看得到。

第一，计时是从排队开始的。我的过审结果几乎都集中在同一个耗时上。16 次更新里有 7 次落在 63.5 到 64.5 小时之间，因为它们是在 9 月 26 日周六上午一起提交的，又在太平洋时间周一深夜的 32 分钟内一起出了结果。不管审核本身花了多久，等待时长取决于队列什么时候轮到它们。

第二，Apple 似乎周六不出新的审核结果，至少我的没有。64 次结果按太平洋时间统计：周一 35 次，周五 10 次，周四 7 次，周三 5 次，周日 4 次，周二 3 次，周六 0 次。周一的数字被两批 spam（22 次结果）抬高了，但就算去掉它们，也没有一次落在周六。所以没错，App Review 周日也上班（四次周日结果中有两次是通过），但周六上午的提交照样要等到周一晚上。

第三，慢的长尾不是随机的。去掉两批 4.3 之后，我的数字就和 Apple 的接近多了：24 小时内 29%，48 小时内 40%。22 次 spam 被拒，每次都花了 7 到 9.3 天。长时间等待是一个信号，而不是运气不好。

快车道是内购项目。五次仅内购的提交（给五款已上架 App 新增的主题和礼包，在 10 月 8 日周四深夜通过 API 发出）全部在 11.7 到 13.4 小时后通过，彼此相差不到 95 分钟。如果你需要尽快上线一个新价位或一个礼包，就把它单独提交，别动二进制包。

新 App：21 款里首次提交就通过的是 0 款

21 款 App 的首次提交全部被退回。这听着吓人，但看了原因就不慌了。21 封首轮邮件里有 10 封是 guideline 2.1“Information Needed”（另外 11 封是下面要讲的 spam 批次），也就是新开发者账号都会遇到的例行问题：提交一段 App 在真机上运行的录屏，说明主要功能，说明是否需要登录，列出用到的外部服务。Apple 的指南本来就要求提前提供这些信息；账号是新的时候，审核员还是会再问一遍。

真正奏效的做法，是不再把审核备注当成走过场。现在每个 App 都带一个 Store/review-notes.md，由流水线推送到 App Store Connect 的审核信息里，写成审核员一分钟内就能照着走完的操作指引，包括怎么进入每一个付费页面：

# 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 带着回答和录屏重新提交，三款都在 51 到 67 小时后通过。在最终上架的 8 款 App 中，从第一次提交到第一次通过，时间中位数是 4.4 天（范围 3.75 到 7.2 天）。新账号上的新 App，上线计划里该写的诚实数字就是这个：不是 24 小时，而是接近一个工作周。

其他首轮被拒原因也值得了解，因为每一个都很容易提前规避：

• 5.1.1 隐私，同一款 App 两次。Minder 是一个专注计时器，里面的卡通眼睛可以跟着你的脸转（眼睛动画见这篇 SwiftUI 文章），审核员要求说明它到底收集、保存和分享了哪些面部数据。答案（只有一个来自 Apple 设备端 Vision 框架的 x/y 坐标，从不存储）必须写进隐私政策里，光在回复里说不行。一周后它又被拒了，因为隐私政策的 URL 本身打不开了。我修好了托管，在收到邮件六分钟后重新提交，24.8 小时后通过。
• 1.4.1，健康相关的说法需要来源。Race Fuel 为耐力赛提供碳水、补液和钠的摄入目标。Guideline 1.4.1 要求这类接近医疗的数字有文献支持。解决办法是加一个来源页面，列出七篇带 DOI 链接的论文，并在每个数字下面放上链接。

Guideline 4.3：沉默一周，然后 30 秒内 11 封拒信

我有 11 款 App（一个汽车保养日志、一个停车计时器、一个家庭物品清单、一个超市价格记录、一个宠物用药追踪、一个家务表、一个小费记录、一个成绩计算器、一个抱石日志、一个跑步配速计算器和一个咖啡因截止时间计算器）在 9 月 26 日提交。它们在队列里待了 8.7 到 9.3 天。然后在 10 月 5 日周一，11 封拒信全部在美东时间下午 5:29:32 到 5:30:02 之间到达。每款 App 的拒信内容都一样：guideline 4.3 Spam 加 4.2.6，即使用模板或 App 生成服务制作的 App，附带九个需要回答的问题。Resolution Center 里每条消息的时间戳都是下午 5:29。

拒信对下一步说得很明确：如果你认为 App 已经合规，不要重新提交，而是回复这条消息并回答全部九个问题。我逐一回复了（没有公开测试版，通过自动化 Simulator 运行做测试；共用的 StoreKit 购买类和测试驱动，已主动披露），为全部 11 款提交了 App Review Board 申诉，同时在当天下午把 11 款全部重新提交了。重新提交就是那个错误。七天后的 10 月 12 日周一，又有 11 封拒信在 27 秒内到达，每一封都恰好在重新提交后 7.0 天。

如果你在规划自己的上线，数据对 4.3 透露了这些：

• 等待时长就是信号。在我的数据里，所有超过 5.1 天的审核，除了一次之外都是 4.3 被拒。那个例外是 Clear the Strait 1.1.1：审核员提问后，我重新提交并附上了一份关于游戏玩法的长篇书面说明；它花了 8.5 天，最后通过了。
• 它是按开发者判定的，不是按 App。两批拒信都在 30 秒内到齐。不管审核是怎么做的，都不可能是对 11 款 App 分别进行的 11 次审核。
• 不要原样重新提交。Apple 自己的邮件就说了，没有实质改动的重新提交会再次被拒。结果确实如此，而且是按七天的周期，每一轮就浪费一周。

我之前测过这些 App 实际共用了多少 Swift 代码。和账号里其他 App 的重合度中位数是 34.5%，而账号里最相似的两款 App（一个高尔夫日志和一个网球日志）都已上架。单靠代码相似度解释不了谁被标记；数据见 iPhone App 开发成本那篇文章。我的看法（声明一下，这只是看法）：一个新账号在同一个上午提交 11 款单一用途的小工具，无论界面多不一样，在队列里看起来都像一个 App 工厂。如果你有好几个小 App 的点子，先上线一个，让它积累评价和更新，其余的错开时间发布，或者把它们合并成一个带内购的 App，这正是 guideline 4.3(a) 所建议的。

一张图看完整个日历

放到日历上，规律一目了然。头两周是短红条（很快回来的 2.1 提问），接着是两到五天的绿条。从 9 月 26 日起，账号一分为二：已上架的 App 大约 64 小时就能通过更新，而 11 款新工具卡在两段长红条里，每次都在同一个 30 秒窗口内结束。

通过之后：几分钟就上线

邮件里说，通过的内容“it can take up to 24 hours”（最多可能需要 24 小时）才会出现。对我的 8 款已上架 App 来说，公开发布时间戳来得快得多。我是从 Apple 自己的 iTunes Search API 读到的，它会为开发者在商店里的每款 App 返回一个 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 款 App 的发布时间都在通过后 0.7 到 7.5 分钟，中位数 2.5 分钟。如果你的上线日期很重要（媒体报道、广告投放、Product Hunt 档期），就选择手动发布，免得凌晨 2 点的一次通过抢在你的官宣之前上线。

等待期间，你会想不打开 App Store Connect 就看到状态。下面是我每个 App 仓库都带着的状态检查脚本，它会向 App Store Connect API 查询最近五个版本和构建：

# 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。三个 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 次出现在周日（太平洋时间）：Pocket Beings 在 9 月 20 日下午 4:05 首次通过，另外三次在 10 月 11 日晚上（两个 1.2 更新被退回，Chain 1.2 在晚上 10:42 通过）。没有一次出现在周六。我在 9 月 26 日周六做的 19 次提交，全部在周一晚上或更晚才出结果；10 月 8 日周四发出的五个更新，在周日晚上和周一凌晨回来。如果可以选，就在周一到周三提交；周四及以后发出的，默认它会在周末之后才有结果。

如果是你的项目，我会这么做

1. 按轮次规划，而不是按天。一轮审核，更新大约 3 天，新 App 2 到 5 天。新账号上的新 App 需要两轮：从第一次提交到通过，预留一个工作周。
2. 像写测试脚本一样写审核备注。登录方式（或者“无需登录”）、每个付费页面在哪里、怎么触发边界情况、你收集了哪些数据。第一次提交就附上录屏，让 2.1 无话可问。
3. 每次提交前确认隐私政策 URL 能打开。一个失效链接让我白白浪费了一整轮。
4. 要速度的时候，把内购项目单独提交。12 小时，5 次全部通过。
5. 审核超过 5 天就当作警告。在用到之前，先把 4.3 那九个问题的答案准备好。
6. Apple 说回复，就不要重新提交。没有改动的重新提交，只给我换来又一封一模一样的拒信，而且正好晚了七天。
7. 问题具体的时候，修好就马上重新提交。Minder 的隐私链接失效：6 分钟内重新提交，25 小时后通过。
8. 需要更快？Apple 提供加急审核申请，用于关键 bug 修复和有时效性的活动。我没用过，所以没有相关数据。
9. 测你自己的。在你的账号上跑同一条 Gmail 查询。十分钟就能得到你真实的审核日历，比任何平均值都靠谱，包括这篇文章里的。

数据，以及如何复现

所有东西都在一个文件夹里：emails.py（从邮件中誊录的 64 行数据，附 Gmail 查询语句和拉取时间）、analyze.py（中位数、分组、批次、通过到上线的延迟）、summary.json（本文中所有计算得出的数字）和 make_charts.py（图表）。拉取时间为 2026 年 10 月 17 日美东时间晚上 10:15 左右；iTunes 查询在晚上 10:20 左右运行。Apple 的说法是同一晚从 developer.apple.com/distribute/app-review 读取的，提交流程见 Apple 的 Submit for review 帮助页面。一个开发者账号、21 款 App、五周时间：样本不大，但是完整的，而且是唯一一种你真正能核实的审核时长数据。

如果你在 Windows 上开发，想在自己的仓库里搭一套同样的流水线（云端构建、签名、截图、fastlane 提交、审核备注模板），那就是 No-Mac iOS Pipeline，$299：5 个工作日内，从 Windows PC 发出你的第一个 TestFlight 构建。如果你想把整个 App 交出去，固定价格的开发服务在 /build/。