Archive 成功不等于可以发布。 Xcode 27 iOS App 发布前验收至少要通过身份信息、构建产物、签名能力、上传状态和 App Store Connect 关联这 5 类指标；只有构建完成平台 Processing、能够在 TestFlight 中安装或被选为送审构建，发布闭环才算完成。Apple 官方也将 Archive、上传、平台处理和选择送审构建视为不同环节，而不是一个按钮完成的单一结果。(Apple 的 Xcode 分发文档)
这篇内容适合第一次提交 iOS App、需要使用清单完成首次验收的独立开发者；也适合维护远程 Mac 打包机、希望确认常驻环境能重复发布的开发者，以及使用脚本或 CI 自动上传的小团队。
⚠️ 本文最后更新于 2026 年 9 月 22 日，数据核实自 Apple Developer 的 Xcode 发布记录、Xcode 分发文档和 App Store Connect Help。Xcode 27 正式版与 Xcode 27.2 Beta 必须分开验证，Beta 的行为不能直接当作正式版结论。(Apple Developer 的 Xcode 发布记录)
先用发布结果定义“验收通过”
Archive 完成后，仍然需要继续核对导出、签名、上传、Processing、TestFlight 或送审关联；Archive 只能证明某次构建已经被 Xcode 保存为归档，并不证明上传成功，更不证明 App Store Connect 已经接受该构建。
Apple 对 Archive 的定义是：它包含应用构建和调试信息，由 Xcode 保存到归档包中；开发者可以在 Organizer 中进行 Validate App 或 Distribute App。换句话说，Archive 是发布链路的产物入口，而不是发布终点。
| 发布节点 | 应检查的证据 | 通过标准 | 未通过时的动作 |
|---|---|---|---|
| Archive | Xcode Organizer 中的归档记录 | 归档对应正确 Scheme、平台和配置 | 删除错误归档，重新用 Release 方案构建 |
| IPA / 导出产物 | 导出目录、导出日志、产物信息 | 导出类型与 TestFlight 或 App Store 分发目的匹配 | 检查 ExportOptions、签名方式和目标平台 |
| 上传完成 | Xcode、Transporter 或命令行交付日志 | 上传工具没有把本地退出成功误判为平台完成 | 进入 App Store Connect 查看 Build Uploads |
| Processing 完成 | App Store Connect 的构建状态 | 状态为 Complete，且没有未处理的错误或关键警告 | 打开状态详情，按错误信息修复或重新上传 |
| TestFlight 可用 | TestFlight 构建页、实际安装结果 | 构建出现在正确版本下，并能被测试人员获取 | 检查平台版本、合规问题和测试分发设置 |
| 可送审 | App 版本页的 Build 区域 | 已选择正确构建并保存，提交按钮不再缺少构建 | 重新选择构建，补齐合规和版本资料 |
App Store Connect 会使用 App Bundle 中的 Bundle ID 和版本号，将上传构建关联到对应 App 和版本；Build string 用于在系统中唯一识别构建。因此，验收时不能只截图 Xcode 设置页，必须回到最终 Archive、导出产物和平台后台核对实际值。(App Store Connect 的上传构建说明)
第一步：核对项目身份与版本指标
版本信息验收的对象不是项目文件本身，而是最终构建内实际写入的值。重点检查以下字段：
- [ ] Bundle ID 与 App Store Connect 中的 App 记录完全一致。
- [ ] Target、Scheme 和平台目标对应本次要发布的 iOS App。
- [ ] Team 属于正确的 Apple Developer Program 团队。
- [ ] Version number 对应本次 App Store 版本。
- [ ] Build string 是本次准备上传的唯一构建标识。
- [ ] App Store Connect 中已经创建对应 App 记录，并且当前账号具备操作权限。
Apple 将 CFBundleIdentifier 作为应用在系统中的唯一身份；Version number 和 Build string 则用于标识应用版本与具体构建。版本号通常用于用户看到的 App 版本，Build string 则用于区分同一个版本下的不同上传产物。(Apple 的应用分发准备文档)
版本号和 Build 号应该从哪里核对？ 先从最终 Archive 或导出产物中读取实际值，再与 Xcode General 面板和 App Store Connect 目标版本逐项比对。若只是同一 App 版本追加修复构建，通常保持 Version number 不变并提高 Build string；若准备创建新的商店版本，则应先确认 App Store Connect 中已经建立对应版本记录。
这里要区分两种失败：
- 版本号错误：构建可能被关联到错误的 App 版本，后续需要重新设置版本号并重新 Archive。
- Build string 重复：如果之前的构建已经成功处理，不能继续使用同一个 Build string；如果上传失败，Apple 文档说明失败构建的 Build number 可以复用，但仍应先确认失败原因，而不是盲目重传。(App Store Connect 的构建与元数据说明)
如果小团队使用自动化脚本，建议把 Bundle ID、Version number、Build string、Scheme 和 Team ID 写入上传前日志，并将日志与 Archive 文件使用同一个脱敏任务编号保存。这样在远程 Mac 打包或断线恢复后，仍能证明“上传的构建”就是“本次验收的构建”。
第二步：确认 Archive、IPA 与签名来自同一次构建
Archive、IPA、模拟器构建和 Debug 构建不能互相替代。模拟器构建可以用于本地运行，Debug 构建可以用于开发调试，但面向 TestFlight 或 App Store 的交付必须从符合分发目的的 Archive 产生。
- [ ] Archive 创建时使用正确的 iOS 设备目标，而不是仅验证模拟器运行。
- [ ] Archive 创建时间、Git 提交或构建标识已记录。
- [ ] 导出的 IPA 来自刚刚验收的 Archive。
- [ ] Entitlements 与目标能力一致，例如推送、关联域名或应用组。
- [ ] Provisioning Profile 与 Bundle ID、Team 和分发用途一致。
- [ ] 签名身份属于正确团队，并且证书没有过期或被撤销。
- [ ] dSYM 与该次 Archive 对应，并且已经进入日志或制品保存范围。
Apple 的分发流程会根据所选方式重新打包 Archive；Xcode 的 TestFlight & App Store 选项还会处理分发签名、符号文件和上传步骤。验收重点不是“是否能导出一个 IPA”，而是导出的 IPA 是否具备目标渠道需要的签名和权限。
在远程 Mac 上尤其要检查 Keychain 和非交互式脚本。人工打开 Xcode 时可以弹出证书选择或登录提示，但 CI 脚本、SSH 会话或无人值守任务不一定能完成这些交互。若脚本依赖临时登录状态、没有明确指定 Keychain，或者凭据注入只在图形界面中生效，第一次手动构建成功并不能证明下一次可以复现。
远程发布环境需要先确认哪些边界？ 至少要验证四个方面：签名凭据是否可被当前用户读取、脚本是否能在非交互式会话运行、构建日志是否能在断线后取回，以及失败后是否能从同一个任务目录恢复。远程 Mac 适合承载重复构建和上传，但不能替代开发者对最终产物和 App Store Connect 状态的确认。
第三步：按平台状态判断上传是否真正完成
上传工具显示成功，只能说明文件已经交给 Apple 的交付入口。App Store Connect 仍需要处理构建，构建在处理完成前可能不会出现在可选列表中。Apple 明确说明，上传后的构建必须经过系统处理，完成后才会显示在 App Store Connect；开发者也可以在 Build Uploads 中查看警告、错误和交付记录。(App Store Connect 的上传构建说明)
| App Store Connect 状态 | 实际含义 | 验收动作 |
|---|---|---|
| Processing | Apple 仍在处理上传构建 | 记录上传时间，等待状态更新，不要立即重复上传 |
| Failed | 处理结束但发现问题 | 打开构建详情，修复所有错误后再决定是否重传 |
| Complete | 构建处理成功，可以进入测试流程 | 继续检查警告、版本关联、合规和 TestFlight |
| Complete + 警告 | 处理成功，但仍有需要关注的信息 | 阅读警告内容，确认不会阻断测试或送审 |
| 长时间 Processing | 处理可能出现异常 | Apple 文档建议在超过 24 小时后提交 Feedback Assistant 或联系支持 |
平台后台怎样证明构建归属正确？ 进入 App 的 TestFlight 页面，展开对应的 Version number，再核对 Build string、上传日期和时间、平台以及构建详情。不要只根据上传工具的退出码判断成功，也不要把最近上传的构建自动当成当前版本应该使用的构建。
如果构建是通过 Transporter、xcrun 或 API 上传，交付日志应至少包含脱敏后的版本号、Build string、上传时间、返回状态和错误摘要。Apple 支持通过 Xcode、Transporter、altool 以及 App Store Connect API 上传构建，但不同工具的本地日志并不等于 App Store Connect 的最终处理状态。
提醒： App Store Connect 显示 Complete，也不代表所有问题都自动消失。Complete 状态旁边仍可能存在警告或其他信息；验收记录应保存状态详情，而不是只保存一个绿色状态截图。(App Store Connect 的构建与元数据说明)
第四步：验证 TestFlight 构建与送审版本是否指向同一产物
TestFlight 可用与可送审是两个不同判断。TestFlight 主要验证构建是否已经处理完成、能否分发给测试人员；送审则还要求该构建被明确添加到 App Store Connect 的某个 App 版本，并且版本资料、出口合规和其他必填项目没有阻断。
- [ ] 构建出现在正确的平台和 Version number 下。
- [ ] 构建状态已经 Complete，而不是仍处于 Processing。
- [ ] TestFlight 页面可以查看该构建的 Build string 和元数据。
- [ ] 至少完成一次真实设备安装或内部测试分发。
- [ ] Missing Compliance 等状态已经处理。
- [ ] App 版本页的 Build 区域已经选择本次准备送审的构建。
- [ ] 选择构建后点击 Save，并重新打开页面确认仍然关联。
- [ ] 提交前确认账号角色、协议状态和版本资料没有额外阻断。
Apple 允许一个 App 版本关联一个提交构建，但在提交 App Review 前可以更换所选构建。选择路径是在 App Store Connect 的版本页面进入 Build 区域，添加已经上传并处理完成的构建，然后保存。(Apple 的选择送审构建说明)
构建状态变成 Complete 后，还缺少哪些送审条件？ Complete 只说明构建已经处理成功并可用于测试；仍需确认它位于正确版本下、出口合规问题已经回答、版本页面已经选中该构建，并且其他必填信息与协议状态没有阻断。Apple 的发布流程要求开发者选择要提交的构建，再提交 App Review，而不是把任意 Complete 构建自动送审。
首次提交时，还要检查 App Store Connect 是否已有 App record。Apple 要求在上传构建前创建 App 记录；如果账号角色不具备创建或管理权限，构建本身可能没有问题，但流程仍会在平台侧停住。Account Holder、Admin、App Manager 和 Developer 的权限范围并不相同，自动化账号也应单独核对角色。(Apple 的新增 App 记录说明)
第五步：用一张验收单决定是否停止发布
下面的清单适合在本地 Mac、远程 Mac 或自动化流水线中执行。每一项都应留下对应证据；如果某项无法回答，就不要把发布状态写成“已完成”。
身份信息
- [ ] 最终产物中的 Bundle ID 与 App Store Connect App record 一致。
- [ ] Version number 与目标 App 版本一致。
- [ ] Build string 与本次上传记录一致。
- [ ] Team、Target 和平台目标没有混用。
- [ ] App Store Connect 中的 App 记录、平台和版本均正确。
构建产物
- [ ] 使用 Release 分发目的创建 Archive。
- [ ] IPA 来自本次 Archive，而不是旧导出目录。
- [ ] Entitlements、Provisioning Profile 和签名身份均来自同一分发链路。
- [ ] dSYM 已与 Archive 建立对应关系并完成留存。
- [ ] 产物路径、提交标识和日志路径已脱敏记录。
上传交付
- [ ] Xcode、Transporter 或命令行日志显示文件交付成功。
- [ ] 已进入 App Store Connect 的 Build Uploads 查看状态。
- [ ] 已记录 Processing、Failed 或 Complete 的状态详情。
- [ ] Complete 旁边没有未处理的关键警告。
- [ ] 长时间 Processing 时没有通过重复上传掩盖原始问题。
TestFlight 与送审
- [ ] 构建出现在正确 Version number 下。
- [ ] TestFlight 页面可以查看 Build string 和元数据。
- [ ] 已完成一次真实设备安装或测试分发。
- [ ] Missing Compliance 等状态已经处理。
- [ ] App 版本页已选择正确构建并保存。
- [ ] 最终提交页面没有要求重新选择构建。
若其中任一项只能凭“看起来应该没问题”回答，验收应停在当前指标，先补证据再继续。这样做比提交后才发现 Bundle ID、Build string 或签名来源错误更容易回退，也更适合远程 Mac 打包环境的重复执行。
为什么远程 Mac 只能是执行环境，而不是最终裁判
远程 Mac 可以承载 Xcode 27、Archive、导出、签名和上传，尤其适合不希望购买一台专用 Mac mini、但又需要重复执行 iOS 构建的小团队。不过，远程环境解决的是工具链可访问性和任务执行问题，不能替代 App Store Connect 对构建状态、版本关联和 TestFlight 安装结果的最终确认。
在实际运维中，至少要把以下内容分开保存：
- 构建输入：代码提交、Scheme、版本号、Build string。
- 构建产物：Archive、IPA、dSYM 和导出配置。
- 签名证据：使用的 Team、Profile、Entitlements 和证书类型。
- 交付日志：上传工具、上传时间、返回信息和平台状态。
- 回查结果：App Store Connect 版本页、TestFlight 页面和实际安装结果。
如果团队需要了解 RUVCLOUD 的远程 Mac 使用入口，可以先按本文清单验证一次完整发布闭环，再决定是否将重复构建迁移到远程环境。这里的重点不是把所有发布步骤交给主机，而是确保每次任务都能从产物、日志和平台状态回查。
最终判断：什么时候可以提交，什么时候应该回退
可以提交的条件是：身份信息一致，Archive 和 IPA 来自同一构建，签名与 Entitlements 能够支持目标分发方式，App Store Connect 状态为 Complete，构建已经位于正确的 App 版本下，并且 TestFlight 或最终送审页面能够确认同一个 Build string。
应当回退的条件包括：
- Archive 成功，但无法证明 IPA 来自该 Archive。
- 上传工具显示成功，但 App Store Connect 仍没有对应构建。
- 构建已经 Complete，却出现在错误的 Version number 下。
- TestFlight 可以安装，但 App 版本页没有选择该构建。
- 远程 Mac 的签名依赖人工弹窗，脚本无法在非交互式会话重现。
- 构建存在警告或 Missing Compliance，团队还没有确认其影响。
如果当前方案依赖个人 Mac 临时开机、手动解锁 Keychain、人工点击上传和本地保存日志，偶发提交时未必需要改变；但对于需要重复 Archive、自动上传、失败恢复或多人共享的团队，这种方式的缺点是环境不可持续、凭据状态难以复核、断线后任务上下文容易丢失。此时，租用 RUVCLOUD 的远程 Mac 可以作为更适合重复发布的执行环境；若只是偶尔提交一次，则按需使用即可，不必为了单次发布长期租用。
需要持续运行远程 Mac、配置签名与自动化发布流程的开发者，可以先查看 RUVCLOUD 的方案与使用说明，再根据每月发布频率、是否需要 7×24 小时在线以及是否必须保留独立签名环境做选择。核心验收原则不会改变：Mac 负责稳定执行，App Store Connect 才负责确认构建是否真正走完发布闭环。