从零开发的 App,却被苹果判定和＂被封账号＂有关

一件很反直觉的事情：你的代码是自己写的，工程是你自己新建的，团队是你自己搭的，App Store 上没有任何一个已下架的应用和你有可见的关系。但苹果的拒审邮件告诉你，它和你不认识的某个"被终止 Apple Developer Program account"提交过的应用太像。

我把这事完整记录下来过，也分享给了身边做 iOS 的朋友。结果发现，这种"看起来完全不可能发生"的拒审并不稀罕，发生的人远比想象中多。而当我把它放在 AI 辅助开发的背景下重新审视，才意识到这事可能不是孤例，而是 App Store 相似性检测机制在 AI 编程时代撞上的第一波系统性摩擦。

一次很奇怪的拒审

提交的那款 App 叫"听途"，版本 1.0 (6)，审核设备 iPad Air 11-inch (M3)，Submission ID cfbe4fa5-fbba-4094-b940-e024cb73507a，审核日期 2026 年 10 月 5 日。第一次提交，直接拒。

苹果在 Resolution Center 里的原话是：

Guideline 4.3(a) - Design - Spam

We noticed your app shares a similar binary, metadata, and/or concept as apps previously submitted by a terminated Apple Developer Program account.

Submitting similar or repackaged apps is a form of spam that creates clutter and makes it difficult for users to discover new apps.

后面列了四个"可能触发 Spam 的因素"：用了和其他 App 一样的源码或资源、用模板换壳做了多个相似 App、买了有问题的第三方模板、在多个账号下提交了相似 App。

每个名词都认识，连起来指向的却是一件我做不到的事。我和那个被封的账号没有任何关系。

这个 App 确实是自己做的

这件事值得单独说一遍，因为它直接决定后面怎么分析。

项目是新建的工程。没有买过第三方 App 模板。没有基于别的开发者已有的 App 换壳。没有复用别人的完整源码。整个 App 的产品设计、功能规划、内容编排，是我和团队一起做的。

开发过程中确实用了大量 AI 辅助编程，主要是生成、修改、重构、完善代码。但产品层面的事情，比如选什么主题、怎么组织课程、UI 长什么样、用户路径怎么走，都是我们自己定的。

所以下面这句话要严格地讲两遍：

第一遍是事实。AI 辅助开发是这个案例的重要背景。

第二遍是边界。目前没有证据能够证明 AI 是直接触发这次 4.3(a) 的原因。不要把它写成"苹果因为我用 AI，所以拒审"。这两件事之间的距离，我现在说不清楚。

4.3(a) 到底在查什么

先把苹果自己的 4.3 原文放上来。这是 Apple 开发者站上《App Store Review Guidelines》4.3 Spam 一节的全文：

4.3 Spam

Don't create multiple Apps with similar purpose, functionality, content, or concept. The most common issues we've found with this guideline include:

- Copies of an existing app, or content from a website, with no significant modifications or added features

- Templated, "cookie-cutter" apps with only minor variations in appearance or functionality

- Repackaged apps, like the ones created by commercial app generation services

- Apps that aren't designed for any specific purpose, user, or intended end-user

- Apps that are essentially identical to other apps waiting for review or already on the App Store

注意，Apple 公开的 4.3 是这一整条带要点清单的条款，没有官方的 (a)/(b) 子条款编号。但在真实拒审里，常见 (a)/(b) 两种说法，分别指向不同的"对象"。

粗略区分：

(a) 你和某些已有 App / 被封账号太像，包括重复 App、模板换壳、同一 App 多 Bundle ID、多账号提交相似 App、复用相同源码或资源、使用大量提交的第三方模板。

(b) 你和整个市场太像，市场高度饱和，产品本身缺少明显差异化，属于大量重复出现的常见类型。

图：4.3(a) 与 4.3(b) 的常见区分；Apple 公开发布的 4.3 是单一一条带要点清单，(a)/(b) 是社区基于拒审原文的归纳。

