先确认 Ad Hoc 适合的是已知设备测试
Ad Hoc 分发的核心不是生成一个可以随意转发的 IPA，而是把 App 交付给开发者账户中已经登记、并且被选入描述文件的具体设备。Apple 的设备概览说明，注册设备后可以通过 Ad Hoc 分发把 App 直接安装到设备。若测试对象持续变化、无法提前收集设备 ID，或人数接近设备额度，先比较 TestFlight 等其他官方路径通常更合适。
开始前建议列出测试目的、设备产品系列、设备名称、设备 ID、使用人、预计结束时间和数据处理要求。设备 ID 属于需要谨慎传递的设备标识，不应通过公开表单无范围收集。清单还应标注哪个 App、哪个 bundle ID 和哪个会员团队负责此次分发，避免设备被注册到错误团队后继续消耗名额。
- 只为明确的开发或测试任务注册设备，并记录设备归属和使用期限。
- 设备持续变化或测试规模较大时，先评估 TestFlight 是否更合适。
准确理解每产品系列每会员年度 100 台
Apple 当前帮助页列出的规则是：Apple Developer Program 与 Apple Developer Enterprise Program 成员，每个会员年度可以按产品系列分别注册最多 100 台设备。产品系列包括 Apple TV、Apple Vision Pro、Apple Watch、iPad、iPhone、iPod touch 和 Mac。也就是说，100 台是每个产品系列各自计算，不是所有类型合并共用一个 100 台池。
额度按会员年度管理，也不等同于自然年 1 月 1 日自动刷新。团队应记录会员年度起止时间，并在批量导入前查看当前已注册和剩余数量。对于只用一次的演示机，也应评估是否值得占用当年名额。把额度表按产品系列分列，可以防止看到 iPhone 还有名额，就误以为 iPad 或 Mac 也一定有相同余量。
- 按 iPhone、iPad、Mac 等产品系列分别统计已用和剩余数量。
- 额度周期跟随会员年度，不要按自然年自行推算刷新日期。
停用设备不会立即返还当年名额
Apple 明确说明，会员年度内可以停用设备，但停用不会增加可用设备数量。因此，发现设备已丢失、离职人员归还或测试任务结束后，可以根据管理需要将设备停用，却不能把这一步理解为立即腾出一个新名额。若团队已经接近某产品系列的 100 台上限，临时停用旧设备并不能解决新增注册需求。
新会员年度开始时，Account Holder、Admin 和 App Manager 首次进入 Certificates, Identifiers & Profiles，会看到设备清理选项。可以移除指定设备、移除全部设备并把每个产品系列的可用数量恢复到 100，或选择继续保留。执行前应导出或核对设备清单，确认仍在进行的测试不会因清理而失去后续描述文件配置依据。
- 停用用于停止当前设备参与，但不会回收本会员年度的注册名额。
- 会员年度切换时先核对在用设备，再决定保留或移除。
手动注册 UDID 前的采集与复核
Apple 的单设备注册说明要求准备设备名称和设备 ID。对 iPhone、iPad 等设备，团队通常把需要填入开发者账户的标识称为 UDID。采集后应让设备使用人和操作人各核对一次，避免把序列号、IMEI 或复制不完整的字符串误当成 UDID。设备名称也应包含可追踪信息，例如项目简称、使用人或资产编号，而不是大量重复的“iPhone”。
手动操作入口位于 Certificates, Identifiers & Profiles 的 Devices 页面，依次选择平台、填写名称与 UDID、继续并复核，最后注册。Apple 页面列出的必需角色为 Account Holder 或 Admin。若使用自动签名，Xcode 可以注册已连接设备；无论采用哪种方式，都建议在注册后回到设备列表确认平台、名称和状态。
- 采集设备名称和正确的设备 ID，并由两人或两次操作复核。
- 注册完成后检查平台与状态，保留操作人和日期记录。
准备 App ID、分发证书与目标设备
Apple 的 Ad Hoc 描述文件创建页把前置材料写得很清楚：需要一个 App ID、一个分发证书和多个已注册设备。App ID 应与要导出的 App 的 bundle ID 匹配；分发证书必须是团队准备使用的有效证书；设备则从开发者账户已经注册的列表中选择。任何一项选错，都可能让导出的包无法在目标设备上按预期安装。
操作前可以把三项信息放在同一张检查表：App 名称与 bundle ID、证书名称与到期信息、设备名称与 UDID。若团队同时维护生产和测试 App，尤其要防止选择相似但不相同的 App ID。若 Xcode 开发阶段使用自动签名，页面可能出现 Xcode 管理的显式 App ID 或 XC Wildcard，选择时仍应依据 Apple 页面说明和实际 bundle ID 核对。
- App ID 必须与目标 App 的 bundle ID 对应。
- 在生成前复核分发证书和本次真正需要的设备名单。
按顺序生成并下载 Ad Hoc 描述文件
手动创建时，在 Profiles 页面点击新增，在 Distribution 下选择 Ad Hoc，然后选择匹配 bundle ID 的 App ID。下一步选择本次使用的分发证书，再选择允许参与测试的已注册设备。设备列表不是越多越好：只勾选当前交付确实需要的设备，有助于后续理解某个包面向哪一批测试者。
选择完成后，为描述文件使用可识别名称，例如包含 App、环境和日期，再点击 Generate 并下载。下载文件应进入受控的签名和归档流程，不建议散落在个人聊天或公共网盘。若采用 Xcode 自动签名，Xcode 会管理 Ad Hoc provisioning profiles；采用手动签名时，则应确认构建实际嵌入的是刚生成的正确描述文件。
- 顺序为 Ad Hoc、App ID、分发证书、设备、名称、Generate、Download。
- 描述文件名称应能区分 App、环境和设备批次。
新增或更换设备后的更新策略
新设备完成注册后，它不会自动出现在已经签入旧包的设备范围里。若要让新设备参与这批 Ad Hoc 测试，需要让当前描述文件包含该设备，并使用相应配置重新完成分发构建。实际操作可以由 Xcode 自动签名管理，也可以在开发者账户中编辑或重新生成描述文件；无论选择哪条路径，都应把设备清单与最终构建对应起来。
设备被停用、证书更换或 App ID 能力调整时，同样需要重新核对描述文件。不要只根据文件名判断内容，最好记录生成时间、证书、App ID 和所选设备批次。交付新包时明确说明旧包是否继续使用、哪些设备新增，以及测试者需要删除旧版本还是覆盖安装，具体安装行为应以当前构建和设备实际提示为准。
- 新增设备后更新描述文件范围，并重新生成对应的分发构建。
- 证书或 App ID 配置变化时，也要重新核对描述文件。
交付前的 Ad Hoc 最终检查清单
交付前逐项确认：所选团队正确；会员资格有效；目标产品系列仍有设备名额；设备名称与 UDID 已复核并处于可用状态；App ID 匹配 bundle ID；分发证书选择正确；描述文件包含本批设备；构建采用预期的签名配置。然后保留构建号、描述文件名称、生成日期和设备批次记录。
Ad Hoc 适合开发者自有 App 在已知注册设备上的测试，不应被描述成不限设备的公开安装方式。若需求变成大规模外部 Beta 测试，应重新评估 TestFlight；若面向正式用户发布，则应选择与业务场景相符的 Apple 官方分发方式。Apple 的账户页面和规则可能调整，执行前应打开本文列出的官方来源再核对一次。
- 把团队、额度、UDID、App ID、证书、描述文件和构建号放入同一交接记录。
- 测试规模或对象改变时，重新评估官方分发路径，不延用不合适的 Ad Hoc 方案。