外包项目做完，甲方要验收，但正式上架还有一轮审核和资料准备。这个空档期最现实的做法就是用签名把包发出去，让甲方在真机上点一遍。这件事本身不复杂，复杂的是没提前说清楚带来的扯皮。
验收期三条路的取舍
- TestFlight（苹果官方测试分发渠道）：最正规，体验最接近正式版，但甲方要装 TestFlight 应用、要被加进测试组，还有 90 天有效期，且需要甲方提供苹果账号邮箱。
- 超级签名：按 UDID（设备唯一识别码）绑定设备，甲方把参与验收的几台设备 UDID 报过来即可，装完点信任就能用。适合三五个人的验收小组。
- 企业签名：不限制设备数，发个链接就能装，适合甲方要拉一批人集体试用的场景。
人少、设备固定，用超级签；人多、要快速铺开，用企业签；要走正式流程、对稳定性要求高，用 TestFlight。
四件事必须提前写进沟通记录
第一件：有效期到哪天。签名都有时间边界，验收拖超时导致包失效，是最高频的纠纷点。建议在验收开始时就把截止日期写清楚，并预留续期方案。
第二件：验收用的是哪个版本。验收期改 bug 会出新包，新旧包签名来源可能不同，甲方装的是哪一版必须可追溯。做法是在 App 内加一个可见的版本号和构建号，验收记录里写明「几点几分测的是哪一版」。
第三件：设备名单谁维护。走超级签需要 UDID 名单，中途加人要重新加设备并重新签名，这个周期要算进排期。
第四件：验收结束后怎么切。正式上架后，验收用的签名包要不要下线、用户要不要迁移到正式版，都要提前定。常见做法是保留签名包一个过渡期，在 App 内提示用户迁移。
两个容易被忽略的风险
一是包外流。验收期的包功能完整，链接一旦扩散出去就收不回。控制办法是分发链接设访问限制、加有效期，并在包里带上能识别来源的渠道标识，万一外流能追到是哪一环出去的。
二是验收环境不等于生产环境。签名包通常落在开发或企业环境，推送、支付这类依赖环境的模块表现可能和正式版不同。涉及这类功能的验收，要么单独说明，要么直接走 TestFlight，别在签名包上得出「功能有问题」的结论。
交付清单
建议每次交付附带一份简短说明：母包版本号与构建号、本次变更点、签名类型与有效期、参与验收的设备名单、安装与信任的操作步骤、联系人。这份说明花不了十分钟，能把后续八成的沟通成本省掉。
小结
验收期用签名分发是标准操作，问题从来不在技术，而在时限和版本没说清楚。把有效期、版本、名单、切换路径这四件写下来，验收就顺了。
我是本期作者小思，想解决苹果企业签名、超级签名、TF签名问题？可以在微信公众号对话框找到我哦~（QQ：822404920 微信：A-mk5888）
