Apple 的 4.3 spam 检查是一个 30 秒的批处理任务，22 封拒信就是证据

太长不看：Apple App Review 以 Guideline 4.3 Spam 拒了我 11 款 iPhone App。然后又拒了一次。两次都是 11 封拒信在 30 秒内全部到齐（10 月 5 日 30 秒，10 月 12 日 27 秒），每 3 秒一封，而且到达顺序和我的提交顺序毫无关系。第二轮是在我重新提交后 167.7 到 167.9 小时到达的，每一款都是：一个七天的定时器，误差 12 分钟。10 月 5 日我向 App Review Board 提交了三份申诉。14 天过去了：零回复。今天我拿自己写的“spam 检测器”扫了一遍全部 20 个 App 仓库，用的都是 Apple 审核时看到的版本。我发布过的最相似的两款 App，现在都在架上。Apple 并不是按 App 来做 4.3 审核的。它审的是账号，只是它不说。

如果你是从 Google 搜“Guideline 4.3 spam”是什么意思过来的：这是 Apple 针对重复 App 的规则。(a) 部分禁止“multiple Bundle IDs of the same app”（同一个 App 用多个 Bundle ID），(b) 部分禁止“indistinguishable from what's already widely available”（与市面上已大量存在的 App 无法区分）的 App。拒信通常会说你的 App 与其他 App“shares a similar binary, metadata, and/or concept”（二进制、元数据和/或概念相似），只有“only minor differences”（细微差别）。它不会告诉你是哪个 App、哪个文件、哪个界面。简短的应对清单在文末：别再批量提交，先回复再重新提交，以及预约和 App Review 通话。本文其余部分都是证据。

11 款 App，30 秒，每 3 秒一封邮件

2026 年 9 月 26 日，我提交了 11 款新 iPhone App，全部是在 Windows 上用我之前写过的无 Mac 流水线构建的：Odometer（汽车保养）、Parked（停车计时）、Rooms（家庭财产保险清单）、Pricebook（超市价格）、Pawprint（宠物用药）、Chores（儿童家务表）、Clockout（服务业小费记录）、Curve（成绩计算器）、Climbbook（抱石日志）、Race Pace（跑步分段配速）和 Cutoff（咖啡因与睡眠）。这些提交分散在 15.5 小时里：第一个在太平洋时间上午 7:10，最后一个在晚上 10:42。

九天后的 10 月 5 日，每一款都收到了同样一封“There's an issue with your submission”邮件。今天早上我从 Gmail 里把时间戳拉了出来。第一封在美东时间下午 5:29:32 到达，最后一封在 5:30:02。十一款 App，每一款解决的问题不同、面向的人群不同、设计也不同，在三十秒内被判了。

我还检查了这些结果是不是按提交顺序出来的，也就是一个人顺着队列逐个处理时会产生的那种顺序。不是。“提交顺序”和“被拒顺序”之间的 Spearman 秩相关系数，第一批是 -0.06，第二批是 0.06。也就是零。Pawprint 第 4 个提交，第 1 个被拒。Odometer 第 1 个提交，第 11 个被拒。不管是什么做出了这些决定，都不是一个人在一个接一个地打开 App。

十一款不同的 App，三十秒内判完。这不是审核，这是一个 for 循环。

第二轮：一个七天定时器，误差 12 分钟

接下来是我违反 Apple 唯一一条规则的地方，这一点我认。拒信上写着：如果你有异议，请在 App Store Connect 中回复，不要重新提交。我回复了全部 11 款，每款都回答了 App Review 的全部九个问题。然后我还是在 10 分钟内把 11 款全部重新提交了（10 月 5 日太平洋时间下午 3:13 到 3:23）。

第二轮拒信在 10 月 12 日美东时间下午 6:04:46 到 6:05:13 之间到达。11 款 App，27 秒。但真正诡异的是等待时间。每一款从重新提交到被拒都等了 167.7 到 167.9 小时。168 小时正好是七天。十一款 App，十一段等待，前后相差 12 分钟。

作为对比，Apple 自己的 App Review 页面说它会在“at least 50% of submissions in less than 24 hours and 90% in less than 48 hours”（至少 50% 的提交在 24 小时内、90% 在 48 小时内）完成审核。上周末我统计了我账号上全部 64 次 App Review 结果，中位数是 73 小时，本来就比 Apple 的承诺差。我账号上没有任何其他提交恰好等了 168 小时。

