LESSON 54 / 575 分钟
Archive、TestFlight 与 App Store
从 Xcode 运行到用户安装，中间还有签名、归档、测试分发和审核。
用你的前端经验理解
类似构建、预发布、正式上线，但 App 的签名身份、商店元数据与系统兼容性是额外的发布契约。
01 / 理解问题
为什么需要它
发布意味着把开发环境中的应用变成陌生用户能够安装、更新和理解的产品。代码之外还包括签名、版本号、隐私声明、商店资料与审核可用账号。打包成功只说明生成了产物，不能证明生产服务配置、升级迁移和审核流程都已准备好。
它是怎样工作的
Archive 使用面向分发的构建流程，TestFlight 用于分发测试版本，App Store Connect 管理商店信息与发布。开发环境与生产环境应明确分离，尤其是 CloudKit schema、内购商品和后端地址。隐私与商店政策会变化，提交前按当前官方要求核对，而不是长期复制旧教程清单。
02 / 掌握要点
把关键概念连起来
1
打包
核对版本号/构建号、Bundle ID、签名和生产配置，Archive 后通过 Organizer 验证和分发。
2
测试分发
上传 App Store Connect，配置 TestFlight 测试，收集设备反馈、崩溃与关键路径问题。流程稳定后可用 Xcode Cloud 等 CI 自动构建和测试，发布身份与凭证仍需正确管理。
3
发布
补充隐私信息、截图、审核说明和必要的测试账号；检查最低系统、可用性保护及第三方 SDK。商店规则以发布当时官方文档为准。
03 / 案例推演
第一次发布前走一条真实路径
- 从干净安装开始添加数据、关闭重开，再检查权限拒绝与断网；确保产品不依赖开发机器上的服务。
- 从旧测试版本带数据升级，确认模型迁移和登录恢复；全新安装成功无法覆盖这类风险。
- 让测试者按明确步骤完成核心任务，收集具体问题；准备审核人员能访问的演示条件和必要说明。
这里需要你亲自判断
不要在发布包里保留调试密钥、测试服务器或虚假的隐私声明；不要假设上传成功就是审核通过。
04 / 动手验证
做一个小练习
列出发布前五项核对：签名、生产配置、真机验证、隐私信息、审核可访问性。
- 列出开发、测试与生产各自使用的后端、云容器环境和商品配置。
- 写一份三分钟核心验收流程，包含一次失败和恢复。
展开参考思路与验收标准
可交付版本应能独立安装并完成闭环，且不会把真实用户连接到测试服务。发布失败时先定位签名、构建、配置还是审核问题，不要一律重建工程。
05 / 检查理解
TestFlight 在交付流程中的作用是什么？
答对理解题后即可标记完成