如果你经常从 Xcode 上传开发构建，担心选错分发方式，这篇文章适合你。

如果你使用远程 Mac 或自托管 Runner 自动上传，需要把内部测试、外部 Beta 和正式发布权限拆开，也可以直接按文中的指标配置。

如果你准备首次邀请外部测试者，但还不清楚 Internal Only 的限制，重点看“测试对象”和“后续资格”两节。

最后更新于 2026 年 9 月 11 日，版本与分发规则核实自 Apple Developer Documentation、App Store Connect Help、Xcode 27 RC 发布信息及官方 Release Notes。

截至 2026 年 9 月 11 日，Apple 已确认 App Store Connect 支持上传使用 Xcode 27 RC 构建的 App。本文不对 Xcode 27 正式版的发布日期作额外推测。 Xcode 27 RC 发布信息

在 Archive 完成之前，你就应该确定这个构建的用途。Xcode 的分发选项发生在 Organizer 中的 Distribute App 环节，上传之后再根据测试对象临时补救，会增加重新构建、重新签名和重新管理版本号的成本。

Apple 将 TestFlight 与 App Store 定义为可用于 TestFlight 和 App Store 提交的普通分发方式，而 TestFlight Internal Only 用于限制团队内部访问，并阻止开发构建进入外部测试和 App Store 提交链路。 Apple 的 Xcode 分发文档

你的判断可以先按下面三条执行：

• ✅ 只给团队成员验证：选 TestFlight Internal Only。
• ✅ 需要邀请客户、社区用户或外部 Beta 测试者：选普通 TestFlight 与 App Store。
• ✅ 同一个项目既要内部验证，又可能产生候选发布版本：建立双通道，分别上传不同构建，不要把 Internal Only 当作中间状态。

这里的关键不是“哪个选项更省一步”，而是构建获得了什么资格。Internal Only 构建会被标记为内部构建，只能加入内部测试组，不能加入外部测试组，也不能直接进入正式提交流程。 Apple 关于内部测试者与构建范围的说明

App Store Connect 中的内部测试者，必须是拥有相应访问权限的 App Store Connect 用户。外部测试者则不是 App Store Connect 用户，通常通过邮件邀请或公开链接加入外部测试组。

Apple 当前的 TestFlight 规则允许每个 App 最多添加 100 名内部测试者，外部测试者上限为 10,000 人。这些是测试者资格上限，不代表每个项目都应该使用到上限。 TestFlight 总览

已经标记为 Internal Only 的构建，后续还能直接进入外部测试吗？

不能把同一个已标记构建直接转换成普通外部测试构建。Apple 的帮助页明确说明，带有 Internal Only 标记的构建只能加入内部测试组；外部测试者不能加入这类构建。

如果后续需要邀请外部测试者，你应回到源码和 Archive 阶段，重新生成一个普通 TestFlight 构建，再把新构建加入外部测试组。 Apple 的测试者与构建关联规则

外部测试组看不到某个 TestFlight 构建，通常是什么原因？

最常见的原因不是测试者邮箱写错，而是构建本身带有 Internal Only 标记。App Store Connect 会根据构建分类限制可选测试组：内部标记构建只能进入 Internal Testing，普通构建才可以按规则加入外部测试组。 Apple 的外部测试邀请说明

你可以把测试对象分成三类：

• 团队成员：需要 App Store Connect 账号和对应角色，适合 Internal Only。
• 客户、社区用户、合作方：属于外部测试者，使用普通 TestFlight 构建。
• 最终用户：不应通过内部测试通道处理，应进入正式 App Store 发布流程。

内部测试适合验证开发开关、数据库迁移、签名环境和 CI 产物。外部测试则适合收集真实设备反馈、验证新用户流程和检查非团队环境下的产品表现。两者的测试对象不同，不能只因为“都叫 TestFlight”就共用同一条上传策略。

Internal Only 最适合两类构建：

• 明确只给内部成员验证的实验功能；
• 带有调试开关、临时接口或尚未准备好对外展示的开发构建。

它的核心价值是形成一道资格边界：即使某个开发构建被上传到 App Store Connect，也不能直接被加入外部测试组或提交给客户。对于多人协作或自动化上传，这种限制可以降低误操作影响。

但它不适合下面这些情况：

• 这个构建可能很快成为正式候选版本；
• 你已经准备邀请外部测试者；
• 你需要让客户或非团队成员安装；
• 你希望保留同一个构建继续进入外部测试和 App Store 提交链路。

内部验证完成后，原构建还能继续用于正式提交吗？

不能把这个 Internal Only 构建直接作为普通正式提交构建使用。更准确地说，Internal Only 选项的设计目的就是限制团队内部访问，并阻止开发构建被提交到 App Store。

若后续版本需要进入正式发布，应重新 Archive，并在分发时选择普通 TestFlight 与 App Store。

重新构建并不是“点一下转换”这么简单。你需要重新处理以下项目：

• CFBundleVersion 或构建号是否递增；
• Archive 是否使用正确的 Scheme；
• 签名证书和 Provisioning Profile 是否对应发布用途；
• 上传凭据是否具备所需权限；
• CI 是否会把旧构建号、旧产物或旧日志误认为候选版本；
• 外部测试信息和正式提交元数据是否已经准备。

Apple 说明，每次上传的 Bundle ID、版本号和构建号会影响 App Store Connect 中的关联与识别；上传后的构建还需要经过 Apple 系统处理后，才会出现在 App Store Connect。 Apple 的构建上传说明

因此，Internal Only 的好处是降低误发布风险，代价是牺牲该构建进入外部测试和正式提交的资格。普通构建的好处是后续路径更完整，代价是 CI 账号一旦配置过宽，开发构建可能被误加入发布流程。

