匿名化存档

App Store 审核给团队带来的真实代价

111 个来自公开开发者帖子的拒审故事改写。不透露姓名、应用名称或来源链接。仅包含背景、已知结果以及每个故事的一个教训。

第 1 批 · 44 个案例 · 更新于 2026-10-19

案例: 111
审核指南: 15
批量: 1

浏览案例

显示全部 111 个故事。

4.3(a) 垃圾内容 iOS 指南 4.3

整个应用组合同时被标记

事情经过

一位开发者有几个基于同一个初始项目构建的应用，每个应用都收到了相同的 4.3 通知：这些应用的二进制文件、元数据或概念相似，仅有细微差别。这位开发者决定逐个处理这些应用。

解决方案

发帖时仍在处理中。

经验教训

4.3(a) 也涵盖你自己应用之间的重叠。如果多个应用都源自同一个模板，每个应用都需要真正独特的内核，而不只是换个图标和名称。
4.3(a) 垃圾内容 iOS 指南 4.3

一周内两次收到同样的拒审信

事情经过

一款单一用途的摄影辅助小应用，在之前的 build 收到一模一样的拒审文案一周后，又在深夜因 4.3(a) 被拒。

解决方案

未说明。

经验教训

仅做表面改动重新提交，几乎不会改变 4.3 的判定。要么改变产品概念，要么在审核备注中清楚说明 App 有何不同。
4.3 设计 / 垃圾内容 iOS 指南 4.3

在拥挤的品类中做产品

事情经过

一位记录每日构建挑战的独立开发者，在第四天收到了 4.3 设计 / 垃圾内容的拒信，开始怀疑选择一个饱和品类是不是错了。

解决方案

未说明。

经验教训

Apple 将某些类别标记为“饱和”，这些应用会面临更严格的审查。在构建之前，而非审核之后，先验证你的应用有何独特之处。
在审核跟上之前先发修复

Capgo: 几分钟内为 Capacitor 用户推送修复，无需 Mac 即可构建签名的 iOS 和 Android App，并支持一键回滚。

来自 Martin 的人工支持

免费开始使用立即开始

14 天无限免费试用。无需信用卡 14 天退款保证。随时取消。
2.1 需要补充信息 iOS 准则 2.1

新账号的七个问题

事情经过

一个团队的首次提交因 2.1 Information Needed 被拒：对方提出了七个问题，并要求提供录屏和演示账号。如实回答后，他们发现了四个此前遗漏的问题。

解决方案

他们修复了问题并进行了回复。

经验教训

新开发者账号应当对此有所预期。提交之前，请准备好演示账号、录屏以及清晰的审核说明。
2.1 App 完整性 iOS 准则 2.1

审核员看不懂 App 怎么用

事情经过

一位首次上架的开发者在上线前被拒了两次。第一次是按 2.1 条款被拒，因为审核员搞不懂 App 该怎么用。

解决方案

补充了真机录制的演示视频和分步审核说明后，审核通过。

经验教训

审核员只有几分钟，没有背景信息。明确告诉他们该点哪里、该看到什么。
元数据与应用内购买设置 iOS 元数据与 IAP

因已知检查项被拒两次

事情经过

一位独立开发者因为自己早就知道的问题被拒了两次。第一次，提交的 build 没有附带应用内购买，描述里也没有链接使用条款。几周后，又有一张截图把 App 说成是免费的。

解决方案

每次都修复并重新提交。

经验教训

针对元数据、订阅和法律链接准备一份提交前检查清单。大多数元数据被拒都是可以避免的。
审核队列时机 iOS 无止境的审核

等待 9 天，审核又耗时 8 天

事情经过

一位开发者等了 9 天，状态才从“等待审核”变为“审核中”，随后又在审核中待了 8 天，没有任何更新。

解决方案

发布时暂无相关信息。

经验教训

审核时间无法保证。切勿将上线日期、媒体或创作者推广活动与预期的审核通过日期挂钩。
审核队列时机 iOS 无止境的审核

20 天困在拒绝、修复、等待的循环里

事情经过

20 多天里，一位开发者经历了被拒、修复、等待审核、再被拒、再修复，发帖时仍在等待。

解决方案

待处理。

经验教训

每次往返都可能耗费数天。把拒绝说明中的所有修复合并到一次 build 里。
账号终止 iOS 账号终止

首轮审核前被关闭

事情经过

一位有十年经验的开发者，开发者账号被封，还收到一项未说明具体违规行为的欺诈指控；而当时一款语言学习游戏仍在等待首次审核。其现有应用全部消失，用户开始询问原因。

解决方案

暂无报告。

经验教训

账号被封会一次性移除所有应用。请保留自己的用户渠道（邮件、网站），以便应用商店不可用时仍能联系到他们。
账号封禁警告 iOS 账号终止

被拒版本过多

事情经过

一位高产的独立开发者收到通知，称其账户将在十天内被终止。Apple 指出，被拒版本数量是原因之一。在引发公众关注并申诉后，该账户未被终止。

解决方案

申诉后账户得以保留。

经验教训

拒绝记录会累积。避免仅修改一个词或提交几乎相同的克隆应用就同日重新提交。
登录要求（未注明指南编号） iOS 登录要求

强制注册：你的 App 还没那么大

事情经过

一位开发者的社交 App 被拒，原因是要求用户在进入首页信息流前必须先创建账号。当开发者解释说每个用户都需要一个用户名才能保证 App 正常运行，并举例说明某大型照片分享网络也有同样做法时，审核人员的回复潜台词是：你的 App 还没到那个级别。

解决方案

未说明。

经验教训

大厂能蒙混过关，并不代表你可以援引为先例。如果你要求注册，请在审核备注中说明为什么核心功能没有账号就无法运行，并考虑先让审核员或游客看到部分内容。
4.3 垃圾内容 iOS 指南 4.3

从毫无审核到几乎全被拒

事情经过

一位开发者发现，自己的 App 连续几天都没进入审核。等待期间，他们又提交了更多版本。等审核终于有进展时，几乎全部都以违反 4.3 Spam 指南为由被拒。

解决方案

未说明。

经验教训

审核队列停滞并不代表你该提交更多。没有任何审核进展时堆积提交，等审核员最终一起看到这些提交，可能会让你的账号看起来像 Spam 模式。
4.3 垃圾内容 iOS 指南 4.3

无关的应用被连带拒绝

事情经过

一位开发者拥有多个应用，这些应用耗时数月开发且互不相关，却在同一时刻全部被以垃圾应用为由拒绝。他在公开场合询问这是否正常。

解决方案

未说明。

经验教训

4.3 可能适用于账号层面，而不是逐个应用。如果多个应用同时被拒，请分别回复每一个，并在审核备注中明确说明每个应用的不同之处。
审核队列时机 iOS 无止境的审核

一次被拒，然后两个月没有下文

事情经过

一次被拒后，开发者的 App 在审核中卡了约两个月，每个审核周期大约要一个月。他们怀疑，这种漫长周期已经成了把新 App 挡在门外的手段。

解决方案

发帖时仍卡在审核中。

经验教训

被拒之后，下一轮审核可能比第一次慢得多。重新提交时请确保材料完整、说明清楚，免得第二轮来回又耗掉一个月。
不当内容 iOS 不当内容

因未修复问题就重新提交而被拒

事情经过

一款 AI 照片编辑应用被拒，原因是它多次重新提交，却未修复 Apple 标记的不当内容问题。

解决方案

审核未通过。

经验教训

重复提交同一个 build、指望换个审核员，可能对你不利。重新提交前，先修复被标记的问题，或通过 Resolution Center 请求说明。对于生成式 AI 功能，要针对 Apple 认为不当的内容添加过滤器。
4.3 垃圾内容 iOS 指南 4.3

审核刚开始就被拒

事情经过

一位开发者花了数周开发 App，结果刚进入审核的同一分钟就因 4.3 Spam 被拒。他们认为审核员评判的是这个细分领域，而不是 App 本身。

解决方案

未说明。

经验教训

在竞争激烈的细分领域，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 开发者计划注册与账号

耗时两个月，最后却被无理由拒绝

事情经过

一位开发者花了两个多月尝试注册，期间多次拨打支持电话、发送多封邮件，还提交了身份验证、设备详情甚至视频证据。随后 Apple 未给出具体原因就拒绝了注册申请。

解决方案

发布时暂无相关信息。

经验教训

账号注册可能比开发 App 耗时得多。尽早开始注册，别等上线计划依赖它时才动手，并保留每次与支持团队沟通的记录。
5.1.2 数据使用与共享 iOS 指南 5.1.2

一次威胁到初创公司的 App Tracking Transparency 拒审

事情经过

在几个月的快速发版和强劲的用户反馈之后，一家初创公司的 App 在深秋因 App Tracking Transparency 被拒。这项 iOS 隐私规则要求，跨 App 和网站追踪用户前必须先获得用户许可。创始人后来称，这次拒审让整个公司陷入风险。

解决方案

文中未提及。

经验教训

提交前，请审计 App 中每一个 SDK 是否涉及追踪。只要有内容会把用户数据与其他公司的数据关联起来，即使追踪来自第三方库，你也需要追踪权限 prompt 和对应的隐私标签。
登录（未注明准则编号） iOS 登录

审核员无法使用 Apple 或 Google 登录

事情经过

为了防止机器人注册，开发者移除了邮箱和密码登录，只保留 Sign in with Apple 和 Google 登录。这在他们自己的 iPhone 和 iPad 上都能正常登录，之前的审核员也没问题——那位审核员曾因其他原因拒绝过该应用。但下一位审核员却因为无法登录而拒绝了该应用。

解决方案

未说明。

经验教训

如果你的应用只提供社交登录，审核员仍可能卡住。请在审核备注中给他们一个可用的登录方式，比如演示账号或仅限审核用的登录方式，并在每次提交前用全新设备和账号测试登录。
模拟赌博（未注明指南编号） iOS 模拟赌博

个人账户下的游戏内押注功能

事情经过

一款游戏因包含模拟赌博而被拒：玩家可以用游戏内道具互相下注，这种机制在经典在线角色扮演游戏中很常见。由于开发者是以个人账户而非公司账户发布，他们决定暂时移除该功能。

解决方案

移除该功能并重新提交。

经验教训

即使不涉及真实货币，赌博类机制也会受到额外审查，而 Apple 允许的范围部分取决于你的账户类型和证明材料。在开发押注、掉落或投注功能前，请先查看赌博相关规则，并据此规划开发者账户类型。
伪造文件（未注明指南编号） iOS 伪造文件

PDF 编辑器因用户可能的行为被指责

事情经过

一款 PDF 编辑器 App 因 Apple 称其允许用户制作伪造 ID 和虚假文档而被拒。开发者辩称，按同样的逻辑，任何银行或通讯 App 都可能因恶意用户可能用它做的事而被拒。

解决方案

未说明。

经验教训

通用工具可能会按其最坏用途来评判。避免使用看起来像官方 ID 或证书的模板或营销素材，并在审核备注中说明 App 的用途以及不支持的功能。
AI 数据共享（未注明指南编号） iOS AI 数据共享

第三方 AI 数据共享缺少用户同意界面

事情经过

某团队因向第三方 AI 服务商共享用户数据而遭遇了首次审核拒绝。Apple 要求必须获得用户的明确许可，并清晰披露发送了哪些数据以及发送给了哪家 AI 服务商。该团队最担心的是：如何在不影响转化率的前提下，设计出一个能通过审核的同意界面。

