从 TestFlight 到 App Store 审核：vibe 项目的移动端上架实战

开篇先划界：这篇讲什么、不讲什么

本篇讲的是商店上架与审核，与站内两篇明确分工：cycle51 的资讯 google-play-personal-vibe-coded-apps-october-2026 讲的是 Google Play 的"私人分发"（不用开发者账号、只装给自己）——那是不上架的路；本篇讲的是正式上架的路（App Store + Google Play 双商店审核实战）。另外站内 vibe-project-mobile-experience-checklist（移动端体验清单）讲的是"产品质量"，本篇讲的是"审核合规"，互为上下游——体验清单是上架前先修好的，审核是修好之后才过的。

vibe 项目最大的错觉，是"代码跑通了就等于能上线"。实际上从"模拟器里能跑"到"商店里能搜到"，中间隔着一套完全独立的工种：证书、签名、元数据、隐私声明、内测轨道、审核话术。AI 能替你写代码，但替不了你回答审核员的问题。下面这份指南按真实上架顺序铺开，每一节都是一人团队会真实踩到的坑。

移动端上架全流程图：TestFlight 内测、商店审核（含被拒回环）与发布上线

图 1：vibe 项目移动端上架全流程——iOS 走 TestFlight 到 App Store，Android 走内测到 Play 审核；被拒不是意外，是流程的一部分。

一、上架前自检清单：14 项，漏一项审核多排一周队

提交审核之前，先把这 14 项逐一打勾。每一项都是真实世界里让一人团队多等一周的元凶：

1. Bundle ID / applicationId 锁定。iOS 的 Bundle ID 和 Android 的 applicationId 一旦发布就改不了。别用 com.example.myapp 这种占位符上线，也别把包名和公司名拼错——改名唯一的办法是下架重发，评价和下载量清零。

2. 签名资产备份离线。iOS 的 distribution 证书 + provisioning profile，Android 的 keystore 文件和密码。丢了 keystore，Google Play 上你这个应用就永远更新不了。放进加密备份，别只躺在某台电脑里。

3. 内购商品全部配齐。价格档、订阅组、免费试用期、"恢复购买"按钮。vibe 项目常见翻车：AI 生成的 paywall 上写着"¥18/月"，后台商品配的是 tier 3（¥25）——价格对不上直接被拒。订阅必须在设置页之外也有入口让审核员找到恢复购买。

4. 推送证书就绪。iOS 用 APNs Auth Key（一份 key 通用于所有 App，别用快过期的证书），Android 配好 FCM。审核员不会测推送，但上线当天才发现推送没配，等于白上架。

5. 深链双向验证。iOS Universal Links 的 apple-app-site-association 文件、Android App Links 的 assetlinks.json，必须已经部署在域名根目录且 HTTPS 可访问。AI 写代码时经常"假装"配了深链——文件没上传、Content-Type 不对，审核不查这个，但用户点分享链接跳浏览器时你就露馅了。

6. 隐私政策 URL 可访问。必须是公网可打开的网页，不能是 GitHub 仓库里的 markdown 链接（裸文件页会被判无效），不能 404。双语应用建议中英各一份。

7. 隐私声明表单填完。App Store 的 Privacy Nutrition Label、Google Play 的 Data Safety 表单（见第三节）。表单和代码行为不一致是高频被拒理由，填完再提交。

8. 账号删除入口已上线。见第四节，这是硬性铁律，没有就别提交。

9. 审核员演示账号。App 需要登录才能用？在 App Store Connect 的"App 审核信息"里填演示账号密码。vibe 项目最常见的 2.1 被拒就是"审核员进不去"。演示账号要能走完核心流程，别给一个空数据的僵尸号。

10. 出口合规问题如实回答。用了 HTTPS（基本都用了）就要回答加密相关问题；标准 HTTPS 选豁免即可。别让 AI 帮你瞎填"是/否"，答错会被打回重走流程。

