在持续集成里用 fastlane 的人，大多都有类似体验：
gym、match、build_app 一路绿灯，IPA 也顺利生成，但真正要把包送进 App Store Connect 时，问题就出现了。

  • CI 环境不在 macOS
  • altool / iTMSTransporter 在新版本中频繁变动
  • 网络问题导致上传不稳定
  • Apple 账号验证失败但信息不直观

这时候，构建流程已经自动化，上传流程却并不工程化。

为什么我没有把上传完全交给 fastlane

fastlane 本身当然可以上传，upload_to_app_store 也足够成熟。
但在一些团队环境里，它并不是最合适的选择：

  • Windows CI 节点无法直接运行
  • 账号需要多人共用，不适合直接暴露在 CI 配置中
  • 网络环境复杂，失败后重试成本高

所以我通常把流程拆成两段：

  • fastlane 负责 构建与签名
  • 专用工具负责 上传与提交

fastlane 输出 IPA，本身就已经很“干净”

在 fastlane 中，我一般只做这些事情：

  • 使用 match 或本地证书完成签名
  • 通过 gym 或 build_app 生成 IPA
  • 将 IPA 输出到固定目录

这一步结束后，IPA 已经满足所有上架条件。
它并不依赖 fastlane 继续“陪跑”。

AppUploader 命令行在这里承担了什么角色

在上传这一段，我更倾向于使用 AppUploader 命令行，原因很简单：

  • 不依赖 Xcode
  • 可在 Windows / Linux / macOS 上运行
  • 上传逻辑相对独立，失败信息更集中

在流程上，它并不参与构建，只做一件事：把一个已经准备好的 IPA，稳定地提交给 Apple。
上传流程：
在windows，linux和mac上使用命令行方式上传发布ipa到appstore的命令如下
appuploader_cli -f <ipa_file> -u -p -c
例子
appuploader_cli -u abc@icloud.com -p xxxx-xxxx-xxxx-xxxx -c 2 -f mygame.ipa

-u 指定apple开发者账号
-p 指定上传专用密码
-c 上传使用的通道，支持1和2
-f 指定要上传的ipa文件路径

appuploader目前支持通道的值 1表示是老通道，老通道稳定，2表示是新通道，新通道方便高效

appuploader_cli 在下载的appuploader压缩包内，mac版本的是在.app内的runtime目录下

一个实际可落地的组合方式

在 CI 或本地脚本中，我通常这样组织流程：

  1. fastlane 负责生成 IPA
  2. 将 IPA 放到共享目录或产物目录
  3. 调用 AppUploader 命令行进行上传

这样一来，构建失败和上传失败被明确区分，不会互相干扰。

使用 AppUploader 命令行前的几个准备点

在真正执行上传前，我一般会确认：

  • Apple 开发者账号为已付费账号
  • App Store Connect 中已有对应 App
  • 已生成并配置 App 专用密码

这些条件不满足，命令行工具会明确返回错误，而不是“卡住”。

上传过程中的一些工程细节

在实践中，我更关注这些点：

  • 上传通道是否可切换
  • 网络异常时是否支持重试
  • 错误是否能快速定位到账号、IPA 或网络

相比直接用 fastlane 上传，AppUploader 命令行更像一个上传专用模块，而不是 CI 的一部分。

当上传失败时，我是如何处理的

如果 AppUploader 返回失败，我一般不会立刻回到 fastlane：

  • 构建已完成，问题不在代码
  • 先检查账号权限与专用密码
  • 再尝试切换上传通道
  • 最后才考虑重新构建 IPA

这种分层排查方式，在多人协作中尤其重要。

在实际项目里，我更愿意看到这样的分工：

  • fastlane：构建、签名、版本控制
  • AppUploader：上传、提交、网络适配
  • CI 系统：流程编排与触发

每个工具只做自己擅长的部分，整体反而更稳定。