解决方案

进行中。

经验教训

如果你的 App 会将用户内容发送到外部 AI 服务，请务必在首次请求前征得用户同意，并明确说明服务商名称及涉及的数据类型。请在提交审核前就构建好该界面，而不是等被拒绝了才去补救。
Family Controls 权限（未明确注明指南编号） iOS 元数据与 IAP

因一个未勾选的复选框被拒 5 次

事情经过

一位开发 Screen Time 类应用的开发者被拒了五次。含糊的审核意见让他们以为问题出在设计上。真正的原因是他们开发者设置里有一个 Family Controls 设置没勾选。勾选后，应用就通过了。

解决方案

启用 Family Controls 设置并重新提交后，顺利通过审核。

经验教训

拒绝理由含糊时，先检查 Entitlements 和证书，再考虑重新设计产品。Screen Time 和 Family Controls 类应用需要在开发者门户中启用对应的 Capability，而不只是在 Xcode 里配置。
准则 5.1.1(v) iOS 指南 5.1.1 登录要求

设备端运行的付费功能需要账号

事情经过

一位做 Web 应用的开发者因指南 5.1.1(v) 被拒。在 Web 上，他们总是把购买和账号绑定。但在 iOS 上，购买由 Apple 掌控，买家无需注册即可付款。他们的付费层级可解锁仅在手机上运行的设备端滤镜，但解锁该层级和“恢复购买”都仍要求先创建账号。

解决方案

正在重构，让无账号完成的购买在用户之后选择注册时仍能归属到本人。发帖时仍在进行中。

经验教训

如果付费功能在设备端运行且不需要服务器身份，就让用户无需账号即可购买和恢复。只为真正需要账号的功能保留注册，比如云备份。
指南 1.4.2 人身伤害 iOS 指南 1.4.2

已上线的剂量计算 App 因规则收紧被下架

事情经过

一位开发者醒来后发现，自己的两款 App 都因指南 1.4.2 被标记，尽管它们都没有任何内容在审核中。这两款 App 均已上线：一款是独立的肽类剂量计算器，另一款是内置了相同计算功能的追踪器，它们共同构成了开发者首个真正意义上的营收成功。同领域的其他开发者也同时收到了同样的通知。通知称，计算药物剂量（包括肽类剂量和复溶）的 App，必须由制药商或受认可的机构（如医院、保险公司、药房或大学）发布。

解决方案

无。开发者表示理解安全顾虑，并认为这两款 App 就此终结。

经验教训

审核通过并非永久有效。Apple 收紧规则时，可能会重新评估已上线的 App。如果你的 App 会计算剂量，或提供可能伤害他人的健康指导，请在开发前阅读指南 1.4，并计划通过有资质的机构发布，或者不包含计算功能。
指南 4.3 Spam 和 4.2.6 App 生成服务 iOS 指南 4.3 指南 4.2.6

又一款离线票务 App 被指 Spam

事情经过

一位开发者开发了一款小应用，能把电子表格变成完全离线运行、无需账号和订阅的票务与签到系统。今年夏天，它已为一场数百人参加的本地活动处理入场。然而，Apple 再次以 4.3 和 4.2.6 的合并通知拒绝了它，称它可能与商店中已有的应用重复、属于竞争激烈品类中的投机性变体，或者源自模板或 App 生成服务。开发者表示，他们并不知道有其他应用具备相同功能，且 Android 版本已经上线约一周。

解决方案

发帖时仍被拒。开发者表示，反正他们也没打算靠 App Store 赚钱。

经验教训

审核 4.3 的审核员只会看你的商店详情页和几分钟的 App 体验，看不到你的真实用户。如果 App 确实与众不同，就在审核备注和首批截图里具体说明不同在哪，提到实际使用场景，并明确声明你没有使用模板或 App 生成器。
准则 5.6.4 App Quality Apple 开发者计划指南 5.6.4

退款率上升导致打款冻结

事情经过

一位运营快速增长订阅应用的开发者一觉醒来，收到 Apple 的警告，称其开发者账号违反了准则 5.6.4 App Quality 下的开发者 Code 行为准则。通知指出退款请求和客户投诉过多，警告账号可能被终止，并表示所有收益打款已暂停、应用转让被禁用。过去两个月，退款率大约翻了一倍。开发者深入分析数据后发现，大多数退款请求被标记为“非预期购买”，他们认为这主要来自用户忘记取消 3 天免费试用，而试用会自动转为年度计划。警告到来时，应用的大规模改版已经在测试中。

解决方案

截至发稿仍未解决。开发者在试用期内增加了更多提醒，让即将扣费更醒目，在应用内加入了管理和取消订阅的入口，完成改版并做了更多测试，同时在等待期间暂停了所有付费创作者营销。

经验教训

Apple 不只看你的二进制文件，还会看退款率和投诉。免费试用悄悄变成年度扣费，用户一多就可能演变成大规模的非预期购买问题。在试用结束前提醒用户，清楚展示真实价格，让取消更简单，并在 Apple 动手之前，就把上升的退款率当成账号风险。
元数据与应用内购买设置 iOS 元数据与 IAP

因为一张控制台删不掉的图片，被拒了三次

事情经过

一名开发者在 App Store Connect 里给订阅添加促销图片时，不小心把同一张图片加了两次。之后这张图片既删不掉也换不了，每次尝试都只报一个通用错误，提示稍后重试。这个 App 因为这项订阅设置被拒了三次。每次开发者都附上删除尝试和报错的录屏，但感觉审核人员都忽略了。开发者认为根因是 App Store Connect 本身的 bug。

解决方案

发帖时仍卡着，Apple 也没给修复方案。

经验教训

当 App Store Connect 本身阻碍修复时，在拒绝线程里的回复可能根本到不了能解决问题的人那里。订阅图片要谨慎上传，而且只上传一次；如果控制台出问题，在回复 App Review 的同时，另外联系 Apple developer support 反馈这个 bug。
准则 4.3 Spam iOS 指南 4.3

一款为经营一家健身房而开发的 App 被拒三次

事情经过

一位开发者为经营自己的健身房开发了一款 iOS App，前后提交了约 176 次 commit。Apple 在 9 月 29 日拒绝了它，10 月 7 日再次拒绝，10 月 13 日又以准则 4.3 Spam 为由拒绝。当天，这位开发者回答了 App Review 发来的全部 9 个问题。六天后的 10 月 19 日，仍然没有收到任何回复。其 App Store Connect 应用列表显示，同一账号下另外几个应用也同时处于被拒状态，iOS 和 macOS 上都有。

解决方案

发帖时仍未解决，提交回答后没有收到 App Review 的任何回复。

经验教训

4.3 衡量的不是投入程度或提交次数。如果应用确实是为某一业务打造的，不公开上架可以让它不出现在搜索中，但任何拿到直接链接的人仍可访问；Custom App 分发则只向指定组织开放。请选择符合所需访问控制的方案。若要公开上架，请在首屏、截图和审核备注中清楚说明应用与现有应用的不同之处。
指南 5.6 开发者 Code 行为准则与 2.5.19 隐藏功能 iOS 指南 5.6 开发者 Code 行为准则指南 2.5.19 隐藏功能

因遗留测试开关被以欺诈为由拒绝

事情经过

2026 年 9 月，一名开发者因违反指南 5.6《开发者 Code 行为准则》导致 iOS App 被拒。Apple 表示发现了其认定为与欺诈相关的行为模式，具体来说，是一些看起来在审核期间被故意隐藏的功能。开发者追查到问题来自发布 build 中遗留的三个测试开关：一个用于截取商店截图的模式、一个模拟缓慢 entitlement 检查的开关，以及一个解锁模拟购买的开关。App Store 版本的普通用户都无法触达其中任何一个。在 Apple 10 月 16 日的 App 审核指南更新中，隐藏、休眠或未记录的功能被单列为指南 2.5.19，Apple 表示违反该指南可能危及整个开发者账号。

解决方案

该开发者现在会在上传每个 release archive 前检查其中的字符串。至于那个 build 后来是否通过审核，文中并未说明。

经验教训

在编译时就把仅用于测试的 code 排除在发布构建之外，比如用 DEBUG 标志，而不是靠运行时检查。检查归档后的二进制文件里实际打包了什么，并列出仍留在 App Review 备注中的开关。
2.1 需要补充信息 iOS 准则 2.1

审核暂停，直到 Apple 明确应用的目标用户

事情经过

一位开发者提交了 iPad 应用的 1.0 版本，但审核因准则 2.1（Information Needed）被暂停。没有崩溃报告，没有功能故障，也没有要求修复二进制文件。Apple 只是要求在继续审核前，详细回答一个问题：谁会使用这款应用。

解决方案

Apple 要求先说明目标用户是谁，才能继续审核。

经验教训

把受众和使用场景当作评审输入，而不是之后能补的营销文案。提交第一版前，先写清楚目标用户是谁。
4.3 设计 / 垃圾内容 iOS 指南 4.3

在饱和的音频应用品类中差异不足

事情经过

一款娱乐音效 App 因 Guideline 4.3(b) 被拒。Apple 表示商店里已有足够多类似 App，将该产品视为饱和类别中的重复内容，尽管团队认为额外功能让它与众不同。

解决方案

因在竞争激烈的类别中差异化不足，依据 4.3(b) 被拒。

经验教训

在 Apple 称为饱和的类别中，新颖性必须在审核开始的第一分钟就足够明显。要主打真正独特之处，而不是审核员见过很多次的噱头。
元数据与商店详情页文案 iOS 元数据与 IAP 无止境的审核

吞噬了上线周的元数据死循环

事情经过

一个面向消费者的效率工具团队提交了干净的 build，随后却花了九天多时间在元数据驳回中反复打转。每次重新提交都回应了上一条意见，但下一条回复又盯上了另一个措辞、截图或说明。code 始终没变，而上线、媒体宣传和付费获客计划都在等审核文案。

解决方案

未改动 binary，仅重写截图、副标题和审核备注后就通过了审核。

经验教训

在定下上线日期前，一次性锁定商店页文案、截图和审核备注。即使 binary 完全没动，元数据驳回也可能接连出现。
出口合规（App Store Connect） iOS 元数据与 IAP

审核通过后，又被另一个合规问题卡住

事情经过

一个 B2B dashboard 配套构建已通过审核，但团队以为出口合规问题已经回答，合规 prompt 却又出现，发布仍被卡住。发布负责人停止了 rollout，收集了法务措辞，更新了 App Store Connect 中的回复，又等了一轮审核；而客户在应用上线前就看到了公告。

解决方案

在再次回答出口合规问题并等待下一轮审核后发布。

经验教训

将出口合规视为发布门禁，而不是一次性勾选框。在宣布发布日期前，确认 App Store Connect 显示为可发布状态。
Google Play 权限与政策审核 Google Play 元数据与 IAP 无止境的审核

权限政策的时间黑洞

事情经过

一款外勤 Android 应用因某个页面使用了一个范围很窄的权限，触发了大范围的政策审查。团队记录了该功能、添加了审核员说明、录制了演示路径，但 13 天后仍不得不从主版本中移除该权限，才能让客户继续使用。

解决方案

在移除权限、重新录制 Demo 并重写商店声明后，终于通过了审核。

经验教训