11. 目标版本达标。Android 新应用必须 target API 36（Android 16，2026 年 8 月 31 日起生效），iOS 用当年最新 Xcode 构建。这是提交时的硬门槛，机器直接拦，不用等人工审核。

12. 截图与元数据合规。各尺寸截图齐全（别用模拟器状态栏带"9:41 以外时间"的图凑合，倒不会被拒但显得不专业），描述里不出现"免费"然后内购收费、不出现竞品名字、不写"测试版"字样。

13. 真机回归一遍。审核员用的是真机和当下最新系统。AI 在模拟器上跑通的代码，在真机弱网、深色模式、大字体下各有各的死法。至少借一台旧 iPhone 测一遍启动和核心流程。

14. 第三方 SDK 隐私清单。iOS 要求常用第三方 SDK 提供 privacy manifest（2024 年 5 月起），检查 Podfile/Gradle 里每一个 SDK 的版本是否在合规名单上。分析、推送、崩溃统计 SDK 是重灾区，见第三节。

二、App Store 审核实战：三大高频被拒理由

苹果的审核意见是模板化的， guideline 编号就是病历号。vibe 项目翻车集中在三个编号上：

5.2.1 法律/知识产权与隐私。这是 vibe 项目的头号杀手，典型形状有三种。第一，隐私政策链接打不开或文不对版——AI 生成的模板隐私政策里还留着 "[Your Company Name]" 占位符，审核员一眼看穿。第二，权限申请文案空洞：调用相机只写"需要访问相机"，正确写法是"需要访问相机，用于扫描…的具体功能"。iOS 要求每个权限都有 purpose string，写不清楚用途会被打回。第三，收集了数据但隐私清单说"未收集"——用了 Firebase Analytics 却勾了"不收集数据"，前后矛盾是 5.2.1 的标准死法。

4.2 最小功能（Minimum Functionality）。苹果的原话是"App 应该包含功能、内容和 UI"，翻译成人话：套壳会被拒。vibe 项目的典型翻车形状：把官网用 WKWebView 包一下就提交；或者 AI 生成的"记账 App"只有增删改查三页，没有任何原生体验。过审的最低线是：有原生导航、有离线可用的核心功能、有区别于网页的交互（推送、手势、桌面小组件至少占一样）。如果你做的确实是内容型应用，那就把内容做厚——空列表页、"即将上线"占位页是 4.2 的靶子。

2.1 崩溃与完整性。审核员在 iPad 上点了一下闪退，你就收到 2.1。vibe 代码的崩溃有鲜明特征：只在特定系统版本崩（AI 按旧 API 生成的代码在新系统上行为变了）、只在无网络时崩（没做弱网兜底）、只在审核员的地区崩（硬编码了某个地区才有的服务）。提交前做三件事：Xcode Organizer 里看崩溃日志清零、TestFlight 上先让外部测试者跑一轮、把启动页 3 秒内的所有网络请求改成可失败、可重试。

收到被拒先别慌：先看编号，再看审核员附的具体截图和复现步骤。80% 的被拒是"按他说的改完重提"就能过的，剩下 20% 才需要申诉（见第七节）。

三、隐私清单：数据收集类型怎么填才不被打回

Privacy Nutrition Label（隐私营养标签）是 App Store Connect 里的一份问卷，问的是"你的 App 收集哪些数据、用来干嘛"。填错的代价是 5.2.1 被拒。核心原则只有一条：按 SDK 的实际行为填，不按你的主观意愿填。

最常见的坑是第三方 SDK 的连带责任。你的代码可能一行数据都没收集，但只要集成了下面这些，你就在"收集"：推送 SDK（极光、个推、Firebase Cloud Messaging）会拿设备标识和推送 token；分析 SDK（Firebase Analytics、Umeng）会拿设备信息和使用行为；崩溃统计（Crashlytics、Sentry）会拿设备型号和崩溃日志；广告 SDK 更不用说。这些都必须在隐私清单里声明为"收集"，用途选"分析""应用功能"等对应项。苹果 2024 年 5 月起还要求常用第三方 SDK 自带 privacy manifest 文件——集成老版本 SDK 的项目，先升级 SDK 再提交，否则构建期就会被警告。