我的拒审明确属于 4.3(a)，而且 Apple 特别点名了 terminated account。所以这篇文章不去讨论"英语学习 App 是不是太多了"那种 4.3(b) 的解释，那不是我遇到的场景。

AI 编程，会不会让 App 越来越像

这是我最想聊的部分。

用 AI 写代码的过程中，确实注意到一些事情。

AI 喜欢生成类似的工程结构。MVC 还是 MVVM，目录怎么分、网络层怎么抽，模型给出来的"默认答案"相当一致。常见页面像首页、播放页、列表页、详情页的命名也越来越像。

相同的技术栈、相同的 UI 框架、相同的第三方 SDK，本来就普遍。一个英语听力 App 用 AVFoundation 播音频，目录里同时有 SQLite 缓存和 JSON 配置，这种组合在同类产品里几乎人手一份。

大量开发者在用相似的 Prompt。"做一个 SwiftUI 听力 App，支持精听、跟读、字幕"这种描述，AI 生成的代码大概率会往同一个方向收敛。

这些趋势单独看都合理。合在一起，就出现了一个新的问题：当越来越多 App 由 AI 辅助生成，工程结构、UI 形态、常见功能越来越趋同，传统的 Spam 检测机制，会不会更容易把原创项目判断为模板化或重复？

这个问题目前没有答案。我自己的判断分两层：

第一层，目前没有证据表明 Apple 会因为"AI 生成代码"这件事本身去拒一个 App。拒审理由里没写过。

第二层，但 AI 生成的代码确实在很多维度上和"其他 AI 生成项目"长得更像。这意味着，即使两个团队互不相识、完全从零开始，也可能做出在某些维度上高度相似的 App，这是 (a) 和 (b) 之间新出现的一片灰色地带。

图：传统马甲包 vs AI 辅助独立开发的对比，二者触达"相似"的路径完全不同。

我找到了几个几乎一样的案例

"只有我一个人被这样拒过吗？"这是拒审之后第一个想查的问题。翻了一圈下来，发现这种拒审并不稀罕，而且很多人描述的情况比我的更让人无奈。

下面这些都来自 Apple 开发者论坛（Apple 自己的官方开发者社区）的公开帖子，先标注一下：这是开发者在论坛中的自述，不是 Apple 已经确认的事实。我尽量保留账号名 + 完整原话，方便你自己去原帖核对。

第一个，开发者 Dasaev_Magomed 在 thread 757046 里，开头就写"I created the application from scratch"（我是从零做的这个 App），但收到的拒审原文和我几乎一字不差，连"terminated Apple Developer Program account"这句都没变。截图来自论坛原帖：

第二个，开发者 NEURALABZ 在 thread 741593 里写道"The application is 100% developed by our team"（这个 App 100% 是我们团队开发的），UI 改过、名字改过、描述也改过，提交之后几秒钟又被打回 4.3。原帖截图：

第三个更让人头疼。开发者 Alialev 在 thread 807849 里描述的是这种版本：App 之前已经在 App Store 上线，之前还通过过审核，后来一次只修了 Bug 的更新突然命中 4.3。原帖里他自己说"That update was ultimately approved, and the app has been live on the App Store since then without any issues. However, our new submission—which includes only a critical bug fix—is now being rejected again for the same 4.3 reason"。截图：

第四个是独立开发者 Dmitrii_Fozer，在 thread 843096 里记录了 5 次 4.3(a) 拒审：自己写了一套物理引擎，自己写了 UI，数百个脚本全是项目专属，电话沟通时被告知是"binary match with another developer's game"，但没人说得清具体和谁匹配；第 5 次拒审甚至换了一种说法，改成指向"concept and look 与饱和品类相似"。

把这四个帖子并排看，有三件事值得拎出来。

第一，开发者做了什么并不重要。Dasaev 是从零开发，NEURALABZ 是 100% 自研团队代码，Alialev 的 App 此前已经在 App Store 上线且通过审核，Dmitrii 有完整自定义引擎和数百专属脚本。四个人的代码来源、团队结构、上线历史完全不同，但都撞上了同一句"terminated Apple Developer Program account"。

