TestFlight 是每一次 iOS 发布在进入 App Store 之前都要经过的分发通道：它把构建版本交到真实测试者手中的真实设备上，而不必先把应用公开发布。2026 年的机制已经相当稳定，而且 Apple 全部写进了官方文档：最多 100 位内部测试者，构建版本一处理完就能安装；最多 10,000 位外部测试者，但应用加入分组后的第一个构建版本必须先通过 App Review 审核；以及一个硬性的 90 天窗口，到期后该构建版本对所有人都不再可用。很多教程出问题，是因为把 TestFlight 当成了「传文件」的工具——它其实是一套内嵌在 App Store Connect 里的测试环境，自带审核门禁、自带必须填写的信息项、自带过期时钟。
本篇按 Apple 官方 App Store Connect 帮助文档的真实顺序展开：填写测试信息、上传构建版本并完成出口合规、邀请内部测试者、邀请外部测试者、通过审核、分发邀请、收集反馈，最后在 90 天到期之前主动结束测试，而不是等时钟替你结束。下文出现的每一个流程与每一个数字都来自 Apple 官方文档，并且尽量引用原文数值而非转述。
一、TestFlight 是什么，以及它不是什么
TestFlight 用来分发应用的 beta 构建版本、管理测试者并收集反馈。测试者先在自己的 iPhone、iPad、Mac、Apple TV、Apple Vision Pro 或 Apple Watch 上安装免费的 TestFlight App，接受邀请后即可收到你分配给其所在分组的构建版本。Apple 对目标的表述很直白：持续改进应用、持续分发构建版本，直到问题解决，然后再提交审核。
它不是把成品绕开 App Store 直接分发的通道。beta 构建版本同样受 App Review 指南约束，应用在分组里的第一个构建版本会被送审；一款只存在于 TestFlight 的应用，也不能当成长期分发渠道。不容易出错的心智模型是：TestFlight 是一间有门卫的排练厅，不是一扇侧门。
二、前置条件：账号、应用记录与构建版本
- 有效的 Apple Developer Program 会员资格。TestFlight 位于 App Store Connect 之内，账号状态必须正常、会员资格必须在有效期内。
- 拥有内容访问权限的 App Store Connect 成员。内部测试仅限拥有内容访问权限的成员，上限 100 人；通常就是日常在用的几个角色：Admin、App Manager、Developer、Marketing。
- 应用记录。没有应用记录的构建版本无法测试，请先在 App Store Connect 里创建应用。
- 可被 TestFlight 接受的构建版本。Apple 明确要求：构建版本的描述文件必须包含 application identifier。上传即失败的情况，通常出在签名或 Info.plist，而不是 TestFlight 本身。
- TestFlight for Mac 要求应用由 Xcode 13 或更高版本构建。
- 在保留域中创建的 Managed Apple 账号无法用于测试——别把这类企业邮箱加进测试分组。
三、第 1 步：填写测试信息（这是必填项，不是装饰）
在邀请任何人之前，App Store Connect 要求先补齐测试者与审核员都会读到的 beta 信息。
- Beta App Description：必填，一段对 beta 版本的简短说明。
- Feedback Email：必填。测试者可从这个邮箱直接联系你，它同时也是邀请邮件的回复地址。
- What to Test：测试者在构建版本上看到的说明。正是这一栏，把「请试用一下」变成可用的反馈。
- Invitation Experience：App Information 复选框默认勾选，也就是邀请页会自动展示最新「Ready for Distribution」版本里已审核通过的截图与应用分类；不想展示可以取消勾选。
测试信息随时可以修改，改动会同步显示在 TestFlight App 里。请在第一次外部审核之前认真填完——描述过于单薄，是少数几种「自己给自己添堵」的审核变慢原因。
四、第 2 步：上传构建版本并完成出口合规
把构建版本上传到 App Store Connect——Xcode、Transporter 或你的 CI 流水线——然后等它处理完成。上传与处理是两个不同状态，对着尚未处理完的构建版本发邀请，是发不出去的。
接着处理加密问题，这一步卡住的首次使用者比任何其他环节都多。Apple 会针对每个构建版本询问：应用是否使用加密、如何使用。官方给出的填写方式有三种：
- 在 TestFlight 分区里针对该构建版本点 Manage，逐条回答问题。
- 上传此前已获批的应用加密文档；或按 Go to App Encryption Page 拿到 Apple 给出的 key value 并填入 Xcode，此后这个应用不必再逐次回答。
- 在应用的
Info.plist中声明不使用加密、或属于免于提交文档的情形——Apple 提供这个设置的目的，正是免去每次提交都要回答。
构建版本长期停在「Waiting for Review」而迟迟没有审核员，很常见的原因是它在等出口合规。先看加密状态，再考虑开支持工单。
五、第 3 步：内部测试——最多 100 人、不经审核、几分钟即可开测
内部测试是整个发布链里最快的一环，也是唯一没有审核门禁的一环。
- 在 App Store Connect 打开应用，进入 TestFlight 分区。
- 在侧边栏 Internal Testing 下新建或选择分组。
- 添加最多 100 位内部测试者（拥有内容访问权限的成员），点 Add。
- 把构建版本分配给该分组。测试者会收到邀请邮件，在 TestFlight App 里接受，或用邮件中的兑换码接受。
Apple 关于时限的原文值得读两遍：内部测试者可以在 90 天内下载并测试所有构建版本。另外要注意「移除」的真实含义：把构建版本从分组中移除后，正在使用它的测试者仍可继续访问，直到他们切换构建版本或主动停止测试——移除并不等于吊销。
六、第 4 步：外部测试——最多 10,000 人，以及首个构建版本的审核
外部测试是 TestFlight 与 App Review 相遇的地方。每个应用最多可邀请 10,000 位外部测试者，可以来自组织之外。换来的是门槛：
- 当你把应用的第一个构建版本加入分组时，它会先被送交 App Review，确认符合 App Review 指南。
- 只有第一个构建版本必须完整审核，后续构建版本可能不需要完整审核。所以成熟的团队会把「某个版本的首个外部构建版本」当成里程碑，而不是走过场。
- 审核通过后测试才开始。随后在构建版本行点 Notify Testers，状态变为 Testing，测试者会收到通知去 TestFlight App 接受邀请。
- beta 构建版本被拒时，Apple 给出的官方途径是向 TestFlight App Review 申诉，而不是换一个开发者账号，也不是带着同样的问题重新上传。
外部审核比 App Store 审核轻，但它不是绕行通道：同一套指南依然适用，beta 也不是试探政策容忍度的地方。
七、第 5 步：邀请方式——邮件、兑换码与公开链接
测试者要先安装免费的 TestFlight App，然后才能接受邀请。
- 邮件邀请。被添加的测试者会收到含兑换码的邀请邮件；一直没有接受的人，可以在测试者列表里重发邀请。
- 公开链接。拿到链接的人无需邮件邀请即可加入分组，是把 beta 开放给社区的标准做法。Apple 提示：为公开链接设置具体条件会限制可参与测试的外部测试者数量；公开链接的测试者同样占用 10,000 人的上限。
- 精简构建版本。测试者下载的是按其设备精简后的变体，不等于你上传的通用版本。
两条实践原则：公开链接不要放在长期可见的位置（它是测试渠道，不是下载页）；邀请要与审核同步规划，指向未过审构建版本的链接等于没有链接。
八、第 6 步：反馈、指标与主动结束测试
- 反馈。iOS、macOS、visionOS 上使用 TestFlight 2.3 及以上的测试者，可直接在 TestFlight App 内提交反馈，或在 beta 应用里截图提交；反馈会汇总到 App Store Connect 的 TestFlight Feedback 分区。tvOS 或更早 iOS 版本的测试者，则只能发到你填写的 Feedback Email。
- 指标。App Store Connect 会给出每个构建版本的会话数与崩溃数，这是区分「没有人用」和「用了但崩了」的依据。
- 结束测试。测试完成后，可以主动 expire 该构建版本以停止测试。Apple 特别提示：如果没有 expire 就直接提交到 App Store，已受邀的测试者在应用上线后仍然可以继续测试。
九、90 天时钟：构建版本过期如何决定你的上传排期
每个 TestFlight 构建版本最多可测试 90 天，之后对测试者不再可用。就是这一个数字，决定了排期上的几个关键判断：
- 超过 90 天的 beta 计划，必须在旧构建版本消失前重新上传——要规划的是「上传动作」，不是「记得提醒自己」。
- 过期针对的是构建版本，不是测试者：只要分组里还有可用的构建版本，同一个测试者就能一直测下去。
- 主动 expire 也是干净收尾的方式：在 App Store 版本上线前，把测试通道切断。
实用规则：把第 75 天当成截止日。如果发布日期在它之后，就提前上传下一个 beta 构建版本——因为「测试者打开 TestFlight 看到一个已过期的构建版本」这种故障，只会在你最尴尬的时候才被发现。
十、beta 构建版本必须守的几条规则
TestFlight 是 Apple 生态内的测试环境，因此也按测试环境来管理：
- 指南适用于 beta。加入外部分组的第一个构建版本会按 App Review 指南审核；被拒就是真的被拒，也真的有申诉路径。
- 是测试，不是分发。用 TestFlight 把成品大规模发给 App Store 之外的受众，背离了审核的意义，也不属于该计划允许的用途。
- 你的账号、你的应用、你的构建版本。TestFlight 构建版本必须由拥有该应用的开发者账号签名并上传。借用他人的开发者账号、身份文件或签名材料来分发构建版本属于违规，会同时危及两个账号——这不是我们提供、也不会建议的做法。
- 保护测试者的数据。测试者是真实的人，不是流量：同样的隐私要求适用于 beta，反馈邮件里经常包含个人信息。
十一、KappS 在这里做什么
TestFlight 位于发布链的前端，正因为如此，这里任何一个本可避免的错误代价都不小：开发者账号、应用记录、签名材料、税务与银行资料、提交动作，必须一一对齐，构建版本才可能被测试，更不用说发布。KappS 帮助开发者在这条链上准备并提交合规材料：核对账号、应用与构建版本指向同一个真实发布者，在审核员或 90 天时钟发现之前，把不一致的地方修掉。
我们不做的是：用别人的账号杜撰一个测试通道，或用 TestFlight 绕过 App Review。一个 beta 计划的可信度，取决于它背后的账号，而那个账号必须是你自己的。
资料来源（Apple 官方文档）：App Store Connect 帮助 — TestFlight 概述；提供测试信息；添加内部测试者；邀请外部测试者；为 beta 构建版本提供出口合规信息；停止测试某个构建版本；App Review 指南。（developer.apple.com）