一人团队的填表 SOP：1）列出所有第三方 SDK，去各家官网的隐私文档页抄"收集的数据类型"原文；2）对照苹果的 14 大类数据（联系信息、标识符、使用数据、诊断等）逐项勾选；3）"是否用于追踪"这一项想清楚——用了广告 ID 或跨应用共享数据就必须勾"是"，勾了就要配 App Tracking Transparency 弹窗，不配又会被拒；4）填完后让没参与开发的朋友读一遍，"一个外行能不能看懂你在收集什么"。审核员就是那个外行。

还有一个隐形坑：表单和隐私政策正文要一致。清单里勾了"收集精确位置"，隐私政策里却写"我们不收集位置信息"——这种自相矛盾是审核员最喜欢抓的。改一处，两处一起改。

四、账号删除铁律：App 内必须可删账号

这是苹果的硬性规定（Guideline 5.1.1(v)，2022 年 6 月 30 日起生效）：只要你的 App 支持注册账号，就必须在 App 内提供删除账号的入口。"发邮件给客服删除"不算数，"去网页版删除"不算数，停用账号也不算数——必须是用户自己在 App 里点几下就能发起删除。

一人团队的最小实现，分两步走。第一步，客户端：在"设置 → 账号 → 删除账号"放一个红色按钮，点开后二次确认（建议让用户输入 DELETE 或长按确认，防止误触），确认后调后端接口。第二步，后端 SOP：DELETE /api/account 接口做四件事——使所有登录 token 失效、删除或匿名化用户产生的数据（帖子、订单、聊天记录二选一：删掉或断开与账号的关联）、清理第三方服务里的用户记录（推送别名、分析 ID）、如果是 Sign in with Apple 登录的，调用苹果接口撤销授权 token。允许设置一个宽限期（比如 7 天内可撤销），但必须在界面上写清楚。

注意 Google Play 的要求更进一步：除了 App 内入口，还要求提供一个公开的网页删除入口（不需要登录就能看到的删除申请页）。做双端上架的，一次把两个入口都做了：App 内按钮 + 官网 /delete-account 页面。审核时把这两个位置写进备注，省一轮来回。

数据保留的边界要提前想好：法律要求保留的（交易记录、发票）、反欺诈需要的，可以保留，但必须在隐私政策里写明"删除账号后我们会保留 X 数据 Y 天，因为 Z"。审核员接受"有理由的保留"，不接受"悄悄保留"。

五、TestFlight 内测 SOP：分组、递增与 90 天过期

TestFlight 是苹果官方的内测通道，也是上架前最后的试金石。两类测试者，两种用法：

内部测试者（最多 100 人）。必须是 App Store Connect 团队成员。构建上传处理完就能装，不经过苹果审核，适合每天多次的快速迭代。一人团队的用法：把自己、朋友、早期用户加为内部测试者，当天改完当天就能让他们验证。

外部测试者（最多 10000 人）。通过邮件或公开链接邀请。第一个外部构建需要过一次 Beta App Review（约 1 天，检查项比正式审核松），之后同版本的新构建自动放行。适合上线前的公开内测。注意公开链接一旦发出就收不回——链接泄露等于公测，重要版本别用公开链接。

三个硬约束，写进你的发布 SOP 里：第一，构建 90 天过期。TestFlight 构建从上传起 90 天后自动失效，测试者手里的 App 直接打不开（含本地数据）。内测周期长的项目，在第 80 天左右必须发新构建续命，别等用户来问"App 怎么打不开了"。第二，版本号只增不减。build 号（CFBundleVersion）每次上传必须递增，写错一次就得重新打包上传。用 fastlane 的 increment_build_number 或 Xcode 自动管理，别手填。第三，每个构建都要写"测试内容"。告诉测试者这版测什么，否则 100 个人的内测群会变成 100 个人都在测登录页。

