早先发 iOS 内测包，我一条路走到底用 TestFlight，直到有次给外部体验用户发包，对方问：能不能像安卓那样发个二维码扫码就装？注册 Apple ID、装 TestFlight 这套流程，对非开发背景的人来说确实长。顺着这个问题把 iOS 内测分发重新捋了一遍——从开发自测到外部公测，能用的做法不止一种，门槛和适用面差得也远。这篇按测试范围从小到大走一遍：开发阶段直连真机、小范围 Ad Hoc 扫码、系统性内测走 TestFlight、平台化与自建的补充。四条路的设备门槛、审核成本和维护量各不相同，先看每条"给谁装"，再看自己团队落在哪。
改完就上手机 开发阶段直连真机
分发的需求不只在发版本时出现——开发阶段每次改完想马上在真机上看效果，也算一类"分发"，只是收包的是自己。常规做法是 Xcode 连上设备跑，前提是有完整的 Xcode 环境。轻量路线走的是另一条：连上 iPhone，一键构建并安装到真机，不用导出 IPA、不用经过 TestFlight，改完即装，调 UI、试手感、验证证书配置都很顺。KXApp 这类工具的定位就在这一段——把"改一行、看一眼"的循环压到最短，代码改动同步到手机不用等完整编译链路走完。比起每次开 Xcode 的重环境，这条路对只想快速验证界面的人也友好得多。这类方式覆盖的是开发自己手上的设备，给别人装还得往下看。
给固定的一小撮人 Ad Hoc 扫码装机
产品、设计、测试组这十几号人，用 Ad Hoc 最直接：把设备 UDID 注册进开发者账号，打包时用包含这些 UDID 的描述文件签名，导出 IPA 后挂到能下载的地方，手机点 itms-services 链接就能装。要配的东西分两半：账号侧的注册设备和生成描述文件，分发侧的挂包和生成安装入口。
Ad Hoc 之所以要收 UDID、要重新签名，根子在 iOS 的安装校验：设备只接受描述文件里点过名的包。理解这一条，后面几条路的差别就好懂了——TestFlight 换了一套信任机制，自建分发绕不开描述文件，只有商店渠道的包才不需要点名。
两个数字要记牢：Ad Hoc 每年每种设备类型上限 100 台，满了之后删设备再加也有坑；描述文件里的设备列表一变，包要重新签名。打包这步用 KXApp 一键构建生成安装包，导出 IPA 后交给分发环节。国内团队常用蒲公英这类平台承担"挂包"那半——上传 IPA 生成二维码，带安装统计和版本管理；Diawi 是做类似事的海外选项。UDID 从哪收集？让测试者扫码上报，很多设备管理工具都带这功能，比手动查省事。对收包的人，体验就一句话：点开链接、装一个描述文件、点安装，包就进桌面了——不用账号、不用审核，这是 Ad Hoc 至今没被淘汰的原因。它的麻烦都留在发端：设备名单是静态的，新人加入要重新走一遍注册和重签流程，所以只适合固定的小圈子。
上量之后 TestFlight 的正规路线
测试面到几十上百人、还要持续迭代时，TestFlight 的优势出来了：包传到 App Store Connect，测试者装好 TestFlight 接受邀请就行，不用收 UDID、不用碰描述文件。内部测试成员最多 100 人，传完基本就能测；外部测试要过一道 Beta 审核，比正式上架宽松——主要看包能不能正常跑、描述信息是否齐全，被退多是元数据不完整，补上重新提就行——通过后最多能加到 1 万人。外部测试者按邮箱邀请、分组管理，可以给不同组推不同构建，不过组一多，邀请收发和反馈收集也要有人盯，别把它当缺陷管理系统用。测试版本 90 天有效，到期传新版本即可。上传环节用 Xcode 自带工具或第三方上传工具都行，传完不是立刻可用，服务端要处理一会（几分钟到几十分钟都有，包越大越慢），处理完才会出现在测试列表里。
前面那个"太麻烦"的抱怨，多半来自外部测试者这一端——注册 Apple ID、装 TestFlight、接受邀请，链路比安卓点个 APK 长。换来的是这类包不用管设备证书、不用重新签名，迭代几个版本后会发现整体更省事。
平台化与自建 已有基建的两种延伸
团队已经用 Firebase 做统计推送的话，Firebase App Distribution 能把测试分发顺手接进来：上传 IPA、邀请测试者邮箱、通过 App Tester 收更新，流程和蒲公英同类，选哪个看现有基建——已经在用 Firebase 的团队，测试者名单能和其他 Firebase 服务打通，少维护一套系统。更极客的玩法是自建：服务器挂 IPA 和 manifest.plist，生成 itms-services 链接，配好 HTTPS 就能在团队内分发。走公网的话，manifest.plist 和 IPA 的地址都必须是 HTTPS，自签证书手机不认，这是第一道门槛；之后证书、域名、描述文件过期的运维也得自己扛，人手不足的团队慎重。
这两条路适合的时机：TestFlight 的审核节奏卡住高频迭代（一天几个包那种），或者外部测试者根本不方便注册 Apple ID。
四条路的分界不在工具，在"给谁装"：开发期改完自己看，直连真机最快；固定的几十个设备，Ad Hoc 扫码；上百人持续迭代，TestFlight；已有基建或要绕审核节奏，平台和自建各取所需。
顺带一提，这几条路并不互斥——同一个项目里，开发期连真机、小范围发 Ad Hoc 给产品组、上量后切 TestFlight，叠着用是常态。真要给个起点：先想清楚收包的人是谁、有多少、迭代多快，路径自己就浮出来了，不用一开始全铺开。