第二，审核口径会漂移。Alialev 的 App 同一份 codebase 之前能过审、之后不能；Dmitrii 同一份拒审邮件，前两次措辞指向"binary match"，第 5 次改成"concept and look ... saturated category"。相似性比对的边界不是静态的，是会随时间和相似图谱变化而移动的。这意味着一个 App 今天的"安全"，不等于明天的安全。

第三，拿不到具体说明。四个开发者都被拒，但没有人被告知"具体是和哪个 App 相似""在哪个维度上相似""需要改哪一个文件"。Dmitrii 走了电话沟通这条路，得到的回答是"similarities could come from game code, assets, shared engine code, ad SDKs, third-party libraries"——这是一个维度清单，不是一个具体诊断。

苹果可能在比较什么（以及为什么"从零开发"也救不了你）

下面这部分是我自己的推测，Apple 没有公开过其 Spam 检测的内部机制；到底哪些维度实际参与、权重多少，目前无法确认。但既然上面四个案例已经证明"从零开发"和"完整自查"都救不了独立开发者，那就有必要把这条推测链讲透。

图：基于公开拒审措辞与开发者讨论的归纳，不是 Apple 已确认的审查流程。

我的推测是，Apple 的相似性比对不是一条规则，而是一张相似性图谱。它大致按这条链工作：

第一步，给每个 App 算一个签名。这个签名大概率不是源码级的逐行比对（那对性能不友好，也容易误伤），而是若干维度的特征向量化：二进制结构哈希、第三方 SDK / 依赖列表、内置资源指纹（音频、JSON、SQLite、字幕结构）、Metadata 向量（截图、描述、关键词）、以及某种"概念向量"（功能清单、UI 模式）。

第二步，算两两相似度。在这个签名空间里，每两个 App 都有一个相似度分数。这个分数来自特征向量的距离，可以是余弦相似度、Jaccard、或者某种 embedding 距离。关键是这个空间是连续的——不是"相同 / 不同"二值，而是 0 到 1 的连续值。

第三步，触发相似性聚类。当一个新提交 App 和某个"被终止账号历史提交过的 App"在这个空间里的距离足够近，就触发 4.3(a) 拒审。注意这里说的"近"，可能不是直接命中同一个 App，而是命中和那个被终止账号相关的某个聚类。

这就引出了一个对独立开发者真正危险的可能性："近"不一定来自代码复用，也可能来自"大家都在用同一套基础设施"。

同一个 SwiftUI + AVFoundation + SQLite + 某广告 SDK 的组合，在 N 个独立开发者手里会算出高度相似的签名。同一个 AI 工具给"做一个英语听力 App"生成的默认工程结构、目录命名、网络层抽象，在 M 个独立团队手里也会算出高度相似的签名。当 N 和 M 都足够大的时候，一个从零开发的独立 App，在签名空间里很容易落到某个已经被终止账号"污染"过的聚类附近。

这条路要成立，前提是 Apple 的相似度计算足够激进地把"共性基础设施"也算成"相似"。论坛案例 thread 843096 里电话沟通被告知的维度清单（code, assets, shared engine code, ad SDKs, third-party libraries）至少说明："共用第三方代码"在 Apple 的相似性判断里是有分量的。而独立开发者几乎不可能不用第三方 SDK。

这不是在指控 Apple 在做"代码指纹比对"。这是说：只要相似性图谱是基于特征向量的，AI 编程时代带来的"工程结构趋同"就会把大量无关 App 拉进同一片高密度区域。终止账号处理得越狠、留下的相似性黑名单越密，独立绘图者的误伤面积就越大。

这条链是推测。但它能解释为什么 Dasaev、NEURALABZ、Alialev、Dmitrii 这四个完全不同的开发者，撞上了几乎一模一样的拒审。

为什么这事比它看起来更难接受

把上面这些放在一起，这事最难接受的不是拒审本身，而是它背后的结构性不对称。

