判断你的 App 是否适合走 App Store Connect 转移流程
在启动任何技术交接之前，首要任务是确认业务与账户状态是否满足 Apple 官方的转移条件。App Store Connect 的 App 转移流程具有严格的权限要求，必须由转出方的 Account Holder 发起，并由接收方的 Account Holder 接受。这意味着双方账户必须处于正常活跃状态，且具备相应的开发者计划资格。如果接收方账户缺乏对应的计划类型（例如从个人计划转移到组织计划时的资格差异），转移请求将无法完成。
此外，需要明确转移带来的数据继承范围。官方文档指出，转移将保留 App 的 Bundle ID、用户评论和评分，且现有用户在转移后仍可继续接收更新。这一特性使得转移成为维护用户资产的合适路径。然而，在发起转移前，必须检查是否存在未处理的 Xcode Cloud 数据或正在进行的审核流程。若有未结清的构建任务或审核中的版本，建议先处理完毕，以避免转移过程中出现状态冲突或数据丢失风险。若接收方账户不具备对应计划资格，或 App 存在未结清状态，则不应贸然发起转移。
- 核对转出方与接收方是否均为 Account Holder，且双方账户处于正常状态。
- 确认 App 的 Bundle ID、评论与评分将被保留，且用户可继续接收更新。
- 检查是否存在未处理的 Xcode Cloud 数据或进行中的审核。
转移前备份：App 信息、签名身份与描述文件的留存范围
转移过程主要迁移的是 App Store Connect 中的元数据和所有权关系，而非开发环境中的本地配置。因此，转出方团队必须在转移前独立完成关键资产的备份。首先，应在 App Store Connect 中导出或详细记录 App 的元数据、定价策略、可用地区设置以及历史审核备注。这些信息虽然部分会随 App 转移，但本地备份可作为后续核对的基准，防止因界面显示延迟或配置差异导致的运营失误。
更为关键的是签名身份的备份。Apple 明确指出，只有证书而没有对应私钥时，无法使用该证书进行签名。如果团队使用的是本地手动管理的签名证书，必须从 Xcode 中将完整的签名身份导出为密码保护的 PKCS#12 文件，并由授权成员妥善保管。同时，需核对当前的描述文件、App ID 所启用的能力（如 Push Notifications、App Groups）以及已注册的测试设备清单。这些配置在转移后不会自动同步到接收方的开发者账户中，接收方需要在自己的环境中重新创建匹配的 App ID 和描述文件。若未备份签名身份，转移后将无法继续构建新版本，导致维护中断。
- 在 App Store Connect 中导出或记录 App 元数据、定价、可用地区与审核备注。
- 确认本地签名身份是否已导出为密码保护的 PKCS#12 文件，并由授权成员保管。
- 核对描述文件、App ID 能力与已注册设备清单是否需要在新团队中重建。
TestFlight 停止测试：转移前必须完成的 Beta 收尾
Apple 的 App 转移说明中有一项强制性要求：在转移发起前，必须停止所有相关的 TestFlight Beta 测试。这是因为 TestFlight 的测试构建与特定的开发者账户和签名证书绑定。如果转移时仍有活跃的测试组或未过期的构建版本，接收方将无法立即接管新的测试构建，甚至可能导致测试员端出现安装失败或版本冲突。TestFlight 构建版本的最长测试期为 90 天，支持最多 10,000 名外部测试员和 100 名内部测试员，因此在大型项目中，停止测试的影响范围可能较广，需提前通知测试参与者。
除了停止测试，还需处理 Xcode Cloud 的相关数据。如果项目使用了 Xcode Cloud 进行持续集成，需确保在转移前完成当前工作流的归档或清理。建议在停止测试前，记录最后几个稳定版本的测试员反馈与崩溃日志，并将其作为基线数据移交给接收方。这有助于接收方在接管后快速定位潜在问题，保持测试质量的连续性。未在转移前停止 TestFlight 测试，是导致接收方无法顺利接管新构建的常见原因之一。
- 确认所有外部测试（最多 10,000 名）与内部测试（最多 100 名）的构建已停止。
- 核对 TestFlight 构建版本 90 天有效期与转移时间窗的关系。
- 记录测试员反馈与崩溃日志，作为接收方后续测试的基线。
签名凭据交接：本地证书与云管理证书的不同路径
签名凭据的交接方式取决于团队使用的是本地手动管理的证书还是 Apple 的云管理证书。对于使用本地证书的团队，安全性是交接过程中的核心考量。Apple 提醒，持有导出签名身份及密码的人可以该开发者账户名义签署软件，因此必须采取严格的安全措施。应将 PKCS#12 文件设置为强密码，并通过不同的渠道分别传递文件和密码给接收方的授权成员。例如，通过加密邮件发送文件，通过即时通讯工具发送密码，并务必核实接收人的身份。
若团队使用的是云管理证书，交接过程则大大简化。Apple 的云管理证书与开发者计划会员关联并由远端管理，在 Xcode 13 或更高版本的 Organizer 归档分发流程中，若找不到本地签名证书，系统会自动使用云签名。这意味着接收方无需下载或共享云证书的私钥，只需在 App Store Connect 中被添加为相应角色的成员，即可在 Xcode 中直接使用云签名进行归档。此外，还需核对 Automatic Signing Controls 设置，确认是否对 Developer 角色施加了注册新 App ID 或测试设备的限制，这些选项默认关闭，但可能在某些严格管理的团队中被启用。
- 若使用本地证书，确认 PKCS#12 导出文件与强密码通过不同渠道传递。
- 若使用云管理证书，确认无需下载私钥，接收方在 Xcode 13+ Organizer 中直接使用云签名。
- 核对 Automatic Signing Controls 是否对 Developer 角色施加了注册 App ID 或设备的限制。
钥匙串共享的边界：转移后登录态能保留多久
许多开发者误以为 App 转移后，用户的登录状态会通过钥匙串共享永久保留。然而，Apple 的官方说明明确指出，钥匙串共享在转移后仅持续到 App 的下一次更新。当用户使用接收方新签名的版本更新 App 时，由于签名身份发生变化，系统将不再允许访问原签名创建的钥匙串数据。此时，App 必须切换到接收方的钥匙串组，这通常意味着用户需要重新登录。
因此，在转移规划中，必须评估用户重新登录的成本和影响。对于拥有大量活跃用户的应用，建议在转移前的最后一个版本中，通过应用内公告或推送通知，提前告知用户在下一次更新后可能需要重新登录。同时，技术团队需核对是否使用了 Keychain Access Groups，并在接收方的新签名配置下重新规划钥匙串组的命名和访问权限。若误以为钥匙串共享会长期有效，而未做重新登录的引导设计，将导致用户在更新后遭遇数据丢失或无法使用的严重体验问题。
- 确认钥匙串共享仅在 App 更新前有效，更新时必须切换到接收方的钥匙串组。
- 评估用户量与重新登录的成本，准备应用内提示或公告。
- 核对是否使用了 Keychain Access Groups 并在接收方新签名下重新配置。
接收方接管：新签名、新描述文件与首次更新的核对
当接收方完成转移接受后，技术工作的重心转向确保首次更新的顺利发布。接收方团队首先需确认已在 Xcode 中正确导入转交过来的签名身份，或确认云管理证书权限已生效并完成归档。接着，必须创建新的描述文件，确保其匹配的 App ID 与所需的能力（如 iCloud、Push Notifications）与原 App 一致。任何能力的缺失都可能导致 App 在运行时出现功能异常。
在正式提交 App Store 审核之前，强烈建议在 TestFlight 或 Ad Hoc 环境中先验证一次完整的更新流程。Ad Hoc 描述文件需要匹配的 App ID、分发证书和已注册设备，通过这种方式可以模拟真实用户的更新场景，检查是否存在签名不匹配或安装失败的问题。若接收方未正确配置签名或描述文件，首次更新可能被系统拒绝，或者更糟糕地，导致用户端数据异常。只有在内部测试确认无误后，方可提交新版本至 App Store，完成所有权的最终技术交接。
- 确认接收方已在 Xcode 中导入签名身份或使用云管理证书完成归档。
- 核对新描述文件是否匹配当前 App ID 与所需能力。
- 在 TestFlight 或 Ad Hoc 环境先验证一次更新流程，再提交 App Store。
企业 App 与自定 App 的转移差异：MDM 信任与审核边界
对于非公开分发的 App，转移后的信任机制有所不同。Apple Developer Enterprise Program 仅用于符合条件组织的内部专有 App 私下员工分发，严禁对外公开分发。如果企业 App 是通过 MDM（移动设备管理）方案分发的，MDM 安装会自动建立信任，用户无需手动信任开发者证书。然而，如果是手动安装的企业 App，用户需要在“通用”>“VPN 与设备管理”中手动建立信任。
在此过程中，设备需要联网验证开发者证书，且之后会定期重新验证。如果显示“Not Verified”，用户需联网后点击“Verify App”，且防火墙需允许连接 ppq.apple.com。对于自定 App（Custom Apps），虽然面向指定组织分发且通过直接链接访问，但仍需通过 App Store 的审核流程。在转移这类 App 时，需评估是否需要重新配置联网验证策略，并确保接收方理解企业计划的内部使用边界，避免因误用企业证书转移公开 App 而违反计划条款。
- 确认企业 App 是否通过 MDM 分发，MDM 安装会自动建立信任，无需用户手动信任。
- 核对自定 App 是否仍需通过 App 审核，且通过直接链接访问。
- 评估转移后是否需要重新配置 ppq.apple.com 的联网验证。
转移交接清单：从备份到首次更新的完整核对
为了确保 App Store 应用转移过程的万无一失，建议团队使用以下清单串联转移前、转移中与转移后的所有关键动作。这份清单涵盖了从数据备份到用户沟通的全流程，旨在消除因遗漏步骤导致的运营风险。每一项检查点都对应着官方文档中的具体要求或常见的技术陷阱，执行时应逐项勾选确认。
跳过任一环节都可能导致用户端异常或接收方无法继续维护。特别是在签名凭据保护和钥匙串登录态过渡这两个高风险领域，务必保持高度的警惕和细致的沟通。通过标准化的交接流程，不仅可以降低技术故障率，还能提升团队协作的专业度，确保 App 在所有权变更后依然能为用户提供稳定、安全的服务。
- 转移前：备份 App 信息、导出签名身份、停止 TestFlight 测试、处理 Xcode Cloud 数据。
- 转移中：由转出方 Account Holder 发起，接收方 Account Holder 接受。
- 转移后：配置新钥匙串组、验证首次更新、通知用户可能的重新登录。