先把敏感权限限制在可上线的最小范围。在 Google Play 上，单个权限就可能触发完整的政策审查。
Google Play 审核排队时间 Google Play 无止境的审核

被卡在政策审核队列中的热修复

事情经过

一家电商团队需要快速修复结账 bug，但商店发布版本偏偏在最糟糕的时候卡在审核里六天。状态一直停在待处理，支持工单却不断攀升。他们先做了服务端缓解，随后只能眼看着二进制包在紧急状况已经耗掉一个周末后才通过审核。

解决方案

在团队通过其他方式缓解故障后，原生商店的修复方案才姗姗来迟。

经验教训

应用商店审核不是事件响应渠道。在二进制文件排队等待审核时，请为紧急生产环境 Bug 保留非商店的缓解路径。
指南 3.1.1 App 内购买项目与 3.1.3(f) 免费独立应用 iOS 指南 3.1.1 指南 3.1.3

配套 App 因试用期结束被拒

事情经过

一位开发者为其付费 Web 邮件服务发布了一款免费的 iOS 配套 App。App 内不销售任何东西。开发者向 App Review 指出，这符合 3.1.3(f) 中针对免费独立配套 App 的豁免规定，但该 App 仍被拒了四次。他们提起申诉，App Review Board 维持了拒审决定。理由是：该服务提供 14 天免费试用，因此对 iOS 用户来说，App 在 14 天后就没什么用了，算不上真正的独立体验。Apple 给出两条路：要么让 App 有足够的免费内容和功能，能够独立使用；要么让 App Store 用户通过 In-App Purchase 购买该服务。开发者指出，某款知名邮件 App 似乎也采用同样的 14 天限制。

解决方案

截至发稿时仍未解决。申诉失败后，开发者正在权衡是提供最低限度的免费层级，还是加入 In-App Purchase。

经验教训

3.1.3(f) 配套 App 豁免条款的适用范围很窄。如果你的 Web 服务设有限时试用，试用结束后，Apple 可能会把 App 视为变相的付费墙。提交前，先想清楚试用结束后用户还能在 App 里免费做什么，或者规划好 In-App Purchase。指出其他 App 似乎也这么做，很少能赢得申诉。
准则 3.1.1 App 内购买项目 iOS 指南 3.1.1

自带 API 密钥被视为在 App Store 外付费

事情经过

一位独立开发者正在为 iPhone 开发 AI 助手，他让用户从第三方模型聚合器粘贴自己的 API 密钥，以便运行大型云端模型。在第四轮审核中，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

因选出胜者被拒的穿搭对比应用

事情经过

一位独立开发者上线了一款对比两套穿搭的 AI 应用。对比完成后，应用会宣布其中一套造型“胜出”。App Review 依据指南 1.2 拒绝了该应用，认为这个结果是在给人排名，而不是给衣服排名。开发者认同这一顾虑。

解决方案

他们删除了所有“胜者”措辞、胜者徽章，以及任一选项上更大的分数或高亮颜色，因此两套造型现在视觉权重相同，各自获得独立反馈，由用户自行决定。修复后的 build 是否通过审核，未透露。

经验教训

Apple 评判的是界面的观感，而不只是功能。如果你的应用给任何与外貌相关的内容打分，展示反馈时不要带排名，并假设会被最严苛地解读。
儿童类别、指南 3.1.2 和隐私问题 iOS 儿童类别指南 3.1.2 无止境的审核

一款儿童故事 App 被拒一个月后仍在等待审核

事情经过

一位独立开发者为 4 到 10 岁的儿童做了一款故事 App，孩子可以听故事，也能暂停提问。该 App 已在 Android 上线数周。开发者于 2026 年 9 月 19 日提交到 App Store。经过多轮拒绝和重新提交，大约一个月后仍未获批。最新一轮审核中，Apple 提出两点要求：由于该 App 提供周订阅、月订阅和年订阅，App Store 页面需要一个可用的使用条款 (Terms of Use) 链接；另外，由于该 App 属于儿童类别，开发者必须先回答四个问题，审核才能继续：第三方分析、第三方广告、是否与第三方共享数据及数据存储位置，以及是否收集其他用户或设备数据及其用途。

解决方案

开发者修复了这两个问题并重新提交。发帖时结果仍未公布。

经验教训

对于儿童、健康、金融或教育类 App，请尽早了解当地隐私法和应用商店会提出哪些要求，例如收集儿童数据前需获得家长同意，并在首次提交前准备好使用条款链接和书面的数据说明。
指南 5.1.1(v) 和 3.1.2 iOS 指南 5.1.1 指南 3.1.2

1.0 版本因登录、购买及注销流程被拒

事情经过

一位开发者的 1.0 版本因三个问题同时被拒，而这些问题都与 App 的核心创意无关。在使用 Sign in with Apple 后，App 仍要求用户输入 Sign in with Apple 已经提供的姓名。账号注销必须能在 App 内发起。订阅与支持页面必须显示价格、续订条款以及服务条款链接。开发者自己的总结是：这三个问题都围绕登录、购买和注销。

解决方案

未说明。

经验教训

在首次提交前，请像审核员一样走一遍登录、购买和注销账号的流程。这三个流程是导致首次审核被拒的高发原因。
指南 5.2.3 音视频下载 iOS 指南 5.2.3 音视频下载

复古网络电台因第三方音频版权被拒

事情经过

一位独立开发者那款复古风格网络电台 App 的 1.0 版本在第五次构建时，因违反指南 5.2.3 被拒。该指南适用于播放或下载第三方来源音视频的 App，并要求开发者提供拥有这些内容权利的证明。次日，开发者在 Resolution Center 回复，解释了内容版权问题。

解决方案

发帖时结果尚不明确。

经验教训

如果你的 App 流媒体播放你不拥有的电台或媒体，请取得授权，或使用条款明确允许 App 播放的来源，并在提交前将这些证明文件放入审核备注。
指南 4.3 (Spam) iOS 指南 4.3

六次被拒，随后被贴上 4.3 Spam 标签，等了两周才等到电话沟通

事情经过

一位独立开发者为他的首款 App 投入了数月心血，这款 App 本意是作为社交场合的破冰工具。然而它却被拒绝了六次，最后一次甚至因 Guideline 4.3（Spam）被拒，尽管开发者认为它比商店里已有的同类 App 提供了更多功能。他向 App Review 申请了 1 对 1 电话沟通。一周过去，没有任何回复，直到 4.3 被拒约两周后，电话才终于打来。通话后，开发者感觉 4.3 现在被用来标记那些看起来像低投入、AI 生成的克隆 App，而他坚称自己的 App 并非如此。

解决方案

开发者已提出申诉。截至本文撰写时，申诉仍在处理中。

经验教训

在竞争激烈的品类中，审核人员会根据截图、描述和首次使用体验来判断。要在这些地方清楚体现与现有 App 的差异，并尽早申请 App Review 通话，因为约到通话可能要一周甚至更久。
未接受协议（未注明具体指南） iOS 注册与账号

排队一周，因未签署协议被拒，然后又等了一周

事情经过

一款 App 等待审核约一周后被拒，原因与 App 本身无关：账号尚未在 App Store Connect 中接受新发布的协议。开发者接受协议并重新提交后，提交又回到队列，大约再等了一周。开发者支持团队只回复说一切正常。

解决方案

截至本文撰写时，仍在等待审核。

经验教训

每次提交前，请检查 App Store Connect 是否有待接受的协议。漏掉一次点击，就可能让你重新走一遍整个审核队列。
审核期间崩溃（未说明具体指南） macOS 准则 2.1

因在开发者尚未安装的 macOS 版本上崩溃而被拒

事情经过

一款 Mac 应用因在 macOS 27 上崩溃而被拒，而开发者当时还没用上这个版本，也不想在主力机上安装。在寻找复现崩溃的方法时，他们发现 Apple 的 Virtualization framework 可以在 Apple silicon 上免费运行 macOS 虚拟机，于是搭建了一台来测试新版本。

解决方案

除在虚拟机中复现崩溃外，未提及其他内容。

经验教训

App Review 会在最新的 OS 上进行测试。建议常备一个运行最新 macOS 的虚拟机，这样无需升级主力机即可复现审核过程中的崩溃。
审核延迟（未引用具体指南） iOS 无止境的审核

两次申请加急后，仍处于“等待审核”状态长达 12 天

事情经过

一位已有应用在 App Store 获批上架的开发者，提交了新应用的 1.0 版本，以及一个包含五项订阅的订阅组。12 天后，该应用仍处于“等待审核”状态，而通常预期不到 48 小时。他们两次申请加急审核，联系支持团队未获回复，还尝试预约 App Review，但被拒绝。

解决方案

截至本文撰写时，仍在等待。

经验教训

不要按 48 小时的平均审核时长来规划发布日期。带订阅的首个版本要留出几周缓冲；加急申请和预约只能当作可能，而不是保证。
权限弹窗 + 截图元数据（常被引用的 5.1.1 和 2.3.7 规则） iOS 指南 5.1.1 指南 2.3.7

上线首周：自定义“允许”界面和截图中的价格

事情经过

上线首周，这个 App 被拒了两次。第一次是因为它在系统权限弹窗之前先展示了自己的“允许”界面，Apple 不接受这种做法。修复后，第二次被拒是因为 App Store 截图里出现了价格。两处修复都不大，但每次重新提交都要在审核队列里多等大约一天。

解决方案

开发者修复了这两个问题，并把这两条规则记录在项目里，避免再次发生。

经验教训

可以用预权限界面说明为什么需要访问权限，但唯一的“允许”选项要留给系统弹窗。截图里不要出现价格，每次提交前过一遍简短的检查清单。
审核延迟（未引用具体指南） iOS 无止境的审核

审核卡了十天，重新提交后半小时就通过了

事情经过

App 在审核中卡了十多天没动静。开发者重新提交了。

解决方案

重新提交后大约 30 分钟就通过了。

经验教训

审核停滞并不一定意味着你的 App 会被拒。如果审核时间远超常规，重新提交或申请加急审核值得一试，但都不保证有效。
4.3(a) 垃圾内容 iOS 指南 4.3

七款模板应用在同一分钟内因 4.3 准则被拒

事情经过

一支小团队在同一周内提交了七款基于同一模板的应用送审。结果这七款应用都在同一分钟收到了完全相同的 4.3(a) spam 拒审通知，其中两款此前从未被拒过。团队由此得出结论：Apple 判定的是整批应用，而不是逐个应用。

解决方案

该团队现在每次只提交一款应用。

经验教训

共享同一 codebase 的应用如果一起提交，可能被看成 spam 模式。请错开提交时间，并让每款应用在功能、设计和元数据上明显不同。
准则 2.3.6 iOS 准则 2.3.6

Connect 已匹配却仍因年龄分级被拒

事情经过

一款 App 因年龄分级被拒。开发者打开 App Store Connect 的年龄分级问卷，发现所有回答都已经和拒审说明里的要求一致。

解决方案

他们没在 Connect 里改任何东西，直接回复审核员说设置已经匹配，然后重新提交。几小时后，App 就通过了审核。

经验教训

2.3.6 的说明可能与你当前的设置不符。改动前先检查 App Store Connect；如果已经匹配，就在回复里明确说明，别靠猜来改。
Guideline 2.1 需要提供信息 iOS 准则 2.1

审核记录有限：真机录屏及付费功能演示

事情经过

