App Store 拒审基本就那十几类。每一条都提前检查过再提交，通常一次就能过。下面是清单，附带真实规则号和处理方法。
问题背景
App 审核看起来神秘其实不神秘。Apple 公布了 App Review Guidelines，审核员拒审时会引规则号，常见踩坑就那几条反复出现。提交前知道要检查哪些规则，能极大缩短审核轮数。下面这几条覆盖了 2026 年独立开发者拒审的大约 80%。
判断标准
- 准备第一次提审，或者被拒过一次想全面排查再提。
- 至少已有能跑的 build 和 App Store Connect 的草稿展示页。
- 能看 App Review Guidelines（不长）。
- 还有时间在提交前修问题，不是提交后。
实操步骤
下面每条都附了：规则号 + 审核员会怎么拒 + 提交前怎么自查 / 修。把每条都过一遍再点 “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、不是浅灰），等下个版本再上。
-
规则 2.3.3（截图真实）——截图必须来自当前 build。
- [ ] 用提交的 build 跑一遍，截当前真实界面的图 - [ ] 禁用 mockup 图（PSD 合成）、设计稿图、竞品截图 - [ ] 截图里的内容数据（用户名、商品、消息）也要是 App 真实数据，不能是 "Apple Sample Content" - [ ] iPhone 6.7" / 6.5" / 5.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）：电商实物、专车叫餐、医疗预约、网课学习平台（受 student 例外）等。如果你属于例外类，在 App Store Connect 审核备注里明确写清楚类别。
-
规则 4.2（最低功能）——纯 WebView 套壳必拒。
提交前自查：
- [ ] 是否有至少 2-3 个原生界面（不是 WKWebView 套页面）？ - [ ] 是否用了 ≥1 个 iOS 原生能力（推送 / HealthKit / 摄像头 / Core Location / Widgets）？ - [ ] 是否有"只有装了 App 才能做"的功能？（离线、推送、生物锁等） - [ ] 卸了 App 之后用网页能不能完成同样的事？如果完全能 → 危险修法：加 1-2 个原生功能。常用最便宜补救：Widgets、Lock Screen Live Activities、Share Extension。
-
规则 4.3（spam / 重复 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 的 32 个数据类目（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 等）也算"你收集"——必须申报附隐私政策 URL（App Information 页）。隐私政策要包含的最少 7 项，看 App 隐私政策清单。
-
规则 5.1.5（位置）——请求位置必须真正用到 + Info.plist 写清楚用途。
Info.plist必须填的 key（不写 → 编译期就会崩；写得敷衍 → 审核拒）：<key>NSLocationWhenInUseUsageDescription</key> <string>用于显示你附近 5 公里内的咖啡馆推荐，仅在你打开搜索时使用</string> <key>NSLocationAlwaysAndWhenInUseUsageDescription</key> <string>仅当你开启 "实时通勤提醒" 后才会持续读位置，用于提前 10 分钟通知你出门</string>规则：每个权限文案必须含 (a) 具体场景 (b) 具体收益。“用于改善体验” 这类话 100% 会被拒。
-
登录测试账号——这是 Top 5 拒审原因，永远不要漏。
App Store Connect → App Review → Sign-In Information：
Username: review@yourdomain.com Password: AppleReview2026! 备注: - 该账号已预填示例数据：3 个项目、5 条消息、订单历史 - 主要功能入口都不需要付费即可体验 - 涉及付款的功能可用沙盒账号测试，沙盒账号也已经预登录 - 若审核遇到任何无法继续的步骤，请联系 dev@yourdomain.com，24h 内回复验证方法：提交前用一台全新（或全擦的）设备 + 这个账号 + 国内外两种网络环境各跑一遍。
-
预填示例内容——审核员只会花 5 分钟看你的 App，不会替你配数据。
- 笔记类：审核账号登录后已有 5 篇示例笔记
- 社交类：审核账号已有 3 个 follower + 已加 2 个 group + 5 条历史消息
- 工具类：示例项目 / 模板已预设
- 内容类：首页瀑布流已有可见内容（不能空白）
在审核备注里写清楚：“登录 review@yourdomain.com 后，可以直接看到示例 X / Y / Z”，并附 1 张登录后首屏的截图。
容易踩的坑
- 把 App Review Guidelines 当成”被拒了再看”的东西。第一次提审前从头到尾通读一遍。
- 给的测试账号不能用，或者已经禁用。从干净设备、未登录浏览器测试一遍。
- 把功能藏在审核员绕不过的付费墙后。要么给”审核专用”通道，要么准备被 2.1 拒。
- 在 IAP 之外自己实现订阅系统。哪怕跑得通也是迟早被拒。
- App 名或描述里用 beta、test、trial、preview——会触发 2.2 条款拒审。
- 为了类目搜索排名把 App 分错类。Apple 审核员会改类目甚至拒审。
这篇适合谁
准备第一次提审的独立开发者，或者已经被拒过想系统排查再交的。
这篇不适合谁
已经过审、只是在迭代功能的 App——看 Update 相关 guideline 更合适。
FAQ
- 被拒了能申诉吗: 可以，通过 Resolution Center 或 App Review Board。申诉最有效的场景是审核员明显误解，不是你确实违规。
- 拒审会影响后续提交吗: 直接不影响，但同一 App 反复同类拒审可能被打更严的审核标签。修根源不是修症状。
- 能加急吗: 可以，在 App Store Connect 申请 expedited review，用于真实紧急情况（崩溃、关键 bug 修复）。别滥用，Apple 会注意。
- 审核员前后不一致怎么办: 有时确实不一致——不同人不同解读。之前批准过就在申诉里引用之前的批准。