我的解读（只是解读，不是内部消息）：被标记的账号会进入一个带一周定时器的待处理队列，定时器一到，整批提交就收到同一封模板拒信。按下按钮的也许是人，但没有人打开过这些 App。如果你对 11 款不同的 App 都落在“7 天减 15 分钟”有更好的解释，我很想听。

不只是我。同一周，同样的 30 秒待遇

我去 X 上找了找 2026 年 10 月遇到同样情况的其他开发者。搜一次就找到了。以下是真实的帖子，今天截取，未经编辑。

10 月 5 日，也就是我第一批被拒的同一天，@krPorsche918 发帖说 Apple 拒了他们五款 App，“in the same minute, with the same sentence: Guideline 4.3 Spam”（在同一分钟内，用同一句话）。他们的复盘文章里有一句关于这件事最精辟的话：“To me, 14 apps in 13 days was productivity. To Apple, it was a pattern.”（在我看来，13 天 14 款 App 是生产力；在 Apple 看来，这是一种模式。）同一周，Apple 批准了他们已上架 App 的全部 53 个 App 内活动。

10 月 8 日，@vovalukashov（Luka Shaw）问出了回复区每个人心里的问题：“Looks like Apple stopped approving my new apps... Is this what happens to everyone who builds small apps that do one thing?”（看起来 Apple 不再批准我的新 App 了……做只干一件事的小 App 的人，都会遇到这种事吗？）四周内三款新 App 被拒，其中一款被拒了两次。“Updates to my old apps still go through.”（我老 App 的更新还是能过。）6.2 万人看到了这条帖子。

还有 10 月 12 日美东时间下午 6:26，就在我第二批 11 封拒信到达 22 分钟后，@martindonadieu（Martin Donadieu，Capgo 创始人）贴出了他的 App Store Connect 界面：满屏红色的“Rejected”标记，配文“Moved from no review to almost all rejected LOL”（从没人审直接变成几乎全拒，笑死）。22.3 万次浏览。三天后他再次发帖：第二次因 4.3 被拒，那是一款 100% 本地运行的票务 App，今年夏天支撑过一场 500 人的活动，而且已经在 Google Play 上架。

看看我们四个人身上的共同规律。新 App 死，更新过。我自己的账号就是例子：在 11 款新 App 被连杀两次的同一时间窗口里，Apple 批准了 Chain 和 Minder 的更新（10 月 12 日），以及 9 月 29 日的六个更新。9 月那六个更新全部加入了与被拒 App 相同的付费墙模式（Pro.swift；Chain 里是 Purchases.swift），而且是同一个上午提交的代码（9 月 26 日美东时间 9:26 到 9:29）。同样的代码，同一天。更新：大约 3 天通过。新 App：两次被拒。Luka 说他的更新能过。Porsche 的 53 个 App 内活动获批。Martin 的已有 App 也都还在架上。

所以我在这里和 Luka 意见不同。他的结论是“I guess it's a sign to focus on the ones already in the App Store”（大概这是在提示我专注于已经上架的那些吧）。这正是这个过滤器在训练每个小开发者养成的行为，而这是错误的教训。过滤器并不是在说你的新 App 不好，而是在说你的账号发得太快，让 Apple 不舒服了。这是两个不同的问题，解法也不同。

Apple 判得对吗？我给自己的 App 跑了一遍 spam 检测

这个问题很公平：也许我的 App 真的是克隆品。我是一个开发者，30 天里做了 20 款 iPhone App，用的是 AI 编程 agent，全出自同一条流水线。如果有谁活该吃 4.3，可能就是我。所以今天下午我做了测试，而不是去争论。

实验方法：对我本地的 20 个 App 仓库，各取 Apple 实际看到的那个 git commit（对 8 款已上架 App，取首次通过前的最后一个 commit；对 11 款被拒 App，取 10 月 5 日重新提交前的最后一个 commit）。然后两两比较，共 190 对，看五个 4.3 过滤器可能会关注的方面：

