App Store 提交里大约四分之一会被拒，而独立开发者第一次提交时，被拒的原因翻来覆去就那十几个规则号。好消息是：审核员在你的 build 里大概只待五分钟，而几乎所有会让你被拒的问题，在你点 Submit 之前你自己就能看见。这篇就是按”审核员会引用哪条规则”组织的提审前自查清单。
一句话总结
- 截至 2026 年 6 月，Apple 大约 90% 的提交在 48 小时内审完（平均约 1.5 天），所以”被拒—改—重提”一个来回通常是 2 到 3 天，不是几周。但避免第一次被拒才是关键。
- 独立 App 反复踩的就那几条：2.1（占位 / 半成品 build）、2.3.x（截图和描述跟 App 对不上）、3.1.1（数字商品绕过 IAP）、4.2（薄 WebView 套壳）、5.1.1（App Privacy 表格没填全），以及测试账号缺失或失效。
- 这些大多你自己就能查。提审当天，在一台刚重装过 build 的设备上，把下面 9 项走一遍。
| 规则 | 管什么 | 独立 App 最常见的触发点 |
|---|---|---|
| 2.1 | App 完整性 | 占位文案、点了没反应的按钮、冷启动崩溃 |
| 2.3.3 | 截图真实 | 用 mockup / 设计稿代替真实界面截图 |
| 3.1.1 | 内购 | ”升级”按钮跳 Safari 走 Stripe |
| 4.2 | 最低功能 | 单页 WebView，没有原生功能 |
| 4.3 | spam / 重复 | 同一份代码改皮肤提交 N 次 |
| 5.1.1 | 数据收集声明 | App Privacy 表格没填全、没填隐私政策 URL |
| 5.1.5 | 位置 | Info.plist 用途文案写得太敷衍 |
| — | 测试账号 | 缺失、被禁用，或者没自测过 |
App 审核其实比看上去可预测
App 审核看着像黑箱，其实不是。Apple 公开了完整的 App Review Guidelines，审核员拒审时会引一条具体规则号，而踩坑的就那几条反复出现。审核团队每周要处理超过 20 万份提交，所以审核员动作很快、很依赖模式匹配——这正是为什么一个干净、自查过的 build 能顺利过，而一个糙的会因为一行就被打回。
下面这些类目覆盖了 2026 年独立开发者首次提交被拒的绝大多数。提交前知道要查哪些规则，就是第一天过审，和在 Resolution Center 里来回三趟之间的区别。
开始之前
- 你在准备第一次提审，或者被拒过一次、想在重提前把所有问题修干净。
- 你已经有能跑的 build 和 App Store Connect 的草稿展示页。
- 你已经读过（或能读）App Review Guidelines——不长。
- 你还有时间在提交前修问题，而不是提交后。
9 项自查
下面每条都附了：规则号 + 审核员会怎么拒 + 提交前怎么自查 / 修。每条都过一遍，再点 “Submit for Review”。
-
规则 2.1（App Completeness）——不能有占位 / 半成品。审核员会把每个按钮、每个 tab 都点一遍。
提交前自查：
- [ ] 全文搜索 "TODO" / "Lorem ipsum" / "敬请期待" / "Coming soon" / "暂未开放"——都要清掉或者隐藏入口 - [ ] 全文搜索 "test@example.com" / "12345" 等明显占位数据 - [ ] 跑一遍冷启动：删 App -> 重装 -> 走完所有 tab 的所有按钮，无 crash / 无白屏 / 无 "功能开发中" - [ ] App Store Connect -> App Description 里宣传的每个功能，在 build 里都能找到入口修法：把”敬请期待”的按钮整个隐藏掉（不是 disabled、不是浅灰），等下个版本再上。Apple 把崩溃和走不通的流程算作 2.1 里最大的一类——冷启动崩溃就是立刻拒。
-
规则 2.3.3（截图真实）——截图必须来自当前 build。元数据对不上是最常见的拒审类目之一，而且申诉成功的案例里大约有五分之一是元数据相关的，所以第一次就把这块做对很划算。
- [ ] 用提交的 build 跑一遍，截当前真实界面的图 - [ ] 禁用 mockup 图（PSD 合成）、设计稿图、竞品截图 - [ ] 截图里的内容数据（用户名、商品、消息）也要是 App 真实数据，不能是 "Apple Sample Content" - [ ] iPhone 6.9" / 6.7" / 6.5" 各套尺寸都用真机或模拟器截，不要拉伸缩放工具：用 Fastlane snapshot 自动跑 UI test 出多尺寸截图：
gem install fastlane fastlane snapshot init # 写 SnapfileUITests/SnapshotHelper.swift，跑： fastlane snapshot -
规则 3.1.1（IAP 强制）——数字商品必须走 Apple IAP，绝对不能跳外部 web 支付。
会被拒的典型：
- 解锁 Pro 功能时打开 Safari 走 Stripe checkout -> 立刻拒 - App 内 "升级" 按钮跳官网 -> 立刻拒 - 任何 "前往网站购买" 的引导 -> 立刻拒不需要 IAP 的合法例外（“reader” 类，规则 3.1.3）：电商实物、专车叫餐、医疗预约、符合条件的网课学习平台等。如果你属于例外类，在 App Store Connect 审核备注里明确写清楚类别——写得太笼统也会被拒。
-
规则 4.2（最低功能）——纯 WebView 套壳必拒。Apple 原话：如果你的 App “不够有用、不够独特，也不够 ‘app-like’，它就不该出现在 App Store”。单页
WKWebView、没有任何原生 UI，就是教科书级的 4.2 拒。提交前自查：
- [ ] 是否有至少 2-3 个原生界面（不是 WKWebView 套页面）？ - [ ] 是否用了 >=1 个 iOS 原生能力（推送 / HealthKit / 摄像头 / Core Location / Widgets）？ - [ ] 是否有"只有装了 App 才能做"的功能？（离线、推送、生物锁等） - [ ] 卸了 App 之后用网页能不能完成同样的事？如果完全能 -> 危险最便宜的补救：加 Widgets、Lock Screen Live Activities、Share Extension。原生底部 tab 导航 + 推送通知，通常就足够过”app-like”这关。
-
规则 4.3（spam / 重复 App）——不要同一壳子提交多版本。Apple 明确建议把高度相似的 App 合并成一个；提交多个近似重复会拖慢审核，还可能连累全部一起被拒。
会被拒的典型：
- 同一份代码改皮肤换图标，提交 10 个细分类目的 App -> 4.3 拒 - 模板生成的 App，只有 brand 不同 -> 4.3 拒 - "白标"批量代提交 -> 4.3 + 5.2 双拒 -
规则 5.1.1（数据收集声明）——App Privacy 表格必须完整。
App Store Connect → App Privacy → “Edit”：
逐项过 Apple 的各个数据类目（Contact Info / Health / Financial Info / Identifiers / Usage Data / ...）： - [ ] 每类标 "Collected / Not Collected" - [ ] Collected 的标 "Linked to User" / "Not Linked" - [ ] 标用途（Analytics / App Functionality / Personalization / Advertising / ...） - [ ] 第三方 SDK（Firebase Analytics、Crashlytics、Adjust、AppsFlyer、Sentry 等）也算"你收集"——必须申报在 App Information 页填上隐私政策 URL——哪怕你”只在本地存数据”，Apple 也要求有一份。审核员还会检查 App 内能不能找到隐私政策链接和账号删除入口。最少要包含哪些项，看 App 隐私政策清单。
-
规则 5.1.5（位置）——请求位置必须真正用到 +
Info.plist写清楚用途。Info.plist必须填的 key（不写 -> 编译期就会崩；写得敷衍 -> 审核拒）：<key>NSLocationWhenInUseUsageDescription</key> <string>用于显示你附近 5 公里内的咖啡馆推荐，仅在你打开搜索时使用</string> <key>NSLocationAlwaysAndWhenInUseUsageDescription</key> <string>仅当你开启 "实时通勤提醒" 后才会持续读位置，用于提前 10 分钟通知你出门</string>规则：每个权限文案必须含 (a) 具体场景 (b) 具体收益。“用于改善体验” 这类话几乎 100% 会被拒。
-
登录测试账号——属于最容易被拒的那一档，永远别漏。只要你的 App 有任何登录页，Apple 就要求在 App Review Information 里给一个能用的测试账号（或一个功能完整的演示模式）。
App Store Connect → App Review → Sign-In Information：
Username: review@yourdomain.com Password: AppleReview2026! 备注: - 该账号已预填示例数据：3 个项目、5 条消息、订单历史 - 主要功能入口都不需要付费即可体验 - 涉及付款的功能可用沙盒账号测试，沙盒账号也已经预登录 - 若审核遇到任何无法继续的步骤，请联系 dev@yourdomain.com，24h 内回复验证方法：提审当天，用一台全新（或全擦的）设备，拿这套一模一样的账号密码，在国内外两种网络环境各登一遍。账号被禁用或者密码打错一个字，就是稳稳一个来回。
-
预填示例内容。审核员只会在你的 App 里待大约五分钟，不会替你配数据。空状态会被读成”还没做完”。
- 笔记类：审核账号登录后已有 5 篇示例笔记
- 社交类：审核账号已有 3 个 follower + 已加 2 个 group + 5 条历史消息
- 工具类：示例项目 / 模板已预设
- 内容类：首页瀑布流已有可见内容（不能空白）
在审核备注里写清楚：“登录 review@yourdomain.com 后，可以直接看到示例 X / Y / Z”，并附 1 张登录后首屏的截图。Apple 明确说过笼统的审核备注会被拒——要具体写出审核员该做什么、该看到什么。
容易踩的坑
- 把 App Review Guidelines 当成”被拒了再看”的东西。第一次提审前从头到尾通读一遍。
- 给的测试账号不能用，或者已经禁用。提审当天，从干净设备、未登录浏览器测试一遍。
- 把功能藏在审核员绕不过的付费墙后。要么给”审核专用”通道，要么准备被 2.1 拒。
- 在 IAP 之外自己另搞一套订阅系统。哪怕跑得通，也是迟早被 3.1.1 拒。
- App 名或描述里用 beta、test、trial、preview——会触发 2.2 条款拒审。
- 为了类目搜索排名把 App 分错类。Apple 审核员会改类目甚至拒审。
FAQ
- 被拒了能申诉吗: 可以，通过 Resolution Center 或 App Review Board。申诉最有效的场景是审核员明显误解，而不是你确实违规；实际成功率大约五分之一，且多集中在元数据判定上。先在 Resolution Center 里带着具体证据回复，再升级。
- 2026 年审核要多久: Apple 称大约 90% 的提交在 48 小时内审完，平均约 1.5 天。所以”被拒 + 干净重提”一般是 2 到 3 天，不是几周。
- 拒审会影响后续提交吗: 直接不影响，但同一 App 反复同类拒审，可能被打更严的审核标签。修根源，别只修 Apple 当次引的那条症状。
- 能加急吗: 可以，在 App Store Connect 申请 expedited review，用于真实紧急情况（崩溃的 build、关键 bug 修复）。不保证批准，而且 Apple 会注意到滥用，所以留给真正着火的情况。
- 审核员前后不一致怎么办: 有时确实不一致——不同人不同解读。如果之前的版本批准过，就在 Resolution Center 回复里引用那次批准。