App Store Connect App Transfer 后怎么打包？2026 交接清单

旧打包机还能打开项目，但接收方第一次上传时出现签名、权限或能力配置错误。

最快解法：App Transfer 后不要直接复用原团队的签名和发布凭据；先确认 Bundle ID 与能力配置，再在远程 Mac 上建立新签名、推送和上传链路，并用一次真实 Archive 与 TestFlight 上传完成验收。

时间表建议： 转让前完成资料备份，转让完成后先保留旧环境短期双轨运行，接收方的新链路通过 TestFlight 验证后，再撤销旧账号权限、Runner、Webhook 和密钥。

本文适合三类人：准备出售 App 的开发者，用来整理源码、构建资产和服务配置；接手 App 的独立开发者，用来恢复签名、推送和发布能力；维护远程 Mac 或自动打包环境的小团队，用来确定旧环境退役与回滚边界。

App Transfer 改变的是 App 在 App Store Connect 和开发者团队之间的归属，不会自动把源码仓库、证书私钥、CI 变量、远程 Mac 用户目录、构建脚本和第三方服务凭据打包交给接收方。Apple 也明确要求转让方直接向接收方交付实际代码和构建资产，而不是只完成后台的转让操作。Apple 的 App Transfer 概览

转让方需要先建立一份“可恢复发布包”，至少包括以下内容：

• ✅ 源码仓库、依赖锁定文件、子模块和私有 Package 地址；
• ✅ Xcode 工程、Scheme、Build Configuration、ExportOptions 配置和构建脚本；
• ✅ 所有 target、Extension、Widget 和 Mac Catalyst target 的 Bundle ID、App ID、Capabilities 与 entitlements；
• ✅ 当前版本号、Build Number、最近一次可安装的 IPA、dSYM 和崩溃符号文件；
• ✅ APNs 使用的是证书还是 API Key，服务器端保存在哪里，生产和测试环境如何区分；
• ✅ App Store Connect API Key、Issuer ID、Key ID 的用途说明，但不要把私钥直接放进普通文档；
• ✅ Webhook 地址、事件类型、回调验签方式和接收服务的负责人；
• ✅ 推送、Sign in with Apple、Apple Pay、iCloud、Keychain Sharing、Associated Domains 等特殊能力的后台配置；
• ✅ 远程 Mac 的登录方式、构建目录、CI Runner、缓存目录和回滚步骤。

转让前应该备份哪些 Xcode 与 App Store Connect 资料？
不要只导出项目文件。还应保存 App Store Connect 的应用元数据、价格与可用性记录、构建历史、TestFlight 配置、销售与下载数据，以及转让前最后一次可复现构建的日志。Apple 说明 App 转让后会从原账户中移除，因此转让方应在发起操作前完成资料备份。Apple 的发起转让说明

转让前还要核对账号状态。双方账号不能处于待处理或变更状态，相关协议需要接受，App 通常还必须有至少一个已经发布到 App Store 的版本；处于审核、等待发布或部分特殊状态的 App 可能无法转让。Apple 的 App Transfer 条件

如果 App 使用自动续期订阅、TestFlight、Xcode Cloud 或 Webhook，也要单独列出停止条件。Apple 的官方流程要求在转让前处理 TestFlight 测试版本和 Xcode Cloud 相关数据；Webhook 是否继续发送，则需要转让双方共同确认服务归属，不能默认原服务器会自动切换。

接收方接受转让后，第一件事不是打开旧工程点击 Archive，而是确认 App Store Connect、开发者账号和项目中的标识符是否已经对应到新团队。

App 转让后，App 会保留原有 Bundle ID，关联的 App ID 也会转移到接收方团队；但是，Bundle ID、App ID、App Store 记录、Team ID 和签名资产并不是同一个对象。Bundle ID 负责标识应用，App ID 还承载能力配置，Provisioning Profile 则把 Bundle ID、证书和授权设备或分发用途组合起来。

建议接收方按下面的顺序验收：

1. 登录新团队的 App Store Connect，确认应用出现在正确的团队中；
2. 检查应用名称、平台、版本记录、历史构建、TestFlight 和用户访问权限；
3. 在 Certificates、Identifiers & Profiles 中确认转移后的 App ID 与目标 Bundle ID 一致；
4. 对照源码中的每个 target、Extension、Widget 和 Mac Catalyst target；
5. 检查 Capabilities 是否完整，尤其是 Push Notifications、Associated Domains、App Groups、iCloud、Sign in with Apple 和 Apple Pay；
6. 确认新的 Team ID 已进入签名配置、CI 变量和服务器端鉴权逻辑；
7. 在新账号下创建或下载新的分发 Provisioning Profile。

转让完成后，原来的 Xcode 打包机还能继续使用吗？
可以把它当作源码检查或短期并行验证环境，但不能把它视为已经完成交接的发布机。旧 Mac 上可能仍然保留旧团队的证书、钥匙串和缓存，甚至能够完成编译；这并不代表它能使用接收方的身份完成稳定签名、上传和后续维护。

