App Store 审核被拒怎么办？12 个常见被拒原因与改法
App Store 审核被拒大多集中在 2.1、4.3、5.1.1 等十几条审核指南条款。本文按条款号整理 12 个最常见的被拒原因，给出被拒信里的说法、改法和回复审核的要点，文末附总表和申诉流程。
App Store 审核被拒后，先在 App Store Connect 的 App Review 页面找到被拒信开头的条款号，判断问题出在构建还是元数据。只改元数据的，用原构建直接重新提交；改了代码的，加构建号重新上传，再在回复里逐条说明改了什么。被拒原因绝大多数集中在 2.1 App 完整性、2.3 元数据、3.1.1 内购、4.3 重复 App 和 5.1.1 隐私等条款。
下面按条款号整理 12 个最常见的被拒原因，每条给出被拒信里的常见说法、原因、改法和回复要点，文末附总表和申诉流程。条款内容以 Apple 官方《App Store 审核指南》为准，截至 2026 年 10 月，指南最近一次更新是 2026 年 10 月 16 日。
收到被拒信先看什么？
被拒后，App Store Connect 里这个 App 的页面顶部会提示有未解决的问题，进入 App Review 页面能看到每一条被拒理由。每条理由都以条款号开头，例如「Guideline 2.1 - Performance - App Completeness」，后面是审核员的具体描述，有时附截图、录屏或崩溃日志。
先做三件事。
- 找到条款号，对照审核指南原文读一遍这一条。
- 区分问题出在构建（代码、包内容）还是元数据（截图、描述、隐私信息、审核备注）。
- 只改元数据的，改完可以直接用同一个构建重新提交。改了代码的，要加构建号重新打包上传。
App Store 审核被拒最常见的 12 个原因是什么？
1. 2.1 App 完整性：崩溃和明显缺陷
被拒信常见说法：审核员在某台设备、某个 iOS 版本上启动或操作 App 时崩溃，或某个按钮没有反应、页面空白，信里通常附崩溃日志。
原因：2.1(a) 要求提交的是最终版本，占位文字、空网页和临时内容都要清掉，并且要在真机上测过稳定性。审核员用最新版 iOS 测试，你只在旧系统上测过的问题会在这里暴露。服务端没开、接口指向测试环境，也算这一类。
怎么改：用附带的崩溃日志定位出错的函数。用 Release 包在最新版 iOS 的真机上把主流程走一遍，TestFlight 就是做这件事的，做法见 TestFlight 内测分发教程。
回复要点：说明崩溃原因和修复方式，写明新构建的构建号，以及你在哪个 iOS 版本、哪种机型上复测通过。
2. 2.1 信息不全：测试账号登录不进去
被拒信常见说法：无法用你提供的演示账号登录，或需要更多信息才能继续审核（Information Needed）。
原因：2.1(a) 要求有登录的 App 提供演示账号，并保持后端服务可用。账号密码写错、账号过期、登录要收国内手机短信验证码、功能需要特定硬件或地区才能看到，都会卡在这里。
怎么改：在「App 审核信息」里填一个长期有效的演示账号，账号里预置好数据。登录依赖短信验证码的，给这个账号设固定验证码，在备注里写清楚。因法律或安全原因不能提供账号的，指南允许在事先获得 Apple 同意的前提下提供内置演示模式，演示模式要能展示完整功能。
回复要点：这类问题通常只改元数据。直接在回复里给出账号、密码和操作路径，再重新提交，不用重传构建。
3. 2.3 元数据不准确
被拒信常见说法：截图没有展示 App 的实际使用画面；描述里的功能在 App 里找不到；名称、关键词里有无关词或其他平台的名字。
原因：2.3 要求元数据（包括隐私信息、描述、截图、预览）准确反映 App 的核心体验。2.3.3 要求截图展示 App 使用中的画面，而不只是标题图、登录页或启动屏。2.3.7 禁止在名称和关键词里堆商标词、热门 App 名、价格信息，App 名称最多 30 个字符。2.3.10 禁止在 App 或元数据里出现其他移动平台的名称、图标和图片。
怎么改：截图换成真实界面，删掉写了但没做的功能，关键词里去掉竞品名，App 内和截图里搜一遍「Android」这类字样。有内购的，按 2.3.2 在描述和截图里标明哪些内容要额外付费。截图怎么做见从打包 ipa 到提交审核的完整流程。
回复要点：列出改了哪几处元数据，然后用原构建重新提交。
4. 2.5.1 使用非公开 API 或框架用途不符
被拒信常见说法：App 使用了非公开 API；或 App 集成了 HealthKit、HomeKit 等框架，但没有看到对应功能。
原因：2.5.1 规定只能用公开 API，并且要在当前正式版系统上运行。框架要用于它本来的用途并在描述中说明，例如 HealthKit 要用于健康和健身并与「健康」App 集成。非公开 API 多数来自第三方 SDK 或静态库。
怎么改：按信里列出的符号名搜索自己的代码和依赖，升级或移除带私有调用的 SDK。用不上的框架和权限直接删掉；确实用到的，在描述和审核备注里写清在哪个页面用、做什么。
回复要点：说明删掉了哪个 SDK 或调用，或者给出功能入口和操作步骤，必要时附录屏。
5. 3.1.1 内购：数字内容没走 App 内购买
被拒信常见说法：App 通过 App 内购买以外的方式解锁功能或内容；或配置的内购项目在 App 里找不到。
原因：3.1.1 规定解锁 App 内的功能（订阅、游戏币、关卡、会员内容、完整版等）必须用 App 内购买，不能用授权码、二维码等自有机制解锁。2.1(b) 要求内购项目完整、可见、能用，找不到的要在审核备注里说明原因。
怎么改：会员、虚拟币、付费内容改用 App 内购买，并把内购项目和这个版本一起提交审核。售卖实物商品或在 App 外使用的服务属于 3.1.3(e)，这类必须用 App 内购买以外的支付方式，例如 Apple Pay 或银行卡。真人一对一的实时服务（辅导、问诊等）按 3.1.3(d) 可以用其他支付方式。
回复要点：说明每个付费项目属于哪一类，引用对应条款号。审核员找不到内购入口的，在回复里写清进入路径。
6. 4.2 最低功能：只是网页套壳
被拒信常见说法：App 的功能、内容有限，用户体验和网页版差不多，不够「像 App」。
原因：4.2 要求 App 提供的功能、内容和界面要超出重新包装的网站。4.2.2 指出除了商品目录，App 不应主要是营销材料、广告、网页摘录、内容聚合或链接合集。
怎么改：加入网页做不到的原生能力，例如离线使用、推送通知、系统分享、小组件、相机扫码，或把核心流程改成原生界面。uni-app、Cordova 这类 WebView 工程，至少把首页和主流程做出 App 特有的交互。
回复要点：逐条列出 App 相对网页版多了哪些功能，附截图或录屏，说明对用户的价值。
7. 4.3 重复 App（Spam）
被拒信常见说法：App 和其他已提交的 App 重复，或和商店里大量同类 App 没有区别。
原因：4.3(a) 禁止为同一个 App 建多个 Bundle ID，例如每个城市一个地图 App。4.3(b) 禁止提交和现有 App 没有区别的作品，并点名手电筒、壁纸、简单计时器、算命等品类，除非体验有明显不同或更好。同一套代码换皮给多个客户上架也常被归到这一条。
怎么改：多个版本合并成一个 App，按地区、客户的差异用 App 内设置或内购提供。确实要做同类 App 的，把差异化功能做实。给不同客户做定制 App 的，由客户用自己的开发者账号提交。
回复要点：说明这个 App 和你账号下其他 App 的区别、目标用户和独有功能。不要只改图标和名称就重新提交。
8. 4.8 登录服务：只有第三方登录
被拒信常见说法：App 用第三方登录作为主账号登录方式，但没有提供符合要求的等效登录选项。
原因：4.8 规定用第三方或社交登录（指南举例有 Facebook、Google、X、LinkedIn、Amazon、微信登录）建立或验证主账号的 App，还要提供另一种登录服务。这种服务要只收集姓名和邮箱、允许用户隐藏邮箱、未经同意不为广告收集交互数据。
怎么改：加上 Sign in with Apple，或其他满足这三点的登录方式，和第三方登录按钮放在同一级。只用自己的账号密码体系的，不受这一条约束。
回复要点：说明新增了哪种登录方式，在登录页的什么位置。
9. 5.1.1(i) 隐私政策缺失或打不开
被拒信常见说法：隐私政策链接无效，或隐私政策没有写清收集哪些数据、怎么使用、如何删除。
原因：5.1.1(i) 要求在 App Store Connect 元数据和 App 内都放隐私政策链接，并明确写出收集的数据、收集方式和用途，确认第三方提供同等保护，说明数据保留和删除政策，以及用户如何撤回同意、申请删除。
怎么改：把隐私政策放在公网可访问的网页上，App 内的设置或关于页也放一个入口。内容逐项对照上面几点补齐，第三方 SDK 收集的数据也要写进去。
回复要点：给出新的链接和 App 内入口位置。这类问题一般只改元数据。
10. 5.1.1 权限申请与数据最少化
被拒信常见说法：权限用途说明不清楚；App 要求用户授权才能继续使用；申请了和核心功能无关的数据。
原因：5.1.1(ii) 要求收集数据前获得同意，付费功能不能以授权为前提，并提供撤回同意的方式。5.1.1(iii) 要求只申请核心功能需要的数据，能用系统选择器（例如照片选择器）就不要申请完整访问。5.1.1(iv) 禁止操纵、诱导或强迫用户同意。相机、相册、定位等权限的说明文字在 Info.plist 的 NS…UsageDescription 键里，写得笼统也会被拒。
怎么改：每个用途说明写清具体场景，例如「用于扫描快递单号」。用户拒绝授权后 App 仍能继续使用其他功能。弹系统授权框前不要加「必须同意」这类引导页。各权限键的写法见 Info.plist 权限用途说明。
回复要点：列出每个权限的使用场景，说明拒绝授权后 App 的行为。改了 Info.plist 的要重新构建上传。
11. 5.1.1(v) 强制登录与账号删除
被拒信常见说法：App 要求注册才能使用和账号无关的功能；App 支持创建账号，但没有在 App 内提供删除账号的方式。
原因：5.1.1(v) 规定没有重要账号功能的 App 要允许不登录使用；支持创建账号的 App 必须在 App 内提供删除账号。Apple 的账号删除说明进一步要求入口容易找到（通常放在账号设置里），要删除整个账号及相关个人数据，只提供停用或冻结不够。
怎么改：浏览类功能允许游客使用。在设置页加「删除账号」，确认后删除账号和关联数据。需要到网页完成删除的，直接链接到删除页面。非强监管行业的 App 不要要求用户打电话、发邮件或找客服才能删除。用了 Sign in with Apple 的，按说明调用 REST API 撤销令牌。
回复要点：写出删除账号的完整路径，例如「我的 → 设置 → 账号与安全 → 删除账号」，附录屏。
12. 5.1.2 数据使用与共享、跟踪授权
被拒信常见说法：App 收集的数据用于跟踪，但没有通过 App Tracking Transparency 请求授权；或 App 隐私信息与 App 的实际行为不一致。
原因：5.1.2(i) 规定未经许可不能使用、传输或共享个人数据，与第三方（包括第三方 AI）共享要明确告知并取得明确许可，跟踪用户活动必须通过 App Tracking Transparency 获得授权。5.1.2(ii) 规定为一个目的收集的数据不能未经同意挪作他用。
怎么改：用了广告或归因 SDK 的，在请求广告标识符前调用 ATT 弹窗，并在 Info.plist 加 NSUserTrackingUsageDescription。把数据发给第三方 AI 服务的，先告知并取得同意。核对 App Store Connect 的「App 隐私」问卷，和 App 及 SDK 的实际行为保持一致。
回复要点：说明 ATT 弹窗出现的时机和位置，或说明 App 不跟踪用户、隐私信息已更新。
为什么还没审核就收到隐私问题邮件？
有两类隐私问题通常在上传构建时就会收到邮件，而不是等到人工审核。
- Info.plist 缺少某个权限的用途说明，见 ITMS 错误码速查表里的 ITMS-90683。
- 代码或第三方 SDK 用了必需原因 API，却没有在
PrivacyInfo.xcprivacy里声明，会收到 ITMS-91053。截至 2026 年 10 月，Apple 官方说明写明自 2024 年 5 月 1 日起，未声明的 App 不被 App Store Connect 接受。
隐私清单怎么写见 iOS 隐私清单 PrivacyInfo.xcprivacy 怎么写。在 Windows、Linux 上用 KXBuild 时，Info.plist 和 .xcprivacy 都能双击用 plist 编辑器修改。
被拒原因与改法总表
| 条款 | 常见被拒原因 | 主要改法 | 要不要重传构建 |
|---|---|---|---|
| 2.1 | 崩溃、空白页、占位内容、后端没开 | 修复后在最新版 iOS 真机上复测 | 要 |
| 2.1 | 演示账号无效、缺少测试说明 | 提供长期有效的账号和操作路径 | 通常不要 |
| 2.3 | 截图非真实界面、描述夸大、出现其他平台名称 | 改截图、描述、关键词 | 通常不要 |
| 2.5.1 | 非公开 API、框架用途不符 | 升级或移除 SDK，删掉无用框架 | 要 |
| 3.1.1 | 数字内容用外部支付、内购找不到 | 改用 App 内购买，与版本一起提交 | 通常要 |
| 4.2 | 网页套壳、功能太少 | 增加原生能力和原生界面 | 要 |
| 4.3 | 多个 Bundle ID 重复上架、同质化 | 合并 App，做出差异化 | 视情况 |
| 4.8 | 只有第三方登录 | 增加 Sign in with Apple 等等效选项 | 要 |
| 5.1.1(i) | 隐私政策缺失或内容不全 | 补齐隐私政策并放 App 内入口 | 通常不要 |
| 5.1.1(ii)–(iv) | 权限说明笼统、强制授权 | 写清用途，拒绝授权后可继续使用 | 要 |
| 5.1.1(v) | 强制注册、不能删除账号 | 允许游客使用，App 内删除账号 | 要 |
| 5.1.2 | 未经 ATT 授权跟踪、隐私信息不符 | 加 ATT 弹窗，更新 App 隐私问卷 | 视情况 |
被拒后怎么回复审核和申诉？
回复审核消息
被拒后先在 App Store Connect 里回复，这是和审核团队沟通的主要渠道。按 Apple 的帮助文档操作。
- 在「App」里选中这个 App，点页面顶部提示有未解决问题的链接。
- 在 In Progress 区域，点这次提交旁边的 Resolve。
- 点 Reply to App Review，写回复内容，需要时点 Attach File 附截图或文档，再点 Reply。
只有账户持有人、管理员和 App 管理角色能回复。回复框最多 4000 个字符，在重新提交之前都可以继续往来沟通。因元数据问题被拒的，改完可以用同一个构建重新提交。
写回复时做到三点。
- 逐条对应被拒理由，写明改了什么、在哪里能看到。
- 审核员误解了功能的，用操作步骤和录屏解释功能本来的设计。
- 语气客观，不要争辩工具或其他 App 也这样做。
向 App 审核委员会申诉
回复后仍不同意结论，可以向 App 审核委员会（App Review Board）申诉，入口见 Apple 的申诉说明。按官方要求，先回复审核消息，没解决再申诉。每个被拒提交只申诉一次，写清 App 为什么符合指南，并先回答审核团队要求补充的信息。申诉结果会通过 App Store Connect 的消息通知。
申诉表单不用于催审或加急。时间紧的，用 Apple 提供的加急审核申请，只在确有必要时使用。想提前了解某个功能是否符合指南的，可以在 App Review 页面预约和审核团队的线上沟通。
已经在 App Store 上的 App 只是提交 bug 修复的，指南规定除法律或安全问题外，修复不会因其他条款问题被拖延。你可以在 App Store Connect 里告诉审核团队，这次先上 bug 修复，下次提交再处理被指出的问题，避免同一次 App Store 审核被拒拖住线上修复。
常见问题
App Store 审核被拒后多久能重新提交？
改完随时可以重新提交，没有冷却期。只改元数据的用原构建直接提交，改了代码的加构建号重新上传后提交。按 Apple 官方说明，审核团队通常 24 小时内审完至少 50% 的提交，48 小时内审完 90%。
被拒的是元数据问题，需要重新上传 ipa 吗？
不需要。截图、描述、关键词、隐私政策链接、演示账号这类问题，改完后在 App Review 页面回复并用同一个构建重新提交即可。
被 4.3 重复 App 拒了怎么办？
先确认账号下没有功能相同的其他 App，有的话合并成一个。然后做出和同类 App 明显不同的功能，在回复里逐条说明差异。只换图标和名称再提交，通常还会被同一条拒。
在 Windows 上打包的 App 审核会更严吗？
不会。审核依据的是审核指南，看的是 App 的功能、稳定性、隐私处理和商店信息，和打包用的电脑无关。能否通过最终由 Apple 按指南判断。
申诉 App 审核委员会能保证通过吗？
不能。申诉只是请委员会重新评估，结论由 Apple 决定。申诉前先在回复里把功能解释清楚，很多误解在回复阶段就能解决。