在远程 Mac 上自动上传时，怎样区分内部验证和正式候选构建？

不要只靠分支名称区分。你至少需要同时绑定分支、Scheme、导出方式、凭据权限和人工批准条件。

一个较稳妥的设计如下：

内部验证 Job

适用于开发分支、实验分支和日常回归。

• 分支：开发分支或功能分支；
• Scheme：内部验证 Scheme；
• 构建用途：TestFlight Internal Only；
• 测试对象：App Store Connect 团队成员；
• 凭据：仅允许上传和内部测试相关操作；
• 发布限制：禁止提交外部测试审核，禁止执行正式发布动作；
• 触发方式：代码合并、手动触发或夜间回归。

候选发布 Job

适用于发布分支或人工指定的 Release Tag。

• 分支：发布分支或受保护标签；
• Scheme：Release Scheme；
• 构建用途：普通 TestFlight 与 App Store；
• 测试对象：内部测试组、外部测试组或正式提交流程；
• 凭据：单独的 App Store Connect API Key 或受限发布账号；
• 发布限制：上传后必须人工确认，再进入外部测试或正式提交；
• 触发方式：人工批准，不建议所有 Pull Request 自动触发。

Apple 支持使用 Xcode、Transporter、altool 或 App Store Connect API 上传构建。对于 CI，上传方式可以自动化，但“是否允许正式提交”不应和普通构建上传共用同一套权限。

如果你使用 Xcode 27，还要先确认 Runner 是 Apple Silicon Mac。Xcode 27 的运行环境、macOS 版本和 Runner 架构都应在 Job 启动时主动检查。 Xcode 27 Release Notes

建议在 CI 中加入以下检查，但不要把真实 Team ID、Bundle ID、API Key、主机地址或日志凭据写进脚本：

1. 检查当前 Runner 的 CPU 架构是否为 Apple Silicon。
2. 用 xcode-select 或等效方式确认当前 Xcode 版本。
3. 根据分支和人工批准状态选择内部 Job 或候选 Job。
4. 检查 Scheme、签名类型和导出配置是否匹配。
5. 确认构建号没有与已上传产物冲突。
6. 上传后等待 App Store Connect 处理，不要把“命令执行成功”当成“构建可测试”。
7. 在 App Store Connect 中核对构建标记、可选测试组和后续提交资格。
8. 将内部 Job 与候选 Job 的日志、缓存和产物目录隔离。

Apple 的构建状态页面会区分处理中的状态、可测试状态以及可提交状态。上传命令没有报错，只能说明交付请求被接受，不能证明构建已经具备外部测试或正式提交资格。 App build statuses

你可以在每次上传后执行下面的检查。它比单纯查看 CI 绿色状态更可靠。

• [ ] 在 App Store Connect 中确认构建已经完成处理。
• [ ] 检查构建号、版本号和 Bundle ID 是否属于本次发布分支。
• [ ] 如果目标是内部验证，确认构建显示为 Internal。
• [ ] 确认 Internal Only 构建只能选择内部测试组。
• [ ] 如果目标是外部 Beta，确认构建能够加入外部测试组。
• [ ] 核对外部测试是否需要提交 TestFlight App Review。
• [ ] 检查外部测试者邀请方式是邮件还是公开链接。
• [ ] 确认候选发布构建没有使用内部专用 Scheme。
• [ ] 确认正式发布 Job 使用了独立的签名与上传凭据。
• [ ] 保留脱敏后的上传记录、构建状态和人工批准记录。
• [ ] 不要因为一次资格错误就默认撤销证书、重置签名或清理全部 Archive。
• [ ] 先检查分发方式、构建分类和上传 Job 是否选错。

TestFlight 的外部测试通常涉及测试信息、外部测试组和审核流程。Apple 说明，首次提交到某个外部测试组的构建可能需要 TestFlight App Review；后续构建是否需要完整审核，要以 App Store Connect 当时显示的状态为准。不要把固定处理时间或固定审核时间当成发布承诺。

三种项目场景的最终选择

分发选项与后续能力对照

远程 Mac 双通道配置表

如果你现在使用的是一台长期在线的远程 Mac，建议将两条 Job 放在不同的 Runner 标签或不同的执行用户下。这样即使内部测试任务被触发，也不会自动拿到候选发布所需的全部权限。你可以先参考 远程 Mac 的 iOS 持续打包环境，再根据项目规模选择单机双 Job 或两台 Mac 分离运行。

TestFlight Internal Only 怎么选，最终只看一个问题：这个构建是否可能交给外部测试者，或继续成为 App Store 发布候选。

如果答案是“绝不会”，选 Internal Only。它适合内部成员、开发开关和实验性构建。

如果答案是“有可能”，从一开始就选普通 TestFlight 与 App Store。对于持续发布项目，更建议把内部验证与候选发布拆成两条 Job，分别配置 Scheme、签名、凭据和人工审批。

如果你目前的方案是让个人电脑临时运行 CI，常见缺点是设备不一定能持续在线、Xcode 版本容易被日常使用打断，签名私钥和上传凭据也更容易与开发环境混在一起。若团队已经需要每天执行内部验证和候选发布，临时借用 Mac 往往比不上一个权限隔离、可持续运行的远程 Mac 环境。

你可以先检查现有设备能否稳定运行 Xcode 27、保存 Archive，并按两条通道完成一次脱敏验收；如果本地 Mac 无法持续在线，再查看 KVMNODE 的远程 Mac 租赁方案，把它作为持续打包、签名和 TestFlight 上传环境进行评估。