卖掉应用、公司重组，或者想把某个产品迁到另一个 App Store Connect 组织——这三种情况都需要在 Apple 开发者账号之间移动应用本身。好消息是：Apple 把这件事做成了平台的原生功能。转让期间和转让完成后，应用在 App Store 上保持在线，评分和评论保留，用户依然能收到更新。坏消息是：这是一场长达 60 天、需要双方配合的操作，条件清单很长，而且有大量内容不会跟着应用一起转移。本文按照 Apple 官方的应用转让文档，把整个流程梳理成一份可逐项勾选的清单。
1. 先确认应用符合条件：转让标准
在任何人开始点击之前，双方账号和应用本身都必须通过 Apple 的应用转让标准。逐项核对：
- 两个账号都必须是稳定状态——不在待处理或变更流程中，且双方都已接受最新版的付费与免费协议。如果发起方接受了 Apple 的欧盟替代条款附录（EU Alternative Terms Addendum），接收方也必须同意才能接受转让。
- 应用必须至少有一个版本已在 App Store 发布。
- 应用不能处于任何国家或地区的预购状态。
- 应用不能处于这些被阻止的状态：Processing for Distribution、Waiting for Review、In Review、Accepted、Pending Developer Release、Pending Apple Release。
- 应用内购（In-App Purchase）产品必须处于允许的状态（Approved、Ready to Submit、Developer Removed from Sale 或 Rejected）。
- 应用的IAP 产品 ID 不能与接收方账号下任何应用的产品 ID 冲突。
- Apple Arcade 应用不能转让；与其他 Mac 应用共享 Application Group Container Directory 的 Mac 沙盒应用同样不能转让。
2. 开始前先备份一切
应用转让本质上是一次移除：完成后，应用将不再出现在发起方的账号里。Apple 的发起指南建议保留元数据和定价记录、应用在 App Store 上线的日期，以及销售和下载数据。其中两点要特别留意：
- 销售与付款：发起方保留转让前发生的付款和销售数据访问权，但转让后的数据不再可见。接收方只能看到转让后产生的交易信息。
- App Analytics：转让后发起方完全失去 App Analytics 的访问权（历史数据仍可在 Sales and Trends 中查看）。接收方则获得自 2015 年 4 月 1 日（或应用首次上架之日，以较晚者为准）以来的全部分析数据。
3. 随应用转移的内容
应用在商店中的大部分身份信息都会随转让移动。根据 Apple 的转让概览：
- Bundle ID 及关联的 App ID 随应用转移（通配符 App ID 会被转换为与 Bundle ID 完全匹配的显式 App ID）。
- 评分、评论和商店元数据，包括本地化文案和无障碍支持信息。
- 内购产品（需满足上述条件），用户无缝继续收到应用更新。
- 为应用配置的 webhooks、OS 数据传输（Android 包名与签名密钥指纹），以及与应用关联的 iCloud 用户数据、CloudKit 容器和 KVS 标识符。
4. 不会转移的内容——需要自己处理的部分
这里是最容易让转让计划翻车的地方。以下内容会留在原地或悄然失效：
- APNs 证书与密钥：现有证书在到期前仍然有效，但到期后接收方必须生成新的；如果使用的是 APNs 密钥，接收方需要生成或复用密钥，并更新推送服务器。
- Apple Pay merchant ID：不会随应用转移。在原证书有效期内交易仍正常，但接收方在提交任何更新之前必须创建新的 merchant ID。
- Sign in with Apple：Service ID 会随应用转移（如果不希望转移，需在开始前解除关联），并且必须在转让前通过 Apple 的 REST 接口为数据库中的每个用户生成转移标识符。已分组的应用需要先取消分组。
- Game Center：转让期间应用会退出原有的组；排行榜和成就恢复到分组前的状态，匹配配置不会转移，接收方可能需要在构建中更新排行榜 ID。
- Promo codes：转让后无法再生成新的促销代码，与所有权无关。
- TestFlight 与 Xcode Cloud：发起转让之前必须关闭测试（移除所有构建和测试者、清空 Test Information 字段），并删除全部 Xcode Cloud 数据。
5. 发起方清单：发起转让
只有Account Holder（账户持有人）可以发起——同样也只有 Account Holder 可以接受（可先查看角色权限）。按 Apple 的发起指南操作：
- 进入应用的App information 板块，滚动到 Additional Information，点击 Transfer App。
- 按提示输入两步验证码。
- 填写接收方 Account Holder 的 Apple Account 和 Team ID。
- 阅读并同意转让条款，点击 Request Transfer。
- 等待：转让在对方接受前保持 Pending App Transfer 状态，且60 天后过期。待处理期间无法编辑元数据、定价、可用性和内购，已有的 App Review 沟通会被关闭。
在 Waiting for Recipient 状态下，双方都可以取消（Business → Agreements → App Transfers）。
6. 接收方清单：接受转让
接收方必须在 60 天内接受。按 Apple 的接受指南操作：
- 登录 App Store Connect，进入 Business → Agreements → App Transfers，点击 Review。
- 填写新的元数据：Support URL、Marketing URL（如果应用之前有则必填）、Privacy Policy URL（规则同上），以及 App Review 和 App Store 联系信息。
- 选择用户访问范围：全体团队成员，或仅 Admin 与 Finance 角色（之后可再限制）。
- 核对上一任所有者填写的App privacy 数据；如果没有，需在提交下一个版本前完成该板块。
- 同意条款并点击 Accept。转让完成最多需要两个工作日（状态为 Processing App Transfer）；如果需要出口合规文档，应用会进入 Waiting for Export Compliance 等待审核。
7. 转让完成后：接收方的后续清单
- 在接收方的 Apple Developer 账号中创建新的 provisioning profiles，并关联到被转让应用的 App ID。
- 自动续期订阅应用：转让完成后，生成新的 app-specific shared secret，让原所有者不再能访问，并同步更新服务器。
- 如果应用使用了 keychain sharing，需要用接收方 Team ID 下新建的 group 重建 keychain——keychain sharing 只持续到第一次更新为止，之后用户需要重新登录一次。
- 如果应用使用了 App Groups，从发起方账号删除该 group，并在接收方账号重新注册。
- 如果应用分发 Wallet 卡券，需要用新的标识符重新签发，确保卡券由接收方的证书签名。
一句话总结：iOS 应用转让是一场以清单驱动的双账号操作——先核对条件、备份数据、清理 TestFlight 和 Xcode Cloud，由 Account Holder 发起、接收方在 60 天内接受，然后在推送下一个版本之前，重建接收方侧的基础设施（provisioning profiles、APNs、shared secret、merchant ID）。