如果把 iOS 上架流程放在几年前来看，大多数团队的方法比较固定：
- Mac + Xcode 打包
- Xcode 或 Transporter 上传
- App Store Connect 提交
但在最近两年，工具开始出现明显变化，不是某个工具更好用了，而是整个过程可以被分开了，这篇文章讲解说明 2026 年更常见的一种模块化上架方式。
把上架流程拆成四个模块
在项目进入发布阶段，可以把流程拆成四段：
| 模块 | 产出 |
|---|---|
| 签名准备 | p12 + mobileprovision |
| 构建阶段 | ipa |
| 上传阶段 | 构建记录 |
| 审核阶段 | 上架版本 |
每一段都可以独立完成，并且可以使用不同工具，这种拆分方式，是当前很多团队在做的事情。
签名不再依赖本地环境
一个明显变化是：证书和描述文件不再绑定某一台 Mac。
在较早的流程中：
- 证书在钥匙串
- 描述文件在本地
- 换电脑需要重新配置
现在更常见的做法是：
- 统一生成
.p12 - 统一生成
.mobileprovision - 存储到团队共享环境
例如使用 AppUploader（开心上架）：
- 登录 Apple 开发者账号
- 进入证书管理
- 创建 distribution 证书
- 下载
.p12
然后：
- 进入描述文件管理
- 创建 App Store 类型描述文件
- 绑定 Bundle ID 和证书
- 下载
.mobileprovision
这两个文件成为标准输入，后续流程不再依赖设备。
构建从本地操作转向可替换执行
构建 IPA 的方式正在变得灵活。
可以选择：
- Xcode 本地 Archive
- Fastlane 自动构建
- 云打包服务
例如 Fastlane：
lane :release do
build_app(
scheme: "AppScheme",
export_method: "app-store"
)
end
构建的本质是：
输入：代码 + 证书 + 描述文件 输出：IPA
构建在哪执行，不再是关键问题。
上传工具开始“去平台化”
上传 IPA 这一环节变化更明显。
过去依赖：
- Xcode Organizer
- macOS Transporter
现在可以选择：
- 命令行工具
- 跨平台上传工具
- CI 自动上传
例如在 Windows 或 Linux 上，可以直接使用：
appuploader_cli -f app.ipa -u appleid@example.com -p xxxx-xxxx-xxxx-xxxx -c 2
或者使用图形界面工具完成上传。
在 AppUploader（开心上架） 中：
- 打开提交上传页面
- 输入 Apple ID
- 设置专用密码
- 选择 IPA
- 切换上传通道
- 执行上传
上传完成后，构建会进入 App Store Connect。
审核阶段变化不大，但输入更规范
审核流程本身变化不大，但输入信息变得更严格：
- 隐私政策
- 权限说明
- 测试账号
这些信息需要在 App Store Connect 中填写。
流程仍然是：
My Apps → 选择应用 → 选择构建 → 提交审核
实际开发中的一个例子
一个团队的实际流程：
- 前端使用 uni-app 开发
- CI 在 Linux 上运行
- 构建在 Mac Runner
- 上传在 Windows
流程如下：
- AppUploader 生成证书和描述文件
- CI 下载证书
- Mac Runner 构建 IPA
- 上传到 Linux
- 使用命令行上传
- App Store Connect 提交审核
这个流程中，没有一步是强制绑定设备的。
2026 年 iOS 上架的变化，并不是工具升级，而是流程解耦。