Apple 明确说明，App Transfer 完成后，接收方必须在自己的开发者账号中创建新的 Provisioning Profile，并将其关联到转移后的 App ID 和接收方的分发证书。Apple 的接受转让说明

因此，旧机器的正确定位是“短期双轨环境”，而不是“继续共用原团队钥匙串”。不要把原团队的完整 Keychain、Apple Account 密码或分发私钥直接复制给接收方。

接收方应先完成普通签名链路，再处理特殊能力。这样可以把问题拆成“身份错误”和“能力缺失”两类，而不是在一次 Archive 失败中同时排查十几个变量。

Apple Distribution 证书与 Provisioning Profile

转让完成后，Apple Distribution 证书和 Profile 应该怎么安排？
接收方应在新团队下准备适用的 Apple Distribution 证书，并重新生成 App Store Connect Provisioning Profile。旧 Profile 不应作为长期发布资产继续使用；如果项目采用手动签名，还要把新的 Profile、证书和 entitlements 显式绑定到对应 target。创建 App Store Connect Provisioning Profile 的官方步骤

在 Xcode 中，至少核对：

• Signing Team 是否为接收方 Team；
• Bundle Identifier 是否仍为转让后的原值；
• Distribution Certificate 是否属于接收团队；
• Provisioning Profile 是否为新的接收方 Profile；
• Archive 使用的 Scheme 是否为正式发布 Scheme；
• 导出的 IPA 是否含有预期的 application-identifier、keychain-access-groups 和其他 entitlements。

如果使用自动签名，也不能只看 Xcode 没有红色错误。自动签名可能帮助生成 Profile，但不会替开发者确认 APNs 服务器、iCloud 容器、Sign in with Apple 用户迁移或 Apple Pay Merchant ID 是否已经完成。

APNs、登录与支付能力

App 转让完成后，APNs 推送是否需要换配置？
需要检查并更新服务器端推送认证。Apple 说明，原有 APNs 证书在有效期内可能继续有效，但接收团队后续需要生成新的 APNs 证书或密钥，并把服务器切换到新团队的认证资产；如果使用 API Key，也需要确认 Key 属于正确团队。Apple 的 App Transfer 规则

如果使用 APNs TLS 证书，证书和私钥通常还会安装在推送服务器，而不是只存在 Xcode 中。Apple 的配置文档要求为相应 App ID 创建 APNs 客户端 TLS 证书，并将证书身份安全地导出到推送服务所在服务器。APNs TLS 证书配置

接收方还要按功能分类处理：

• Sign in with Apple： 需要迁移用户标识和私密中继邮箱关联，不能只替换 Team ID。Apple 的 TN3159 说明，转让后存在 60 天 的用户迁移窗口，转让方和接收方应提前生成 transfer identifier 并完成服务端迁移。Sign in with Apple 用户迁移技术说明
• Apple Pay： Apple Pay Merchant ID 不随 App Transfer 自动转移。原有交易在相关证书有效时可能继续工作，但提交新版本时，接收方需要创建自己的 Merchant ID，并重新检查 Payment Processing 配置。
• iCloud： 如果共享 CloudKit 容器，转让可能影响同一容器下的其他 App；如果使用 iCloud Key-Value Storage，还要根据新 Profile 中的完整 KVS 值更新 entitlements。
• Keychain Sharing 与 App Groups： 要对照新 Profile 中的授权值检查，不要假设旧安装版本能访问新团队创建的所有共享组。
• Mac Catalyst： 如果 iPad App 与 Mac Catalyst App 不是单独处理，必须确认两个关联 App ID 的转让关系，不能只验证 iOS target。

对于独立开发者和小团队，远程 Mac 的风险不在于“能不能打开 Xcode”，而在于账号、钥匙串、构建目录和上传认证是否被混在同一套旧环境中。若需要先准备独立的构建主机，可以结合 JEXCLOUD 的远程 Mac 方案 规划接收方账号、构建目录和权限边界；不要把原团队的用户目录整体复制过去。

接手 App 后，怎样在远程 Mac 上完成首次 Archive？
建议使用一台可以由接收方独立登录和管理的远程 Mac，先建立新用户或新的隔离构建环境，再按以下步骤操作：

