在我们团队的日常开发中，TestFlight（TF） 是必不可少的工具。它帮助我们在正式发布前，把应用分发给测试人员，收集反馈并优化体验。
不过，我们的团队开发环境很“混搭”：
- 绝大多数人用 Windows 写 Flutter 和前端；
- 只有一台放在机房的 Mac Mini 专门用来打包 iOS；
- 团队分布在不同城市。
因此，如何在这样的条件下快速完成 TF 上架，就成了一个值得优化的流程。下面是我们一次完整的 TF 上架过程记录。
一、准备阶段：搞定证书和描述文件
以前，申请 iOS 发布证书对我们来说很麻烦：
要用 Mac 的 Keychain 生成 CSR，再去 Apple Developer 网站操作，最后还得导出 .p12 文件。
这次我们直接在 Windows 上用 Appuploader 完成了所有证书申请：
- 打开 Appuploader，登录 Apple ID；
- 选择生成 iOS Distribution 证书；
- 自动导出
.p12文件和.mobileprovision描述文件； - 命名成
ProjectName_Distribute_2025.p12，存入公司共享盘。
这样一来，证书和描述文件在团队内任何电脑都能使用，免去了之前反复导入导出的麻烦。
二、构建签名 IPA：Mac 出场
构建 IPA 仍然是 Mac 的专属任务。 我们用的方案是远程连接机房的 Mac Mini，专门用来跑构建命令：
flutter clean
flutter build ios --release
xcodebuild -workspace Runner.xcworkspace \
-scheme Runner archive \
-archivePath build/Runner_v1.xcarchive
xcodebuild -exportArchive \
-archivePath build/Runner_v1.xcarchive \
-exportOptionsPlist ExportOptions.plist \
-exportPath build/ipa
构建出来的 app_v1.0.ipa 会自动上传到共享盘，方便 Windows 同事直接拿来上传。
三、上传到 TestFlight：回到 Windows
上传是我们优化的重点，因为以前要在 Mac 上用 Xcode 或 Transporter 来做，操作复杂且依赖性强。
现在我们在 Windows 上用 Appuploader：
- 选择刚刚构建好的 IPA；
- 目标平台选 TestFlight；
- 点击上传，几分钟后版本就会出现在 App Store Connect 的 TF 页面。
这样即使构建人员不在，也能让其他人替他完成上传，极大提升了协作灵活度。
四、配置测试与分发
IPA 上传完成后，需要在 App Store Connect 中设置测试信息：
- 版本更新说明（Beta Notes）
- 测试人员（内部测试 / 外部测试）
- 自动分发开关
我们的习惯是先做 内部测试，因为不需要苹果审核，安装速度快；等稳定后再开放外部测试，让更多人参与。
五、快速收集反馈
TestFlight 内置了反馈通道，测试人员可以直接提交截图和文字描述。但我们还结合了企业内部的 IM 群：
- 发现问题的测试人员会在群里发截图和重现步骤；
- QA 整理问题清单；
- 开发在下个构建中修复。
这种方式保证了反馈在 1 天内就能被处理，迭代效率很高。
六、团队分工模式
在这次 TF 上架中，我们的分工是这样的：
| 流程环节 | 工具 | 执行人 | 平台 |
|---|---|---|---|
| 证书申请 | Appuploader | 运维 / 开发 | Windows |
| 构建 IPA | Xcode + Flutter | 构建负责人 | macOS |
| 上传 IPA | Appuploader | QA / 产品助理 | Windows |
| 测试配置 | App Store Connect | 产品经理 | 浏览器 |
| 反馈收集 | TestFlight + IM | QA / 测试用户 | iOS 设备 |
经验总结
- Mac 只用在构建阶段，占用时间很少；
- 证书和描述文件跨平台共享，免去了反复导入导出的麻烦；
- 上传任务分离，不再依赖构建人员，有人空闲就能上传；
- 内部测试优先，快速验证版本稳定性；
- 反馈通道多元化，保证问题第一时间传达给开发。