一款已通过 Google Play 审核的应用，却因 2.1 需要提供信息被退回。Apple 表示该开发者账号的审核记录有限，要求提供真机录屏、付费功能演示，并书面说明应用的功能以及依赖哪些外部服务。

解决方案

发帖时开发者正在准备录屏和回复。结果尚不明确。

经验教训

通过 Google Play 审核并不代表能稳过 Apple。如果你的开发者账号较新或过往提交记录较少，请在提交前准备好真机录屏、付费功能演示以及第三方服务清单。
指南 2.1、2.3.2 和 5.2.3 iOS 准则 2.1 指南 2.3.2 指南 5.2.3 音视频下载无止境的审核

首次提交：一个月内先后被 2.1、2.3.2 和 5.2.3 拒绝

事情经过

一位开发者第一次提交，等了六天后因 2.1 被拒。当天就回复了。十二天后再次被拒，这次是 2.3.2。他们重新提交，九天后又因 5.2.3 被拒。他们当天再次回复，两天后仍在等待。每一轮引用的指南都和上一轮不同。

解决方案

首次提交已过一个多月，仍在等待。

经验教训

每一轮审核都可能冒出新的准则，每次都可能耗上一周甚至更久。首次提交前，先读元数据规则 (2.3) 和适用于你的内容权利规则 (5.2)，而不只是完整性规则 (2.1)，并在一次 build 中修复所有能发现的问题。
准则 4.2 最低功能要求 iOS 指南 4.2

祈祷 App 因被判定为“本质上是一本书”而依据 4.2 被拒

事情经过

一款宗教祈祷与灵修 App 依据 4.2 被拒，理由是其本质上是一本书。开发者指出，该应用包含日历、祈祷次数追踪器、冥想计时器、可分享的收藏集、主屏幕小组件和语音搜索等交互功能。

解决方案

未说明。

经验教训

如果审核人员把你的 App 当作静态内容来看，交互功能可能在审核开始的头几分钟里都看不到。请在首屏和截图中展示这些功能，并在审核备注中列出它们，同时说明如何进入每一项功能。
指南 2.3.10 iOS 指南 2.3.10

排队 13 天，却因 Android 在 7 分钟内被拒

事情经过

一位开发者在审核队列中等待了 13 天，每天查看 App Store Connect 和邮件，并提交了两次支持请求。审核终于开始时，应用约 7 分钟后就被拒了，原因是 App Store 描述称该产品可在 iPhone 或 Android 的任何浏览器上运行。

解决方案

他们删除了对另一个平台的提及，只改了一行文字并重新提交。目前尚未反馈结果。

经验教训

Apple 会拒绝提及其他移动平台的元数据。提交前，请检查描述、截图和推广文案中是否出现竞品平台名称，因为一个小措辞问题就可能让你白等一整轮审核队列。
准则 5（法律） iOS 指南 5 法律

因元数据提及 OpenAI 在中国区被拒（Guideline 5）

事情经过

一款 AI 应用因元数据提及 OpenAI，依据 Guideline 5（法律）被拒。Apple 解释称，中国要求生成式 AI 和深度合成服务获得政府许可证，而 ChatGPT 没有该许可证；开发者要么从中国区 App Store 的名称、副标题、宣传文本、描述和截图中移除 AI 功能及所有 OpenAI 或 ChatGPT 引用，要么停止在中国大陆分发。

解决方案

开发者建议，在提交提到这些服务的应用前，先在“可用性”中取消勾选中国大陆商店，这样能省下一个审核周期。

经验教训

如果你的应用基于生成式 AI 服务构建，请提前决定是否在中国区上架。被拒的原因在于商店区域和元数据，而不只是你的 code。
指南 3.1.2 iOS 指南 3.1.2

应用内有条款链接，但描述中缺失

事情经过

一款订阅应用的首个版本在提交两天后被拒，原因是 App Store 描述里没有使用条款链接。该链接其实已经在应用内的付费墙和设置中，只是没写进那个元数据字段。

解决方案

修复只用了五分钟，但重新提交后，build 在“Waiting for Review”状态卡了十多天，毫无回应。目前尚无相关报告。

经验教训

对于自动续期订阅，首次提交前就要把使用条款 (EULA) 和隐私政策链接放进 App Store 元数据和 App 内，因为一个小修复也可能换来漫长的二次等待。
账号终止 iOS 账号终止

账号因 3.2(f) 条款被终止，待结算收益尚未支付

事情经过

一名开发者的 Apple Developer 账号根据《开发者计划许可协议》第 3.2(f) 条被终止。近三个月后，其待结算收益仍未支付，于是询问其他开发者：是否有人在账号终止后收到过被扣留的收益？

解决方案

暂无报告。

经验教训

账号被封不仅会冻结未来销售，还会冻结你已赚取的收入。留足现金跑道、收款记录和自有用户渠道，别让一次账号处置终结整个业务。
指南 2.1 和 5.1.2 iOS 准则 2.1 指南 5.1.2 无止境的审核

审核 25 天后，同时收到 2.1 和 5.1.2 拒审通知

事情经过

一位独立开发者提交了 iOS 应用的第一个版本 1.0。大约 17 天后，该 build 仍在审核中。总计约 25 天后，App Review 在同一次决定中，根据准则 2.1 App Completeness 和准则 5.1.2 Data Use and Sharing 拒绝了该版本。随后，App Store Connect 阻止了该次提交中其他所有项目，直到被拒版本修复为止。开发者表示，所提到的问题很容易修复；真正痛苦的是，重新提交后还要再等两到三周。

解决方案

他们修复了这两个问题并重新提交。下一次审核的结果未见报道。

经验教训

当审核队列排这么久时，每次拒绝都可能耗掉数周。提交前，请完整过一遍完整性检查：没有断掉的流程、有可用的 demo 账号、没有占位内容，并确保隐私回答和任何 SDK 数据共享都与应用实际行为一致。
准则 2.3.1(a) iOS 指南 2.3.1 元数据与 IAP

真钱投注依据 2.3.1(a) 以隐藏内容为由被拒

事情经过

一位开发者开发了一款习惯与自律追踪应用，用户可以投入资金，若未达成目标则会损失这笔钱。2026 年 10 月中旬，App Review 根据指南 2.3.1(a) 拒绝了该应用，理由是应用包含隐藏功能，特别是元数据中未描述的资金质押和质押金没收机制。通知中还附带了 Extended Review 警告，提醒重复提交此类问题会导致审核时间延长，且持续违规的账号可能会被移出 Apple Developer Program。该应用总共被拒五次，另一次的理由是在 iPad 上审核时发生崩溃。这位使用 AI 编程工具开发应用的开发者总结了经验教训：仔细阅读指南、确保元数据与应用内容一致、绝不隐藏功能或数据收集行为、检查生成的 code，并在不同设备上进行测试。

解决方案

除了在五次被拒后重做应用外，没有更多说明。未提及审核通过。

经验教训

任何涉及真实资金流动的功能，包括质押或没收，都必须在描述和 App Review 备注中写清楚。即使你只面向 iPhone，也要在 iPad 上测试，因为审核人员会这么做。
指南 4.3(a) iOS 指南 4.3

新功能、新截图，三分钟内就收到带警告的 4.3(a) 拒绝

事情经过

一位开发者花了约两个月从零开发一款 App，却因 4.3 Spam 被拒。下一轮他们加了新功能、换掉所有截图、针对更多设备尺寸做了优化，并附上审核备注和高级测试账号重新提交。App 进入审核仅三分钟后，又因 Guideline 4.3(a) 被拒。这次拒信末尾还附了延长审核通知：反复提交此类问题会拉长审核时间，持续提交这类 App 的账号还可能被移出 Apple Developer Program。由于担心再提交一次可能赔上整个账号，这位开发者正在纠结：是放弃这款 App，还是申请与 App Review 通话。

解决方案

截至发帖时仍未解决。

经验教训

一旦收到延长审核通知，快速重新提交就是最冒险的举动。先申请与 App Review 通话，弄清楚他们认为哪里过于相似后，再重新提交。
准则 4.3(b) iOS 指南 4.3

三分钟被拒，随后三周申诉无回音

事情经过

一名开发者的 App 在进入审核约三分钟后，就因 Guideline 4.3(b) 被拒了。该开发者向 App Review Board 提起了申诉。三周后，该开发者仍未收到任何答复，状态没有变化，也没有任何消息。

解决方案

未解决

经验教训

申诉可能搁置数周、毫无反馈。同时推进 App 在拥挤品类中的差异化，这样就不会只能干等申诉结果。
账号终止 iOS 账号终止

一款 App 看起来像网站，数十款 App 却消失了

事情经过

一家十多年来发布过 80 多款应用的工作室，开发者账号被标记为待终止。据该工作室称，原因是其中一款应用可能被认为与现有网站相似。没有预警，也没有只下架那一款应用的选项。其所有应用都被从 App Store 下架，包括为客户构建的无关授权应用，更新也被阻止。

解决方案

尚未解决。该工作室公开对该决定表示异议。

经验教训

一个开发者账号就是一个单点故障。如果你为客户构建应用，就发布在客户自己的开发者账号下，这样即使你的某个应用出现纠纷，也不会连累客户的应用被下架。
第 3.2(f) 条 (开发者计划许可协议) iOS 账号终止

一次标题更新，随后是 3.2(f) 终止通知

事情经过

一位独立开发者只为一款应用提交了简单的标题修改，却收到了依据 3.2(f) 条款发出的终止通知。其所有应用都被从商店下架。他们提交了正式申诉，15 天后仍未收到任何真人回复。

解决方案

未解决

经验教训

触发 3.2(f) 通知的更新，可能并不是 Apple 真正针对的问题。申诉前，请收集每个应用由谁拥有、由谁运营的明确证明，并做好数周才有回复的准备。
第 3.2(f) 条 (开发者计划许可协议) iOS 账号终止

修复了一个付费墙问题，一周后却收到了 3.2(f) 终止通知

事情经过

一位独立开发者的 App 曾因付费墙上年度和每周价格的展示方式被拒。这个付费墙来自 AI 编程助手复制进来的模板。他们在 code 内修复了问题，提交了新 build，等了大约一周。结果没等到审核结果，却一觉醒来看到一份依据第 3.2(f) 条的待处理终止通知。整个开发者账号被标记，多年来开发的所有 App 都被从 App Store 下架，打款也被冻结。开发者表示提交后没改过 App 的任何内容，有 logs 为证，并公开询问有没有人成功找回账号。

解决方案

截至发帖时仍未解决。

经验教训

把付费墙或定价被拒当成警告，而不是走个形式。首次提交前，检查任何模板或生成的付费墙 code 如何展示价格和试用条款；同时保留 build 和变更 logs，这样万一账号被质疑，也能准确说明你提交了什么。
准则 3.1.1 App 内购买项目 macOS 指南 3.1.1

一款免费云游戏客户端因串流游戏内的购买行为，依据 3.1.1 条款被拒

事情经过

一位开发者为某主流游戏主机厂商的云游戏服务开发了一款免费的远程游玩 App，并提交到了 App Store。但 Mac 版本因违反指南 3.1.1 被拒。App Review 表示，部分串流游戏可能会引导用户在 App Store 之外购买数字内容。但据开发者理解，该游戏服务不允许玩家在串流会话期间完成支付：有些游戏会显示购买选项，但串流时无法完成付款。开发者指出，App Store 上已有多个类似的串流 App，并提起了申诉。