1. 固定工具链。 记录当前 Xcode、macOS、Swift、依赖管理工具和项目依赖版本；不要在第一次验收时顺手升级多个组件。
2. 同步源码。 从可信仓库拉取指定提交，检查子模块、私有依赖和构建脚本，确认路径中不包含原团队用户名或旧机器目录。
3. 注入新凭据。 使用接收方的 Apple Developer 账号、分发证书、Provisioning Profile、App Store Connect API Key 或 Transporter 登录方式；密钥放在受控变量或安全存储中，不写进脚本仓库。
4. 核对签名入口。 在 Xcode 图形界面检查 Signing & Capabilities，再通过 SSH 或 CI 执行一次命令行 Archive，确保两种入口使用的是同一套签名资产。
5. 检查 Archive 内容。 打开 .xcarchive，确认 Bundle ID、Team ID、entitlements、版本号和 Build Number；必要时使用 codesign、security 和 xcodebuild -showBuildSettings 辅助核对。
6. 导出 IPA。 使用与发布用途匹配的 ExportOptions 配置，记录导出日志、IPA 文件哈希和归档路径；不要只截取 Xcode 的“Archive Succeeded”提示。
7. 上传并等待处理。 通过 Xcode、Transporter 或 App Store Connect API 上传，等待构建在后台完成处理。Apple 说明，上传成功不等于构建已经出现在 App Store Connect 中，系统还需要完成处理。Apple 的上传构建说明
8. 完成 TestFlight 验收。 检查构建状态、安装、推送、登录、内购、云服务和关键业务流程，再决定是否撤销旧环境权限。

建议把一次发布拆成 5 个独立结果：编译成功、Archive 成功、IPA 导出成功、上传成功、TestFlight 可安装且线上能力正常。任何一个结果缺失，都不能把交接标记为完成。

我们的建议是优先采用第三种或第四种方案。转让期间保留旧环境，不代表长期共享旧密钥，而是给接收方留下可验证的回退路径；一旦新链路完成真实上传并通过 TestFlight，旧环境就应进入只读或待退役状态。

接收方完成一次真实发布后，转让双方应共同保存以下证据：

• ✅ 使用新团队完成的 Archive 日志；
• ✅ IPA 导出记录与文件哈希；
• ✅ App Store Connect 上传记录和处理结果；
• ✅ TestFlight 构建状态与安装截图；
• ✅ 推送、登录、内购、云服务和关键扩展的验收记录；
• ✅ 新旧环境中凭据、Runner、Webhook 和权限的变更时间；
• ✅ 回滚到上一稳定版本的操作说明。

TestFlight 的构建状态需要单独判断。Apple 将 Invalid Binary、Missing Compliance、Ready to Test、Testing 等状态区分处理；构建已经上传但仍处于处理或合规检查阶段，不能当作最终发布成功。Apple 的构建状态说明

可以用下面的停止条件决定是否退役旧环境：

• 转让方： 新团队已经能独立构建和上传，旧团队不再需要保留生产权限后，撤销旧 CI、API Key、Webhook 和远程 Mac 访问。
• 接收方： 新 Team ID、Bundle ID、证书、Profile、APNs 和特殊能力全部完成记录后，才接管正式发布。
• 共同维护者： 若 TestFlight 尚未可安装、线上推送失败、iCloud 数据无法读写或 Apple Pay 尚未验证，则继续双轨，不要撤销旧环境。
• 远程 Mac 管理者： 保留构建日志和归档证据，但不长期保存原团队私钥；账号权限应按最小权限重新分配。

如果当前方案是把原团队的 Mac、钥匙串和 CI 凭据整体交给接收方，短期看似省事，实际上会产生归属不清、旧凭据泄露、无法审计和后续续签失败等问题；如果使用一台多人共用的本地 Mac，还会增加用户目录、缓存和证书残留造成误签名的概率。对于需要在转让期间保持旧链路可用、又希望接收方拥有独立账号环境的项目，使用 JEXCLOUD 的远程 Mac 会比直接复制原打包机更容易隔离权限、保留双轨构建和追踪交付记录。需要常驻构建或独立账号环境时，也可以进一步查看 JEXCLOUD 的远程 Mac 租赁入口，再根据是否需要 SSH 接入和完整管理权限选择环境。

最后可以把交接压缩成这份核对表：

转让前

• [ ] App Store Connect 转让条件已满足；
• [ ] 源码、构建脚本、IPA、dSYM 和归档已备份；
• [ ] Bundle ID、App ID、Capabilities 和 entitlements 已记录；
• [ ] APNs、Sign in with Apple、Apple Pay、iCloud 和 Webhook 已分类；
• [ ] 旧远程 Mac 的构建路径、CI 和回滚方式已记录。

接收后

• [ ] 新团队能看到 App、历史构建和必要权限；
• [ ] 接收方已创建新的分发证书与 Provisioning Profile；
• [ ] 新远程 Mac 已完成图形界面和命令行 Archive；
• [ ] 新 APNs 证书或 API Key 已接入服务器；
• [ ] 特殊能力已按项目实际情况重新验证。

首次发布后

• [ ] Archive、IPA、上传、Processing 和 TestFlight 安装分别通过；
• [ ] 推送、登录、内购、云服务和关键扩展正常；
• [ ] 日志、产物和版本号可追溯；
• [ ] 旧环境尚未在新链路稳定前被提前撤销；
• [ ] 新链路确认可独立运行后，才停止共享旧团队凭据。