vibe 项目的额外建议：把 TestFlight 的崩溃反馈和用户反馈当成正式审核的预演——苹果审核员测的深度还不如一个认真的外部测试者。外部测试跑满两周、崩溃清零再提交正式审核，能把 2.1 被拒的概率压到最低。

六、Google Play 侧：三道独有门槛

Play 这边的审核逻辑和苹果完全不同，有三道苹果没有的门槛：

第一，Data Safety 表单。对应苹果的隐私清单，但填在 Play Console 的"应用内容"里。同样要求声明第三方 SDK 的数据行为，同样要求和隐私政策一致。一个细节差异：Play 明确要求声明"数据是否会与第三方共享"，用了广告 SDK 的必须如实勾选，否则下架比被拒更疼——上架后被发现声明不实是直接下架。

第二，目标 API 级别。2026 年 8 月 31 日起，新应用和更新必须 target Android 16（API 36），否则提交时直接被机器拦截。这是硬门槛，每年往前滚一级。vibe 项目的坑在于教程和模板过时：很多 AI 生成的项目模板还默认 target 34 或 35，提交前检查 build.gradle 里的 targetSdk。升 API 级别可能带来行为变更（Android 16 强制 edge-to-edge 等），别在提交当天才升。

第三，新个人账号的封闭测试 14 天。2023 年 11 月 13 日之后注册的个人开发者账号，上架前必须跑封闭测试：至少 12 个测试者连续 14 天保持加入状态，生产轨道才会解锁。注意"连续"二字——中途有人退出、人数掉到 12 以下，时钟重算。实战策略：招 18~20 人（留出流失余量），第一天就把所有人拉进组，用 Google Group 管理名单，每天看一眼人数。组织账号（公司主体）不受此限。App 必须打成 AAB 格式上传，APK 新应用已不接受。

费用和时长对照：Play 开发者账号 25 美元一次性，苹果 99 美元/年；苹果首发审核通常 1~2 天，Play 新账号 7 天起步。两边审核排队相互独立，可以并行提交，别等一边过了再提另一边。

移动端上架全流程图：TestFlight 内测、商店审核（含被拒回环）与发布上线

图 2：App Store vs Google Play 审核差异对照——费用、测试要求、隐私声明、账号删除、目标版本、申诉通道九项全对比。

七、被拒急救包：邮件、申诉信与加急审核

被拒邮件的阅读顺序：先看 guideline 编号（定位病因），再看审核员写的具体复现步骤和截图（定位病灶），最后看 Resolution Center 里的历史记录（有没有前科）。编号决定策略：2.1（崩溃）、5.2.1（隐私）这类"事实型"被拒，照着改、改完重提，通过率最高；4.2（最小功能）、4.3（马甲包）这类"判断型"被拒，才需要动用申诉。

申诉信模板（写在 Resolution Center，用英文，三段式）：第一段复述问题，"We understand the app was rejected under guideline X for [reason]"；第二段讲你改了什么，精确到版本号和位置，"In build 1.2.3 (build 45), we have [具体改动]. The account deletion option is now available at Settings → Account → Delete Account"；第三段给验证路径，"You can verify by [登录演示账号/操作步骤]"。语气就事论事，不辩解、不抱怨。审核员一天看几百封，写清楚"改了什么、在哪验证"就是最大的尊重。

加急审核（Expedited Review）是苹果提供的插队通道，但只能用于真正的紧急情况：线上严重 bug 导致用户无法使用、配合有明确日期的发布活动（如发布会、节日版本）。申请入口在 App Store Connect，每次申请要说明紧急理由。注意两点：一是别滥用，一年用个两三次是正常频率，每月都申请会被无视；二是加急只加速排队，不降低标准，该被拒还是被拒。Google Play 侧对应的是严重 bug 的优先审核，同样只给真正的线上事故用。

最后一句大实话：把"被拒 2~3 轮"写进你的上线时间表。vibe 项目从写完代码到商店上架，留三周给审核和整改是健康的预期——排得太紧，最后一周你会同时面对审核意见、用户反馈和自己的血压。