解决方案

发帖时申诉仍在处理中。

经验教训

对于串流和客户端 App，App Review 审核的是用户在串流内容中能看到什么，而不只是你自己的 code。首次提交前，就在审核备注中附上截图，详细说明串流内购买的具体行为，而不是留到申诉时再说。
iPad 登录（未注明指南编号） iOS 登录

第三次被拒：后端故障期间 iPad 登录失败

事情经过

一个开发健身 App 的小团队第三次被 App Store 拒绝，原因是审核人员无法在 iPad 上登录。问题并不出在 App code 本身：审核人员尝试登录时，他们托管的后端服务商正好出现身份验证故障，登录直接失败了。团队提供了带邮箱和密码的演示账号，但据他们说，审核人员之后并没有再试。团队自己也没有 iPad 或 Mac 可以测试。后端恢复后，他们重新提交了。Apple 曾告诉他们，即使再次被拒，App 也会保持加急审核，但三个工作日后，它仍在等待审核。

解决方案

已重新提交，截至发帖时仍在等待审核。

经验教训

审核人员经常在 iPad 上测试，而且通常只会尝试登录一次。build 处于审核期间，留意后端和身份验证服务商的状态；提交前先在 iPad 尺寸的屏幕上测试演示账号；并在审核备注中写明登录失败时该联系谁。
审核指南 5.1.1(i) 和 5.1.2(i) iOS 指南 5.1.1 指南 5.1.2 AI 数据共享

把 AI 同意藏在服务条款里，无法满足 5.1.1(i) 和 5.1.2(i)

事情经过

一位开发者的日记 App 因违反 iOS 指南 5.1.1(i) 和 5.1.2(i) 被拒，这两项都涉及与 AI 服务共享用户数据。这项数据处理的同意原本已写在 App 的服务条款里，但 App Review 并不认可。开发者随后把同意移到 App 内的一个独立页面，并在任何模型读取任何一条记录之前首先展示它。接着他们梳理了所有 code 路径，凡是记录会到达模型的地方都用该同意做前置校验，用户没点同意，请求根本不会被构建。现在后台任务会跳过未同意的账号，转为等待而不是直接失败；如果 App 调用了同意页面未列出的 AI 主机，发布检查也会失败。

解决方案

已修复并重新提交。发文时 Apple 的裁定结果仍未知。

经验教训

服务条款里的一句话并不构成对 AI 数据共享的同意。请在首次请求前在 App 内询问用户，说明服务商和涉及的数据，并确保每条发送用户内容的 code 路径都会校验这个答案。
第 3.2(f) 条（开发者计划许可协议），此前元数据多次被拒 iOS 账号终止元数据与 IAP

一个新库，八次被拒，应用改名，最后收到终止通知

事情经过

一位独立开发者有一款 iOS 应用，已上线近三年，收入达六位数，发布过很多次更新，退款率很低。六个多月前，他们提交了一个小更新，唯一的变化是新增了一个库。App Review 拒绝了它八次以上，每次都是因为元数据：已上线一年多的关键词、某个本地化版本中的副标题，然后是截图，接着又回到同样的问题，最后是应用名称本身——而他们的大部分搜索流量正来自这个名称。他们申请与 App Review 通话，审核员告诉他们，名称是最后一个待解决的问题。他们给整个应用改了名并重新提交。三天后，又收到一封笼统的拒绝通知，副标题和截图问题再次出现。他们觉得这次更新没必要，就放弃了。几个月后，同一个旧的审核线程里收到了一份待处理的终止通知。通知称，该账户为试图规避审核流程而反复违反指南，且此前消息中的问题仍未解决。应用已从商店下架，整个账户也被标记为待移除。

解决方案

已向 App Review Board 提交申诉，发帖时仍在处理中。

经验教训

被放弃的提交仍可能对你的账号造成不利影响。如果审核一直反复，请在审核消息线程中以书面形式确认所有剩余问题，而不是只在电话里沟通；如果你决定放弃某次更新，请在消息线程中回复说明，并从审核中移除该 build，而不是让拒绝一直悬而未决。
Guideline 1.1 Safety: Objectionable Content，随后是 Section 3.2(f) iOS 不当内容账号终止

两次 1.1 拒审，一个关于是哪张图片的疑问，随后是账号终止通知

事情经过

一位开发者的 iOS 应用用于生成 AI 情侣照，因违反指南 1.1 关于不当内容的规定被拒。拒信没有说明是哪张图片有问题。开发者降低了示例图片的尺度，去掉了肢体接触和依偎动作，约五天后重新提交。四天后，应用又因同样原因被拒。这次他们没有再发新 build，而是写信问 Apple 是哪张图片出了问题。约十天过去仍无回复，随后应用被下架，开发者收到待处理的终止通知。按他们的理解，Apple 把反复修改再提交的循环视为规避审核。付款被暂停，账户下所有应用都面临风险，申诉期 30 天。查阅收到同样通知的开发者论坛帖后，他们发现大多数申诉数周无人回复；唯一找到的恢复案例，是在第二次申诉中指明实际原因并披露其他所有内容后才成功。

解决方案

发布本文时正在准备申诉。

经验教训

现在，同一指南下的两次拒绝就可能让账户面临风险。内容拒因含糊时，重新提交前先请 App Review 指出具体界面或素材，记录每次修改，并把第二次拒绝当作暂停信号，而不是再试一次。
指南 2.3.7、5.2.5 和 4.8 iOS 指南 2.3.7 元数据与 IAP 登录要求

Mac 版已通过，同一款 App 的 iPhone 版却因 2.3.7、5.2.5 和 4.8 被拒

事情经过

一位为某主流第三方日历服务开发日历客户端的开发者先上线了 Mac 版。Mac 版为了在应用描述里说明它支持该日历服务，就已经走过一次正式申诉，也向 App Review 解释过为什么不需要 Sign in with Apple。可当他们用与 Mac 版相同的 bundle 和相同的 App ID 加上 iPhone 版时，却一次性因三项指南被拒：2.3.7 是因为应用内活动中显示的价格，5.2.5 是因为一句写着 App 适用于 iPhone、iPad 和 Mac 的文案，4.8 是因为没有在日历服务自己的登录旁提供 Sign in with Apple。指南 4.8 对特定第三方服务的客户端应用有豁免，这个 App 正是这种情况，但为 Mac 版给出的解释并没有延续过来。每个平台 target 都是从零开始审核的。

解决方案

发布时未注明。

经验教训

即使在同一个 App ID 下，新平台也是一次全新的审核。把已经争取到的每一项解释和豁免都复制到每个平台的审核备注里，并在提交前检查应用内活动和描述中的价格和 Apple 设备名称。
指南 3.1.2(c)，然后是 Siri 文本中的 Apple 商标（未注明指南编号） iOS 指南 3.1.2 无止境的审核

等了九天，因 3.1.2(c) 付费墙被拒，随后 binary 因 Siri 文本在 42 秒内被拒

事情经过

一位开发者用新账号提交了一款写作习惯应用的首个版本，等了大约九天才进入“审核中”。50 分钟后，该应用因违反指南 3.1.2(c) 被拒：在年付方案中，折算出的月费字号比实际扣费的年费更大。他们修正了付费墙的字体大小并上传了新的 build。该 build 在 42 秒内被自动拒绝，因为 Siri 快捷指令的帮助文本中使用了 Apple 应用的品牌名称，而 Siri intent 中的文本不能出现 Apple 一词。他们改成泛指笔记应用，并再次上传了 build。

解决方案

已重新提交，发帖时结果未知。

经验教训

首次提交前，请确保每个套餐中最醒目的价格是计费金额，并检查所有面向用户的字符串（包括 Siri、Shortcuts 和小组件文本）中是否出现 Apple 商标。自动化检查几秒内就能发现这些问题，但每一轮仍会让你在审核队列中往后排一位。
第 3.2(f) 条（《开发者计划许可协议》）引用了早前一次名称被拒的记录 iOS 账号终止元数据与 IAP

名称被拒的问题修复并获批后，近一年后又收到因欺诈被终止的通知

事情经过

一位运营小型公司账号的独立开发者，在约一年半里做出了八款已上线的应用。大约一年前，其中一款应用曾因 Apple 反对其名称中的某个词而被拒。开发者随后改了名，应用重新送审后获批，之后的一次更新也获批。其分享的审核记录显示，1.0 版本连续两天被拒、次日获批；约两个月后，一次更新首次提交即获批。此后该应用约九个月没有改动。随后，同一账号下的一款新应用被拒，紧接着收到一份待生效的终止通知，援引第 3.2(f) 条的不诚实或欺诈行为：提交内容多次违反指南以试图规避审核，且此前消息中的问题仍未解决。通知没有指出任何新问题，事先也没有警告或询问。所有应用的收益都被暂停，包括从未出过问题的应用；通知还警告，新账号也可能被终止。唯一能回复的方式是一个限 2,000 字符的网页表单，提交后只返回自动确认，随后便再无音讯。开发者接受了被标记应用的下架，当天关闭了服务器，暂停了所有提交，并在第一天提交了完整申诉。

解决方案

第一天就提交了申诉，截至发帖时仅收到自动确认。

经验教训

即使你修复了被拒问题并获批，几个月后这条记录仍可能被作为“惯犯模式”引用。请保留所有拒审通知、你做出的具体修改以及随后的批准记录，以便在简短的申诉表中展示完整历史。提交后，请做好没有明确时间表的准备。
指南 4.3（垃圾应用）和 4.2.6 iOS 指南 4.3 指南 4.2.6

一款独立开发的游戏两次被拒：一次因垃圾应用，一次因模板应用；发送了九次回复，均无回应

事情经过

一位晚上独自开发游戏的开发者提交了一款原创游戏，却在 10 月初相隔四天被拒两次。拒审理由分别是指南 4.3（垃圾应用）和指南 4.2.6（涵盖由商业化模板或应用生成服务创建的应用）。该游戏并未使用任何模板，每一行代码均由开发者亲自编写。两次拒审均返回相同的模板文本，且均未指明该游戏与哪款应用相似。随后，Apple 就游戏的制作方式提出了九个问题，开发者在第二次拒审后的第二天详细回答了所有问题。但始终未收到回复。大约九天后，他们向 App Review Board 提出申诉，一周后仍在等待结果。他们猜测，一个人几个月内发布多款游戏，在审核员眼中可能看起来像是一个应用工厂。在此期间，他们让该游戏可以在网页浏览器中免费游玩。

解决方案

发帖时，向 App Review Board 提交的申诉仍在处理中，距首次被拒约三周。

经验教训

4.3 和 4.2.6 会按整个账号来判定，而不是看单个二进制文件。如果你在短时间内上架多款应用，就要从首次提交起展示每款应用的原创之处，附上说明构建方式的审核备注和一段简短的实机演示视频；因为一旦拒信变成模板，详细的答复可能几周都无人查看。
Guideline 2.1 App Completeness，随后是 Guideline 5 Legal（China availability） iOS 准则 2.1 指南 5 法律无止境的审核

给审核员的免费授权让付费墙没被发现，随后排队六天，又被中国区 AI 审核拒绝

事情经过