• 文件树重合度：被追踪文件路径的 Jaccard 相似度（共有路径除以全部路径）。这是“骨架”。
• 相同文件：把 App 自己的名字替换掉之后，逐字节完全相同的文件。
• Swift 代码行重合度：两款 App 共有的、去重后的非平凡 Swift 源码行所占比例。
• 商店文案重合度：App Store 描述中三词短语的重合度。
• 截图距离：两款 App 之间最接近的一对商店截图，用 256 位平均哈希计算（越低越相似）。

先说诚实的结果，因为它对我并不友好：被拒的 11 款确实共用一副骨架。它们的文件树重合度中位数是 0.76，已上架 App 是 0.56。每对平均共有 14 个相同文件（中位数），上架组是 5 个；Swift 代码行重合大约是三倍（0.067 对 0.021）。Clockout 和 Odometer 的文件树完全一样：同样七个 Swift 文件，同样的文件名，放在同样的文件夹里。如果 Apple 的过滤器会看二进制包里的项目结构，我被拒的这一批会一下子亮起来。

接下来是 Apple 该解释的部分。190 对里最相似的一对是 Baseline Ledger 和 Fairway Ledger，我的网球日志和高尔夫日志。它们共有三分之一的 Swift 代码行（0.333）、20 个相同文件、0.90 的文件树重合，商店描述是所有组合里最相似的，截图也最接近。两款都通过了，相隔两天，分别在 9 月 22 日和 24 日。两款今天都在架上。Chain 和 Quiver 的文件树重合度是 0.968。两款都在架上。

而人类审核员真正会看的东西，也就是商店页面和截图，完全分不开这两组。商店文案重合度：被拒组合 0.010，上架组合 0.009。截图距离：76 对 82。一个人翻看商品页，根本看不出被拒的 App“更相似”。只有对比安装包的机器才看得出来。

每款被拒 App 都有的那个文件

能把两组干净利落分开的特征，并不是某个相似度得分，而是一个文件。11 款被拒 App 在首次提交时全都带着 Sources/Pro.swift。8 款上架 App 在首次通过时都没有。Pro.swift 是一个 StoreKit 2 付费墙：App 免费，一次性 $4.99 购买解锁完整版。下面是 Odometer 里这个文件的开头，取自 Apple 审核时的 commit：

// Sources/Pro.swift (odometer repo, commit af40d3658)
/// Odometer Pro: one non-consumable. Keeping one car on schedule is free forever; Pro is the
/// whole garage and the paperwork.
@MainActor
@Observable
final class Pro {
    static let productID = "com.mattbusel.odometer.pro"
    /// The first build that has Pro in it. Anything earlier had every feature.
    static let firstFreemiumBuild = 2

    enum Reason: String, Identifiable { case costs, garage, history, export, settings; var id: String { rawValue } }

    private(set) var unlocked: Bool
    private(set) var grandfathered = false
    private(set) var product: Product?

    var price: String { product?.displayPrice ?? "$4.99" }

    func ask(_ why: Reason) { if !unlocked { paywall = why } }
    ...
}

这些文件并不是互相复制的（没有任何两款被拒 App 的 Pro.swift 完全相同；每款都有自己的商品、自己的免费层级和自己的升级理由）。但形状是一样的：一个非消耗型商品，一个 Pro 类，一个付费墙弹窗。上架的 App 在通过时都没有它，后来才通过 9 月 26 日提交的更新改为免费增值模式，也就是 11 款新 App 提交的同一天。这些更新在 9 月 29 日一路顺利通过。

下面是我认为真正在发生的事，Apple 永远不会明说。一款全新的免费 App 带一个 $4.99 解锁，出自一个一天丢出 11 款这种 App 的账号，这正是模板工厂的典型轮廓。4.3 的条文及其姊妹条款 4.2.6 针对的是“commercialized template or app generation services”（商业化的模板或 App 生成服务）。到了 2026 年，每个编程 agent 都能一天吐出一款 App，模板工厂和用 Claude Code 的独立开发者从外面看是一样的。Apple 的过滤器判断的是轮廓，签字的人从不打开 App。这是相关性，不是证明：19 款 App 是个小样本。但它比指南条文里的任何东西都分得更干净。

我回了什么，收到了什么：什么都没有

4.3 拒信附带九个问题：App 是做什么的、面向谁、有什么不同、你是怎么测试的、是否与你的其他 App 共用代码，等等。我逐个 App、诚实地回答了每一个问题。包括那些可能对我不利的部分，比如 Odometer 回复中的这一段：

