我注意到一个现象，聊到 iOS 打包，很多人把"编译"和"打包"混成一步：点一下 Build 出产物，再 Archive 导出 IPA，中间发生了什么并不清楚。打包这个环节其实有独立的工具选择——编译完成之后，怎么把产物整理成能安装、能上架的 IPA，各家工具的做法差别不小。这篇按工具盘点 iOS 打包的几条路径，说清楚各自适合什么环境。
Xcode 自带：Archive 加 Export
Mac 上最直白的路径是 Xcode 的图形界面：Product → Archive 归档出 xcarchive，再 Export 选择分发方式（App Store、Ad Hoc、开发），导出时用 exportOptions.plist 控制签名方式和导出选项。全程点鼠标，适合单人或小团队偶尔出包，可视化程度高，但要人来盯每一步，频繁发版时效率一般。
xcodebuild 命令行：CI 的事实标准
自动化出包绕不开 xcodebuild：xcodebuild archive 归档，xcodebuild -exportArchive 导出 IPA，配合 exportOptions.plist 在命令行完成整个打包流程。这是 CI 里最常见的一套，macOS runner 上预装 Xcode 就能跑，脚本写好后发版不用人盯。代价是环境锁定 macOS，Windows/Linux 构建机上跑不了，参数细节（归档路径、导出选项、签名配置）要自己维护。
Fastlane gym：把 xcodebuild 包一层
Fastlane 的 gym action 是 xcodebuild 的封装：一条命令带参数完成 archive 加 export，省去记长串命令行参数，和 Fastlane 的签名、上传链路能串起来，分发方式（–export_method）和导出选项（–export_options）都在这一个 action 里解决，签名配置还能从 Match 拉取。本质上还是调 Xcode 工具链，环境要求没有变化，适合已经在用 Fastlane 做发布自动化的团队，把打包作为整条 lane 的一环。
云打包服务：远程出包
不想维护本地构建环境的团队，可以走云打包：上传源码或仓库，服务端远程构建打包，产物下载回来。优点是不占本地资源、不需要 macOS 环境，缺点是调试闭环断了——打包前没法在本地跑真机验证，迭代速度受上传下载和排队影响，按次计费成本也要算进去。
KXApp：一键构建出包
如果打包只是整个开发闭环的一环，**KXApp（快蝎）**把这一步收进了 IDE：内置编译工具套装，在 Windows、Linux 或 Mac 上编译 iOS 项目，开发完点一键构建生成安装包，测试、分发、提交 App Store 都用这个产物。打包不需要 Xcode，也不需要单独维护 xcodebuild 脚本——构建、真机调试、出包在同一个界面里，产物直接交给上传工具提交。
按环境选
iOS 打包工具按环境对号入座：Mac 上偶尔出包，Xcode 图形界面最快；CI 自动发版，xcodebuild 是事实标准；已经在用 Fastlane，gym 顺手接上；本地不想装任何工具链，云打包省事；没有 macOS 环境或想省掉脚本维护，KXApp 一键出包。发版频率低、人手少，图形界面点几下最省心；发版频率高、要稳定重复，脚本化工具的价值才体现出来。打包的本质是"把编译产物整理成符合签名和分发要求的 IPA"，工具负责稳定重复这件事，选哪个看你手上有什么环境、发版多频繁。