一位开发者提交了其首款 iOS 应用——一款用于跟踪定期付款的个人理财工具，结果因准则 2.1 App Completeness 被拒。原因是一个适得其反的好意：他们给审核员的邮箱账号开通了付费许可，审核员因此跳过了付费墙，从未看到购买流程。开发者随后写了一份带截图的分步 PDF 指南给审核员，并重新提交，这次同时提交了 iOS 和 Mac 版本。新提交等待了六天进入审核中，随后再次被拒，这次是因为应用在中国大陆可用，却提到了 ChatGPT。

解决方案

截至本文发布时，该应用仍处于被拒状态，而更新的版本已通过 TestFlight 提供给测试人员。

经验教训

让 App Review 看到新用户的真实体验，包括付费墙。与其提供一个会隐藏购买流程的免费许可，不如给审核员一个可用的演示账号或沙盒账号，并附上清晰的备注。如果应用或其商店详情页提到 ChatGPT 等 AI 服务商，请在提交前检查可用地区是否包含中国大陆，因为每轮新审核都可能在队列里耗上几天。
准则 2.3.10 Accurate Metadata iOS 指南 2.3.10 元数据与 IAP 无止境的审核

首次审核等了十天，因提及 Google Play 被拒，又等了两周

事情经过

一位开发者在十月初用全新的开发者账号提交了一款全新应用。该应用允许用户公开上传自己的图片，开发者预计这会招来额外的内审核查。十天后首次审核在 iPad 上进行，结果因违反指南 2.3.10（准确的元数据）被拒：应用或其元数据中提及了第三方平台，下一步要求移除对 Google Play 的引用。开发者追查发现，该提及出现在应用内购买描述中。修复后应用重新进入队列，两周后仍在等待审核，距首次提交已过去 24 天，应用仍未上线。

解决方案

发帖时仍在等待审核，距首次提交已 24 天。

经验教训

首次提交前，请把你提交的每个文本字段（包括应用内购买描述）都搜一遍，检查是否出现其他商店或平台的名称。新账号每一次往返都可能在队列里耗掉一周甚至更久，所以一个词的提及就可能让发布延迟数周。
指南 2.1 App 完整性（所需信息） iOS 准则 2.1 无止境的审核

排队 24 天后，收到 2.1 拒绝通知，要求提供完整的屏幕录制

事情经过

一位开发者提交了一个新的 iOS App 1.0.0 版本，并包含一个订阅组及两个订阅（年订阅和月订阅）。在等待 24 天后，Apple 审核了该版本，并根据指南 2.1 App Completeness 予以拒绝，这让开发者感到非常困惑。由于 App 版本被拒，随之提交的订阅也无法通过审核，状态一直停留在 Ready for Review。拒绝通知的内容是一项 2.1 Information Needed 请求，这也是该开发者第一次收到此类请求。要求提供一段在运行最新操作系统的真机上的屏幕录制，内容需从启动开始，展示典型的用户流程，包括注册、登录和删除账号、任何用户生成内容（UGC）及其举报和屏蔽工具，以及访问付费内容的过程。此外，还要求说明产品用途和目标受众、提供包含登录凭据的设置说明、列出 App 依赖的所有外部服务（包括 AI 服务）、说明任何地区差异，并提供受监管行业或受保护第三方材料的相关文档。所有回答还必须添加到 App Store Connect 的审核备注中，供后续提交使用。

解决方案

发帖时，开发者又回去准备录屏和答复，结果未知。

经验教训

在队列里等了几周后，一个“需要更多信息”的请求又会让你多走一整轮流程。提交新 App 前——尤其是带订阅、账户或用户内容的 App——先在真机上录下这段操作演示，并把答案写进审核备注，因为被拒的版本也会拖住随它一起提交的所有内容。
第 3.2(f) 条 (开发者计划许可协议) Apple 开发者计划账号终止无止境的审核

连续六次更新获批，随后一次常规更新却因 3.2(f) 被封号

事情经过

一位独立开发者连续六次更新获批。其分享的审核历史显示，最新一次提交处于“正在审核”状态，之前的版本均显示“审核已完成”。随后，他们在 10 月中旬提交了一次常规更新，但审核一直停滞不前。最终，他们没有收到审核结果，而是整个开发者账号因违反 3.2(f) 条款被封禁。在 App Store Connect 中，一条日期为提交当天的消息被附加到多个版本上，并被标记为未解决问题。该开发者称其 App 是原生的，更新获批记录一直良好，并表示 Apple 支持团队正在调查其申诉。

解决方案

发帖时，申诉仍在调查中。

经验教训

连续顺利通过审核，并不能避免因 3.2(f) 被终止。请为每次提交、审核消息和批准保留带日期的记录，并在每次审核后检查 App Store Connect 的 Messages 栏目，以便一旦可以申诉就能立即提供完整历史记录。
App Review 信息请求（演示账号和屏幕录制） iOS 登录

提交五分钟后演示账号被删，随后一个录屏请求让他们免于第二次被拒

事情经过

一家代理机构提交了客户的 App，并附上用于 App Review 的演示账号。提交仅五分钟后，App Review 就删除了该演示账号。随后 Apple 要求提供该 App 的屏幕录制。在录制时，团队发现 App 内有一段被他们漏掉的销售文案，而这本会导致 App 再次被拒。

解决方案

发布时尚未公布最终结果。

经验教训

审核员可能会删除你提供的演示账号（比如在检查账号删除功能是否正常时），所以要有办法重新创建它，或者多提供几个。提交前录制一遍自己的审核走查：像审核员那样查看应用，是发现会触发下一次拒审的文案的省事办法。
第 3.2(f) 条 (开发者计划许可协议) Apple 开发者计划账号终止元数据与 IAP

早期被拒五次，四次更新获批，一年多后收到 3.2(f) 通知

事情经过

一位拥有近十年开发经验的独立 iOS 开发者在 2025 年 4 月提交了一款全新的 AI 图生视频应用。用户可以上传自己的照片，免费获得首次生成，之后可通过一次性应用内购买获取积分，无需订阅。首次提交被拒了五次，大多是因为截图和元数据：截图被认为营销味太重；一张显示情侣接吻的截图，以及后来替换它的求婚截图，都被标记为违反“不良内容”指南。在修改截图、文本和 build 后，应用获批，随后四次更新均未再被拒，最后一次是在 2025 年 8 月。此后没有再提交更新。超过十四个月后，开发者收到一份“待终止通知”，称该账号的提交多次违反指南、试图规避审核，且在多次重新提交后违规问题仍未解决，该通知附在了全部五个版本上。开发者表示，App Store Connect 已不再显示足够细节，无法还原此前的拒绝情况。通知在午夜前后到达，开发者约 30 分钟后就在 2,000 字符限制内提交了申诉，后来很后悔没有等一等、把申诉写得更清楚。

解决方案

发帖时申诉仍在处理中。

经验教训

审核通过并不代表结案。请自行保存每封拒绝通知、所引用的指南条款、你修改了什么以及批准日期，因为 App Store Connect 之后可能不再显示这些旧详情。收到通知后，请花时间写一份符合字数限制的清晰申诉，而不是在第一个小时内就发出去。
第 3.2(f) 条 (开发者计划许可协议) Apple 开发者计划账号终止元数据与 IAP

一个标题关键词、一次 3.2(f) 终止，以及一份提到流媒体引用的申诉答复

事情经过

一位独立开发者的整个开发者账户因 3.2(f) 条款被终止。据其说法，此事没有事先警告，也没有更早的元数据拒绝记录，该开发者认为原因是应用标题中的关键词错误。随后提出申诉。App Review Board 回复称，其调查确认存在指南违规：该开发者的一款应用包含误导性引用，让用户误以为其提供流媒体服务，Apple 称此举极其恶劣。函件指出存在操纵或误导性行为模式，继续暂停收益支付，并表示一旦终止正式生效，开发者可向 App Review Board 申请恢复账户，说明理由及计划中的改进。

解决方案

申诉被驳回。正式终止后可提交恢复申请。

经验教训

标题或关键词中若暗示 App 并不提供的服务（例如流媒体），可能被视为误导，而非简单的元数据错误，这会直接导致终止，而不会先被拒审。提交前，请对照 App 的实际功能检查每个标题、副标题和关键词。
指南 4.1(a) 抄袭 iOS 无止境的审核

审核 15 天后，因使用来自公开 API 的电影海报，被以 4.1(a) 抄袭为由拒审

事情经过

一位开发者开发了一款帮助用户挑选电影的 iOS App。它展示了从公开电影数据库 API 获取的标题和海报，并在 App 内注明了出处；其“观看”按钮会跳转至官方流媒体 App，而非直接播放内容。经过 15 天审核后，Apple 以指南 4.1(a) 抄袭为由拒绝了该 App，将海报视为第三方内容，要求提供使用权证明或将其移除。而使用相同海报的同一款 App，此前已在 Android 和电视端应用商店通过审核。

解决方案

发帖时仍未解决。该开发者当时在问其他开发者：API 的条款能否作为证明被接受，还是必须把海报撤下。

经验教训

在 App 内注明出处、或在其他商店通过审核，都不能作为 App Review 认可的授权。如果你的 App 展示了来自 API 的海报、美术作品或 Logo，请在提交前准备好可以展示它们的书面证明，或者准备一个不含这些内容的版本。
元数据被拒（本地化关键词） iOS 元数据与 IAP

AI 把 App 翻译成五种语言，却混入了一个导致被拒的关键词

事情经过

一位开发者用 AI 模型把 App 翻译成了另外五种语言。在其中一种语言里，翻译结果加入了一个可能被误读的关键词，提交因此被拒。一周后，开发者仍在等待回复；在连续一周看到其他开发者因 3.2(f) 被封号的故事后，他担心即使修复方案获批，之后也可能被拿来对账号不利。

解决方案

截至发稿时，仍在等待 Apple 的回复。

经验教训

提交前，请让懂每种语言的人检查所有本地化关键词、标题和副标题。机器翻译很快，但 App Review 会像这些词是你自己选的一样，逐一审视每个语言区域的用词。
App 预览元数据（价格参考） iOS 元数据与 IAP

App 预览写着“可免费试用”，更新因此被拒

事情经过

一位独立开发者提交了一次更新，其 App 预览视频中出现了“可免费试用”字样。Apple 拒绝了该更新，将预览中任何提及 free 的内容都视为价格参考。开发者随后重新剪辑视频并再次提交。

解决方案

视频已重新剪辑并重新提交。发帖时未公布最终结果。

经验教训

不要把价格和“免费”一词放进 App 预览，即使试用真实有效。改为在 App 内的付费墙展示试用条款。
指南 2.5.1 软件要求（HealthKit） iOS 无止境的审核

等待六天后，因 Health 同步缺少 Apple Health 徽章而被拒（2.5.1）

事情经过

一位独立开发者提交了一个重大更新，首次添加了 Apple Health 同步功能。它在“等待审核”状态停留了六天。直到那时，他们才注意到账户里有一份新的开发者协议待签署。他们签署后，更新当天下午就进入了审核，尽管他们说不清这两者是否有关联。随后，该更新因指南 2.5.1 被拒，原因是 Health 功能未在 App 界面中明确标识。开发者此前并不知道有 Apple Health 徽章这回事。

解决方案

在同步开关旁加上了 Works with Apple Health 徽章、审核备注，以及一段真机录屏。下一次提交就通过了。

经验教训