"No shared framework or asset pack. Every screen, model, illustration and text is specific to Odometer. Two files follow a pattern I reuse: the StoreKit 2 purchase handling for its one non-consumable (the paywall's text, free/Pro split and look are specific to the app), and a test-only driver that steps through the app's screens to record the walkthrough video and is inactive in normal use."（大意：没有共享的框架或素材包。每个界面、模型、插图和文字都是 Odometer 专属的。有两个文件沿用了我复用的模式：它唯一一个非消耗型商品的 StoreKit 2 购买处理（付费墙的文案、免费与 Pro 的划分和外观都是这款 App 专属的），以及一个仅用于测试的驱动程序，它会逐个走过 App 的界面来录制演示视频，在正常使用中不生效。）

然后我通过 Apple 的表单向 App Review Board 提交申诉，每张表单最多 5 款 App、每条理由 2,000 个字符，所以填了三张（5 + 5 + 1）。论点很简单：11 款 App 在一分钟内被拒，拒信一字不差，所以根本没有进行过单独审核，我请求由真人逐一打开每款 App。

那是 10 月 5 日。今天早上我在收件箱里搜了 Apple 之后发来的所有邮件。有 Apple Ads 的账单邮件、一封 iPhone Duo 预购广告，还有一条 App Review Guidelines 于 10 月 16 日修订的通知。自 10 月 12 日第二批之后，没有任何来自 App Review 或 App Review Board 的邮件，关于申诉更是只字未提。13.8 天，还在继续。

10 月 16 日那次修订本身就是个小小的讽刺。Apple 改写了指南的七个部分（关于创意素材和隐藏功能、支付链接、儿童安全的新规则）。Guideline 4.3 不在其中。在一波公开的 4.3 批量拒审浪潮中间，这条规则一个字都没改。

Apple 自己的数字说明：你并不特殊

Apple 每年都会发布 App Store Transparency Report。2025 年版统计了 9,100,620 次审核提交，其中 2,093,244 次被拒，约 23%。包含 spam 和山寨的 Design 部分占 415,532 次被拒。Apple 2026 年 5 月的新闻稿称，它因抄袭其他 App、spam 或误导用户拒绝了超过 371,000 次提交。

再看那一行没人引用的数据。同一份报告统计了 26,305 次针对 App 下架的申诉，以及 423 次恢复上架。也就是 1.6%。早在 2021 年，Apple 的 App Review 高级总监就在一份法庭文件中表示，团队有 500 多名人工审核员，而且 less than 1% of rejections are appealed（只有不到 1% 的拒审会被申诉）。自己算一下：每年 910 万次提交，大约每天 25,000 次。37.1 万次 spam 类被拒，大约每天 1,000 次。没有人能每天认真打开 1,000 款 App。30 秒批处理不是这个系统的故障，它就是这个系统。

犀利观点，按强度排序

1. 4.3 已经变成了针对独立开发者的产量税。它抓不到克隆品，我最相似的两款 App 都在架上。它抓的是那些发得比 Apple 认为一个人该发的更多的账号。在 AI 编程时代，这意味着每一个有点本事的独立开发者。
2. App Review Board 对批量拒审来说是个黑洞。我打赌：这 11 份申诉在 11 月之前不会收到真人回复，就算哪天回复了，也会是一段适用于全部 11 款的模板文字。
3. Apple 绝不会主动公布 4.3 的数字。透明度报告只在下架统计里列出“4.3.0 Spam”（418 款 App），从不列在拒审统计里，因为按条款统计会暴露所谓“反 spam”在多大程度上其实是在给新开发者限流。
4. 更新能过，是因为更新已经在给 Apple 赚钱。已上架 App 的更新是一个有付款记录的已知量，新 App 是一笔成本。本文中的每一个账号，都在新 App 被干掉的同几周里获批了更新。这不是巧合，这是商业模式。
5. Google 会把这块吃掉。Martin 的 App 在 Apple 第二次拒绝它的一周前就已经在 Google Play 上架了。当独立开发者的首发转向 Android，Apple 的“质量”说辞就会安静很多。

被 Guideline 4.3 spam 拒了，怎么活下来

根据上面的数据和 Apple 自己的页面，下面是我会换个做法的地方。这也是我现在自己在遵循的建议。