第一，否决被自动化，且不公开。 Dasaev 的拒审邮件里没有"具体是哪个 App 和你相似"。Dmitrii 走了电话沟通，得到的也只是维度清单。独立开发者不知道"我被比对了什么"，也就不知道"我应该改什么"。这不是"没通过"，是"被判了而不知道判词里写的是什么"。

第二，账号层面的风险是真实的。 拒审邮件里夹了一段 Extended Review 的警告：反复提交存在这些问题的 App，可能延长审核时间；如果账号反复提交违反审核指南或 ADP 协议的 App，可能最终被移除出 Apple Developer Program。换句话说，一次误判不是"再改改"的代价问题，而是"账号存续"的风险问题。

第三，对独立开发者没有安全通道。 Apple 给企业账号、知名开发者的申诉通道不止 Resolution Center 一条，但个人开发者和小团队基本只有 Resolution Center 这一个入口。Dmitrii 描述的"打了十几个电话、开了好几次会"，已经是非常主动的争取；很多开发者连这一步都没走到。

这三件事叠在一起，构成了 AI 编程时代一个真实但很少被讨论的治理问题：平台用相似性检测反 Spam 是合理的，但当检测维度开始捕获"共性基础设施"和"AI 默认答案"这类非行为信号时，独立开发者就被卷进了一场他们没有参与的对抗。

我为什么最后决定不上架

这件事的最后一步不是继续提交。

反复改、重新打包、再次进入 Extended Review，每一次都要花时间，而且每一次都带着"账号可能被进一步处置"的风险。对一个还没上架、商业价值还没验证过的 App 来说，这笔账越来越不值得。

最后我决定：不继续提交，不上传新 Build，不改 Bundle ID 重新提交。我给 Apple 留了一段正式的澄清，不是为了逼它通过，也不是承认它的判断，只是为了在记录里留下这几句：

Hello App Review Team,

Thank you for your review and feedback.

We would like to clarify that this app was independently designed and developed from scratch by our company.

We did not purchase, reuse, or modify any third-party app template or source code, and we have no relationship with any terminated Apple Developer Program account.

We wanted to provide this clarification because the review message mentioned similarities to apps previously submitted by a terminated developer account.

At this time, we have decided not to proceed with distributing this app and will not resubmit it for review.

Thank you for your time and consideration.

中文意思是：这是从零开发的项目，我们不同意它和被封账号之间存在关联，但我们也决定停止提交。

止损，不是认输。

一个新的问题出现了

以前 App Store 的 Spam 问题其实很好理解。

最典型的"模板换壳"路径是清晰的：买一份模板，换个图标、换个名字、换个 Bundle ID，代码和资源高度复用，App Store 上一次能挂十几个相似的东西。这种东西被打上 4.3(a)，争议不大。

进入 AI 编程时代以后，类似的"重复"开始有了不一样的来源。

即使两个团队互不相识、没有抄任何人的代码，AI 工具在生成代码时带来的项目结构趋同、页面命名趋同、技术栈与 SDK 选择趋同，都会让不同 App 在工程和产品形态上越来越接近。再加上"English learning with listening + shadowing + subtitles"这种高度同质化的产品描述，AI 给出的实现路径本来就很集中。

这给 App Store 留下了一道新的题，而它的难度比表面看起来大得多：

未来到底应该如何判断一个 App，是"模板换壳"，还是两个开发者恰好通过相似的 AI 工具、独立做出了相似的东西？

这道题目前没有答案。这篇文章也不是要给出答案。

我只想把这件真实发生的事情写下来，留给同样在做 AI 辅助独立 App 的开发者做个参考。如果你的 App 还在审核里、或者刚刚提交，建议把这段背景提前想清楚：项目结构、第三方 SDK、课程或内容的组织方式，尽量做出和"AI 默认答案"足够明显的偏移；预留一份能证明"从零开发"的时间线记录，包括最早的 git commit、设计稿和关键决策的留存；同时做好最坏打算，因为目前的审核机制不保证"做对了就一定不被误伤"。

拒审不一定是你的代码有问题。但触发以后，能拿到的解释往往很有限。这件事本身，也许比 4.3(a) 更值得讨论。