如果你的应用读取或写入健康数据，从第一次提交起就要在界面中用 Apple Health 徽章清楚展示。如果审核好几天没动静，先检查 App Store Connect 里有没有未签署的协议。
指南 1.1 不当内容 iOS 不当内容

上架一年多从未被拒，随后在 1.1 条款下无预警下架

事情经过

一位独立开发者的应用在 App Store 上架超过一年。它从未被拒过，还带来了一笔不多的月度订阅收入。没有任何预警，Apple 发来消息称，该应用因违反指南 1.1 不当内容而被从商店移除。

解决方案

这位开发者告诉 Apple 自己不会重新提交，放弃了这款应用乃至整个细分领域，因为不想拿开发者账号冒险。

经验教训

干净的审核历史并不能保护应用日后不被下架，内容规则也可能适用于早已获批的应用。如果你的应用处于敏感领域，现在就对照指南 1.1 检查内容和截图，别等收到下架通知才做。
Bug 拒审（未说明具体指南） iOS 无止境的审核

100 秒的匹配超时被当成 Bug 上报，之后等了六天回复

事情经过

一位开发者提交了一款多人游戏。审核员以 Bug 为由拒了这款游戏，但其遇到的并不是崩溃：游戏在等待 100 秒匹配对手后会停止搜索，而审核员把这种超时当成了故障。开发者向审核员回复并解释了匹配机制，同时也从游戏中移除了超时设置。六天后，他们仍在等哪怕一个回复。

解决方案

已在回复中说明并移除了超时设置。发帖时仍在等待回复。

经验教训

审核人员经常独自在冷门时段试玩，匹配队列很可能为空。给审核团队提供进入真实对局的方式，比如机器人对手或演示模式，并在提交前在审核备注中说明。
元数据被拒（服务条款与隐私政策链接） iOS 元数据与 IAP

Code 是从另一个 App 复用的，但服务条款与隐私政策链接仍指向旧 App

事情经过

一位开发者部分复用了自己早期 App 的组件来构建新 App。新 App 内的使用条款和隐私政策链接仍指向旧 App，因此 App Review 拒绝了这次提交。开发者表示，拒绝信息明确写明了需要修改的内容。

解决方案

修复了链接并重新提交。开发者说加急审核通常一天左右就有结果，但应尽量少用。

经验教训

在提交基于旧项目构建的应用之前，请检查它沿用过来的每个链接、bundle 名称和法律页面。仔细阅读拒绝信息，因为它通常会明确指出需要修复什么。
Guideline 2.1 需要提供信息 iOS 准则 2.1

报告里没提任何 Bug，只有 2.1 Information Needed，用一段 89 秒的录屏做了回复。

事情经过

一位开发者提交了第二个应用，结果因 2.1 Information Needed 被拒，且完全没有列出任何 Bug。App Review 要求提供一段屏幕录制，并回答应用面向谁、如何使用、依赖哪些外部服务以及目标地区是哪些等问题。开发者在模拟器上录制了 89 秒，从启动、完整使用一次主要功能一直到付费墙，并在备注中回答了所有问题，当天重新提交。

解决方案

录屏和答复均在当天提交。发布时未公布最终结果。

经验教训

新应用要做好收到 2.1 信息请求的准备。提交前，在审核备注中准备好主要流程的简短录屏，以及关于受众、使用情况、外部服务和地区的书面答复，这样首次审核就不会因提问而中断。
指南 2.5.4 软件要求（后台模式） iOS 无止境的审核

因一个遗留的复选框（音频后台模式）被拒，下一次更新又等了十天

事情经过

一个小团队为已上线的应用提交了更新。App Review 依据指南 2.5.4 将其拒绝，原因只有一个设置：应用启用了音频后台模式，但应用并不需要它。团队当天移除了该后台模式并重新提交，前后花了大约一天。之后的下一次更新又在审核中卡了大约十天。

解决方案

当天删除了音频后台模式并重新提交。随后的更新在审核中等待了大约十天。

经验教训

后台模式只能用于其预期用途。每次提交前，打开 Background Modes 能力，移除应用实际未使用的所有选项——残留一个勾选框就足以被拒，而且你无法预测下次审核要多久。
准则 4.3(a) Spam iOS 指南 4.3

一个套壳 Web App 被判定为 4.3(a) Spam，因此开发者将其重构为 Native App

事情经过

一位开发者提交了应用的第一版，形式是 Native Wrapper 里的 Web App。App Review 以 4.3(a) Spam 规则为由拒绝了它。开发者承认 Apple 说得有道理。他们把应用重做成真正的 Native App，将后端迁移到自建的 relay server，并公开了源码 code。

解决方案

用自托管 relay server 重构成原生 app。文章没有分享重构版本的结果。

经验教训

只在网站外面套层壳，很容易被 App Review 当成垃圾应用。如果要上架 App Store，首次提交就得让 app 有真正的原生价值，别指望套壳网站能过审。
因“不当内容”被拒（截图，随后副标题） iOS 不当内容元数据与 IAP

截图被标记为不当内容，随后显示副标题；这款游戏没有任何成人内容

事情经过

一家小型工作室为 iOS 开发简单的剧情游戏，不含成人主题、赌博或加密货币。其中一款游戏让玩家扮演想在好莱坞闯出名堂的名人，却因截图被判定为“不当内容”而遭拒。截图里只显示了游戏中衣着完整的角色。工作室更换了所有截图并重新提交。下一次被拒则是因为副标题中的不当内容，而副标题只是把游戏描述为明星生活和剧情游戏。每次审核都要花上数周。

解决方案

该应用最早于 9 月提交，直到 10 月底仍未通过审核。

经验教训

当 App Review 标记元数据违规却未说明原因时，请在 App Store Connect 中询问具体是哪个元素有问题以及原因，然后再重新提交。重新提交前，请一并检查截图、副标题和关键词，因为修复一个问题可能会暴露下一个问题。
指南 5.2.5 法律与知识产权 iOS 指南 5 法律元数据与 IAP

因截图使用了类似 iPhone 的设备而被 5.2.5 条款拒绝

事情经过

一位开发者因违反指南 5.2.5 被拒。App Review 指出截图中的元数据包含类似 iPhone 的设备图像，可能会让用户误以为是 Apple 产品。尽管展示的设备并非 Apple 设备，只是外观相似，且该开发者此前另一款应用使用类似设备图像已获批准，因此对此感到意外。

解决方案

发帖时未分享最终结果。另一位回复的开发者指出，App Review 也可能拒绝与平台不匹配的设备边框，或看起来与真实 iPhone 不同的渲染图。

经验教训

一款应用的批准不会为下一款应用设立先例。外观几乎像 iPhone 的设备模型可能被认定为与 Apple 产品混淆相似。请使用纯截图，或仅使用 Apple 提供的营销用设备边框，并确保其与平台匹配。
Guideline 2.1 需要提供信息 iOS 准则 2.1

首个 iOS 应用收到 2.1 信息请求，修复方法是确保所有内容可被找到

事情经过

一位 Android 版本已在 Google Play 上线的独立开发者提交了首个 iOS 应用。该应用包含三项应用内购买（IAP）和用户生成内容（UGC）。App Review 并没有直接拒绝，而是根据准则 2.1 发出了信息请求。开发者重新研读了准则 2.1（要求每项应用内购买必须对审核员可见且可用），并检查了用户生成内容（1.2）和账号删除（5.1.1(v)）的相关规则。次日，开发者重新提交了一个新 build，其中包含：每条用户内容旁可见的举报和屏蔽选项、用户发布前需接受的社区规则、退出登录和切换账号，以及一段展示购买项、安全工具和账号控制位置的录屏。

解决方案

收到请求后的次日提交了新 build。发帖时结果未知。

经验教训

把审核当成一场与陌生人在限时内进行的可用性测试。每一项购买、举报和屏蔽选项以及账号控制，都应能在几秒内找到，审核备注中的录屏应逐一指出它们的位置。已在 Google Play 上线，并不代表能通过 App Review。
准则 4.3(a) 设计、垃圾内容（Spam） iOS 指南 4.3 无止境的审核

新应用排队 27 天，结果因 4.3(a) 垃圾内容被拒

事情经过

一位开发者提交了一款全新的 App，等了 27 天才等到 App Review 审核。结果最终出现在 App Store Connect 时，却是依据准则 4.3(a) 设计、垃圾内容（Spam）的拒审。随后，该开发者问其他开发者，是否有人曾成功挺过 4.3(a) 拒审。

解决方案

发帖时并未分享解决办法。该开发者想听听经历过 4.3(a) 的人的建议。

经验教训

等得久并不代表 App 就安全。审核队列这么慢，几周后收到 4.3(a) 拒审，代价就是整整一个月。提交新 App 前，请如实说明它和同类别现有 App 有什么不同，并在审核备注和元数据中写清楚。
准则 4.3(a) 设计、垃圾内容（Spam） macOS 指南 4.3

iPhone 版 App 已经上线，随后其 Mac 版却因垃圾内容被拒。

事情经过

一位开发者已经在 App Store 上线了一款 iPhone 应用，并为 Mac 开发了同一应用的原生桌面版。App Review 根据指南 4.3(a) 拒绝了这款 Mac 应用。拒绝信息称，该应用与其他开发者提交的应用在二进制文件、元数据或概念上相似，仅存在细微差异，并建议提交一款内容和功能都独特的应用。该开发者随后在社区询问其他遇到 4.3 的人有哪些有效做法。

解决方案

发帖时尚未有任何解决方案。

经验教训

每个平台都要单独审核，已获批的 iPhone 应用不会自动延续到 Mac。4.3(a) 的信息会将你的应用与其他开发者的应用进行比较，所以回复时请具体说明你的应用能做哪些类似应用做不到的事，并指出只有你的应用才有的功能。
无止境的审核 iOS 无止境的审核

审核超过 14 天，最终还是被拒；重新提交后又等了两周。

事情经过

一位开发者说，他们之前的审核耗时超过 14 天，最后还被拒了。他们在 10 月 21 日重新提交，近两周后仍处于“等待审核”状态，而 Apple 表示大多数审核只需 24 到 48 小时。

解决方案

发帖时仍在等待审核。

经验教训

平均审核时间并不代表最坏情况，一旦被拒，你就会被退回缓慢队列的队尾。规划发布时预留数周缓冲，并尽量让首次提交完整，免得被拒后等待时间翻倍。
账号删除要求（指南 5.1.1(v)） iOS 指南 5.1.1

因缺少账号删除功能被拒，而此前第一位审核员已经删除了多个账号

事情经过

一位开发者的应用以公开用户生成内容为核心，第二次审核时因缺少账户删除功能被拒。日志显示，第一次审核期间，审核员顺利创建并删除了多个账户。这位开发者认为，被拒更多是因为该类别审核严格，而不是功能真的缺失。

解决方案

发帖时尚未有任何解决方案。

经验教训

即使功能可用，审核员也必须能快速找到它。请在审核备注中写明账户删除路径和具体要点击的页面，并附一段简短录屏。对于含用户生成内容的应用，还要展示举报、屏蔽和内容审核，因为这些类别会被审查得最仔细。
指南 2.1(a) App 完整性 macOS 准则 2.1

一款 Mac 应用因读取登录钥匙串被 2.1(a) 拒审，旧的拒审备注也消失了

事情经过

一位开发者提交了 Mac 应用，App Review 依据指南 2.1(a) 将其拒绝，因为应用读取了登录钥匙串。修复只需一次更新。真正让开发者意外的是 App Store Connect 本身：它只显示最近十次提交，因此更早的拒审消息会悄悄从历史记录中消失。