1. 永远不要批量提交新 App。每个账号每周一到两款新 App。Porsche 的“13 天 14 款”和我的“一天 11 款”得到了同样的答案。已上架 App 的更新想多快都行。
2. 回复，不要重新提交。拒信里就是这么写的，我没听。我的重新提交落在七天定时器上，27 秒内全军覆没。在 App Store Connect 里回答那九个问题，然后等。
3. 新 App 先不带付费墙上线，内购放到更新里加。我的 8 款过审 App 在首次通过时 0 款有付费墙；11 款被拒 App 全都有。样本小，但这是我找到的唯一一条干净的分界线，而且免费增值的更新每次都通过了。
4. 如果你的 App 是变体，就合并。4.3(a) 字面上就告诉你：只发一款 App，把变体作为内购来卖。如果审核员能用一句话描述你的两款 App，他们就会这么做。
5. 预约和 App Review 通话。Apple 提供 30 分钟的 Webex 预约，可以和 App Review 讨论指南。几乎没人提到这一点。这是唯一一个必须有真人看你一眼的渠道。这也是我的下一步。
6. 申诉要具体，一次提交一份申诉。Apple 的申诉页面要求提供“specific reasons why you believe your app complies”（你认为 App 合规的具体理由）。批量拒审的时间戳就够具体了。目前看来光有这些还不够，所以配合第 5 条一起用。

如果你想要构建和发布这 20 款 App 的那套流水线（在 Windows PC 上，没有 Mac），在 Windows 上做 iOS 开发的完整指南都讲了，钱的那一面见 20 款真实 App 的开发成本。

目前为止的数字

• 两次以 4.3 被拒：11 款 App（22 次被拒），2026 年 10 月 5 日和 10 月 12 日
• 拒掉 11 款 App 用时：30 秒（10 月 5 日），27 秒（10 月 12 日）
• 提交顺序 vs 被拒顺序：Spearman -0.06 和 0.06（没有关系）
• 第二轮等待：全部 11 款都是 167.7 到 167.9 小时（Apple 称 90% 在 48 h 内）
• 已提交申诉：3 张表单，覆盖 11 款 App，10 月 5 日。13.8 天后回复：0（10 月 19 日美东时间下午 1:10 检查收件箱）
• 今天在美区 App Store 上架：8 款 App（iTunes 查询，10 月 19 日美东时间下午 1:12），自 10 月 17 日以来没有变化
• 190 对中最相似的一对：Baseline Ledger + Fairway Ledger，33% 的 Swift 代码行相同。两款都在架上。
• 首次提交时带付费墙：被拒 App 11 款中 11 款，过审 App 8 款中 0 款

数据，以及如何复现

结果时间戳：来自 Apple App Review 发件人的 22 封“There's an issue with your submission”邮件，连同其中的“Submitted:”行（太平洋夏令时），于 10 月 17 日从 Gmail 拉取，并在 10 月 19 日美东时间下午 1:10 再次检查是否有更新的邮件（没有）。特征指纹：fingerprint.py 于 10 月 19 日美东时间下午 1:19 在 20 个本地仓库上运行，每个仓库取决定性提交之前的 commit（git rev-list -1 --before=...），用 git show 读取文件，文件比较中排除 PNG，哈希前把 App 自己的名字替换成占位符。上架状态：对我的开发者账号做的 iTunes Search API 查询，美东时间下午 1:12。@krPorsche918、@vovalukashov 和 @martindonadieu 的帖子于 10 月 19 日美东时间下午 1:15 左右从 X 截取，真实且未经编辑。

所以，@martindonadieu、@vovalukashov、@krPorsche918：查查你们自己的拒信。你们的拒信是不是在几秒内相继到达？重新提交是不是正好等了一周？如果再有三个账号出现同样的 168 小时定时器，这就不再只是我的猜测了。其他朋友：Apple 的 App Review Board 真的回复过你的 4.3 申诉吗？花了多久？把你的数字留在评论区。

在没有 Mac 的情况下开发 iPhone App，想在自己的仓库里搭好流水线（签名、截图、fastlane 提交，以及我现在用的审核备注）？No-Mac iOS Pipeline 只要 $299，5 个工作日内发出第一个 TestFlight 构建。