解决方案

一次更新就修好了。现在，开发者会把每条拒审消息复制到对应的修复 commit 中。

经验教训

不要把 App Store Connect 当作过往拒审记录，因为更早的提交会从列表中消失。请把完整的拒审文本和修复一起保存——放在 commit、工单或发布说明里——这样同样的问题再次出现时，你仍能拿到准确原文。
指南 1.4.1 身体伤害（健康与医疗） iOS 无止境的审核

一款健康类 App 审核了十天，随后因 1.4.1 被拒，靠一个来源页面在一个下午就修好了

事情经过

一位开发健康应用的独立开发者，在 App Store 审核中等了十多天。结果因 1.4.1 指南被拒，该指南涵盖健康和医疗应用。改动很小：开发者加了一个来源页面，标明应用内健康信息的出处，只花了一个下午就构建完成。

解决方案

添加了一个带引用的来源页面，只花了一个下午。帖子中没提重新提交后是否获批。

经验教训

健康应用的审核标准更高，漫长的等待，最后可能等来一个你本可以在提交前就满足的要求。如果你的应用会展示健康或医疗信息，请在首次提交前在应用内为这些信息添加清晰的引用来源。一位回复的开发者指出，醒目的“请咨询医生”提醒也是常见要求。
审核员难以找到应用内购买（未注明指南编号） iOS 元数据与 IAP

一款游戏更新因付费墙藏得太深被拒，把解锁入口移到标题画面后，26 小时内就过审了

事情经过

一位独立开发者花了 33 天、被拒两次，才让 iOS 游戏的 1.0 版本通过审核。首个更新 1.0.1 也被拒，因为付费墙埋得太深，审核员够不到。开发者在标题画面加了解锁按钮并重新提交。这次整个流程约 26 小时，实际审核只有约 12 分钟。

解决方案

在标题画面加了解锁按钮。重新提交后约 26 小时，更新就通过了。

经验教训

审核员不会花二十分钟玩你的游戏，就为了找到你卖的东西。把所有购买入口放在几秒内能到达的位置，或在审核备注里写清具体路径，让审核员不用翻找就能测试。
应用内购买元数据不匹配（未注明指南编号） iOS 元数据与 IAP

被拒原因：付费墙写的是“1 个月免费”，但 Apple 显示的是年费

事情经过

一位开发者结束了数周的 TestFlight 测试，准备正式上架 App Store，却有一个构建因付费墙被拒。付费墙写着“1 个月免费”，但 Apple 购买界面显示当天就开始收年费。审核员还找不到周订阅方案。开发者修正了付费墙文案和方案可见性，重新提交构建，再次等待审核。

解决方案

修正了付费墙，让免费试用文案与购买弹窗一致，并让周订阅方案能被找到。该应用随后在 App Store 上线。

经验教训

付费墙承诺的内容必须与 Apple 购买弹窗显示的一致，包括试用时长和开始扣费的时间。把审核员需要测试的每个方案都放在点几下就能到达的位置，并在提交前用全新安装走一遍这条路径。
指南 2.1 App 完整性（启动时崩溃） iOS 准则 2.1

一次附带额外性能修复的重新提交，启动时崩溃，搭进去一整天

事情经过

首次 App Store 审核被拒，原因只是要求补充信息；之后开发者决定把性能修复一并放进同一次重新提交。他们信心十足，甚至移除了原本针对游戏级设备的硬件门槛。App Review 再次拒绝了该构建，因为应用启动即崩溃，而且没有崩溃日志，只有一条自动消息。开发者以为是内存不足被系统杀掉，于是把门槛加了回来，花了一整天压缩资源、延迟加载、释放资源，同时不牺牲性能。

解决方案

恢复了硬件门槛，降低了内存占用，并为第二天准备了第三次提交。原帖没有分享第三轮后的最终结果。

经验教训

不要把不相关的修复堆进为回答审核问题而做的重新提交里。只提交能解决拒审的最小改动，对你声称支持的最低端设备保留稳定性门槛，并在再次上传前在该设备上做冷启动测试。
准则 4.3(a) 设计垃圾信息 iOS 指南 4.3

几款小型游戏一起提交后都触发了 4.3(a)，随后两次申诉成功改判

事情经过

一位开发者曾同时向 App Store 提交了几款小型游戏。结果全部因垃圾内容（Spam）被 4.3(a) 条款拒绝。经历这次风波后，他们调整了流程，现在每次只提交一款游戏。其中两次拒绝后来通过向 App Review Board 申诉得以撤销。

解决方案

改为每次只提交一款。其中两次 4.3(a) 拒绝在 App Review Board 申诉后被撤销。

经验教训

将相似应用集中在同一审核窗口提交，容易引发针对整组应用的垃圾内容判定。建议每次只提交一款；如果 4.3(a) 拒绝看起来不合理，请向 App Review Board 申诉，并清晰说明每款应用的独特性。
1.1 条款：安全、不当内容（应用元数据） iOS 不当内容元数据与 IAP

一款康复应用因营销文案点名了它帮助人们戒除的习惯，被依据 1.1 条款拒绝

事情经过

一款旨在帮助人们克服色情内容和情欲的应用被依据 1.1 条款拒绝。App Review 表示，该应用的营销在元数据（包括描述、截图和关键词）中提及了不当内容。当开发者要求提供细节时，App Review 点名了一个关键词“porn”，称该列表并不详尽，警告重新提交时应用会接受全面审核，并表示以相同营销内容重新提交，或作为相同概念的新应用提交，都会带来相同甚至更多违规。开发者指出，商店中已有类似应用公开宣传帮助克服性诱惑。

解决方案

发帖时问题尚未解决。App Review 要求先从元数据中删除所有提及不当内容的地方，之后才会进行全面复审；开发者则公开质疑为何类似应用受到不同对待。

经验教训

帮助人们戒除成人内容相关习惯的应用，审核看的是其自身营销文案中的措辞，而不是意图。在关键词、描述和截图中描述目标（如康复或自控），而不是点名恶习，并在重新提交前问清 App Review 是哪些具体术语触发了拒绝，因为下一次提交会接受全面审核。
应用图标被标记为不当内容（未说明具体指南编号） iOS 不当内容元数据与 IAP

一个已获批的应用图标因皮肤暴露过多被拒

事情经过

一款 AI 应用使用插画角色作为应用图标，角色穿着露脐装，露出了部分胸部和腹部。该图标此前已通过 App Review。但在后续提交中，Apple 以胸部和腹部暴露过多为由拒绝了它。开发者把角色改画成穿着遮住胸部和腹部的完整上衣，然后重新提交。

解决方案

重新绘制图标，使上衣覆盖胸部和腹部。帖子未说明新审核耗时多久。

经验教训

之前的批准并不能锁定你的图标或截图，因为每次提交都可能被重新审核。如果你的美术素材中角色有裸露皮肤，就要假设更严格的审核员可能会标记它，并准备一个遮盖更多的版本，这样修复时只需替换，而不用重新设计。
订阅取消流程（未注明准则编号） iOS 元数据与 IAP

在 Apple 推出留存消息功能前一周，因取消时多了一个“确定要取消吗”步骤被拒

事情经过

一款订阅应用在用户尝试取消时显示了自己的“确定要取消吗”界面，结果被 App Review 拒绝。不到一周后，App Store Connect 推出了留存消息功能：开发者可在用户尝试取消订阅时展示一条消息，并可选配图片或留存优惠。

解决方案

该帖子未说明这个拒审问题是如何解决的。现在，新的 App Store Connect 功能提供了一种 Apple 认可的方式，可在取消时展示消息。

经验教训

不要在订阅取消前人为设置阻力。让用户直接进入取消流程；如果想最后挽留一次，请使用 Apple 的留存消息和优惠，而不是自定义界面。
指南 5.6 开发者 Code 行为准则与 2.5.19 隐藏功能 iOS 指南 5.6 开发者 Code 行为准则指南 2.5.19 隐藏功能

因隐藏功能被拒（5.6 条款），这些功能实际上是捆绑在订阅 SDK 中的结账 code

事情经过

A solo developer had an iOS goal tracking app rejected seven times on the way to launch. One earlier rejection had been about real money stakes. The last one came under the Developer Code of Conduct: App Review said the app had hidden or misleading functionality and asked for all hidden features to be removed, without saying which one. The app had no remote feature flags, no downloaded code and no special behavior for reviewers. Instead of guessing, the developer scanned their own release binary and found web checkout code from a payment provider that they had never written. It came bundled inside their subscription SDK for that SDK web platform, and the iOS app never used it. Given the earlier money stakes rejection, the developer suspected it looked like a hidden payment path.

解决方案

在没有任何 code 的情况下，开发者用事实回复了 App Review：应用能做什么、不能做什么，没有真实资金风险，结账 code 的来源，以及未使用的 SDK web code 和未使用的照片库权限将在下一个 build 中移除，并请求指出被标记的具体屏幕。大约九小时后，App Review 表示将继续审核，应用随即上线。

经验教训

了解你的 binary 包含的一切，包括 code 你的 SDKs 为其他平台引入的内容，因为 App Review 评判的是 build 里的内容，而不是你的称呼。在遭遇 5.6 拒绝后，不要猜测并重新提交。冷静地用具体细节回复，并询问哪个屏幕或行为被标记。
指南 2.3.4 准确元数据（App Previews） iOS 元数据与 IAP

一个在十月通过审核的 App Preview，一个月后因 2.3.4 关于边框的问题被拒绝

事情经过

一位开发者提交了 iOS 应用的更新，因指南 2.3.4 被拒绝。App Review 称 App Preview 视频在屏幕录制周围有边框。同一个视频在上个月通过了审核。开发者指出，商店上的其他应用，包括一个知名应用（其预览显示的是人而不是应用），都使用了几乎没有或没有应用本身画面的 App Previews。

解决方案

开发者完全移除了 App Preview 视频并重新提交了更新。帖子没有说明新的审核结果如何。

经验教训

即使 App Preview 曾经通过审核，后续更新仍可能被拒，因为每次提交都会重新审核。请保持预览为应用界面的纯屏幕截图，不要添加装饰性边框。如果预览被标记，移除它是解锁更新最快的方法，同时你可以重新制作它。
第 3.2(f) 条 (开发者计划许可协议) macOS 账号终止无止境的审核

一个修复图标问题的 macOS 更新在审核中停留了约 45 天，随后收到了 3.2(f) 通知

事情经过

一位独立开发者的 macOS 应用因品牌问题被 App Review 标记。2026 年 9 月 15 日，他们提交了一个更新以解决反馈，包括完全重新设计的 App 图标。该更新随后在“审核中”状态停留了约 45 天，没有决定，开发者通过官方渠道发送了两次加急审核请求。2026 年 10 月 30 日，当该修正更新仍在等待时，收到了根据 3.2(f) 条款发出的“开发者账户终止待处理通知”。

解决方案

发帖时申诉仍在处理中。开发者已提交正式申诉并单独联系了开发者支持团队，但尚未收到实质性回复。

经验教训

队列中等待修复的问题不会暂停对旧版本提交的处罚。请保留所有拒绝通知、你为此做出的每项更改以及每次加急请求的日期记录，以便在申诉中准确展示你修正了什么以及何时修正的。