摘要

  • Sign in with Apple 的用户标识属于开发团队的识别范围。App 转给新团队后，旧用户记录需要通过迁移标识接到新团队的登录身份上。
  • Apple 规定转让完成后有六十天迁移期；逾期补救要把 App 转回原团队、备妥用户迁移，再次转给买方。交割后的卖方配合因此有了实际价值。

收购已经完成，买方却得给卖方发一句颇难启齿的话：麻烦把刚卖掉的 App 收回去，再卖——准确地说，再转——一次。

这是错过 Sign in with Apple 用户迁移窗口后的官方处理路径。Apple 的技术说明 TN3159写得很具体：若 A 团队转给 B 团队已超过六十天，B 应把 App 转回 A；A 准备好迁移标识和用户数据后，再转给 B，由 B 完成身份交换。交易合同可以早已签完，技术交接却要走一个回头弯。

资本市场喜欢把用户数放进估值表。登录系统更挑剔：这些用户回来时，新主人究竟凭什么认出他们？

评分会过桥，身份证要换证

App Store Connect 的转让说明描述了相当体面的连续性。符合条件的 App 可以在转让期间继续供人下载，保留评分、评论和 Bundle ID，用户也能继续收到更新。站在商店橱窗前，生意仿佛只是换了收款人。

Sign in with Apple 的身份边界在另一处。它把用户标识限定在开发团队范围内，同一个人到另一个团队，并不是拿着一张通用号码牌报到。这种安排保护隐私，让不同开发者难以靠同一个固定标识串联用户。

于是，卖方数据库里那条熟悉的用户记录，需要接上买方能够识别的新标识。记录中的使用历史、账户关系和服务待遇能否正确接续，取决于这个对应关系有没有完成。买到了数据库，还需要买方的登录流程知道哪一行属于眼前这个人。

Apple 在转出团队指南中安排了一座受控的桥：为每个用户生成面向接收团队的迁移标识。交出的数据用它来识别用户，原团队的用户标识和私密转发邮箱地址须排除在导出数据之外。买方拿这项迁移标识，换取自己团队范围内的用户标识，以及适用时的私密邮箱地址。

这道桥保留了隐私隔离，也给交割增加了一项必须真的做完的工作。合同里的“用户随业务转让”，到了身份系统里，还差一次逐人对应。

六十天不会等项目经理有空

窗口从 App 转让完成算起。卖方可以在转让前准备迁移标识，也可在转让被接受后的六十天内生成；接收方同样必须在接受转让后的六十天内完成交换。卖方在临近截止时才把材料交出，并不会给买方另开六十天。

这使双方的工作顺序有了价钱。卖方负责准备，买方负责交换并把新身份接到已有记录；任何一端把“已经发出”当成“已经完成”，剩余时间都不会迁就它。

接收团队指南也给出登录时建立对应关系的办法。迁移期内，相关登录信息可以带上迁移标识，供新团队识别旧用户。不过，若整个计划只是等用户回来登录，它就把交割进度交给了用户的作息。

有些人每天来，有些人隔几个月才需要这款 App。后者的安静并不会替买方延长期限。Apple 提供服务器端批量迁移，团队可以处理尚未再次登录的用户。一个闲置账户是否已迁好，应该由后台完成记录来回答，而不是由市场部祈祷下周活跃度暴涨。

逾期以后，卖方又成了关键人物

超过窗口，标准迁移通道停止工作；TN3159 的恢复办法重新动用了 App 转让本身。买方把 App 转回去，卖方准备，再转回来。App Store Connect 的转让需要双方各自的 Account Holder 执行发起或接受。这里需要的是能办事的人仍在场，双方账户和配合关系仍可用。

收购前，卖方有动力回答每封邮件。收购后，它可能把人员和注意力放到下一件事。技术补救把这段已经准备散场的关系重新请回舞台。一次本可提前完成的数据交接，变成新的跨团队安排。

缺少具体收购的迁移日志、漏接记录和恢复工时，目前无法给这项返工标价；这些数字会决定它在某笔交易里到底有多贵。机制本身已经足够清楚：新买家独自拥有 App，并不等于独自掌握完成旧用户身份迁移的全部动作。

真正值得放进交割条件的，是已完成的对应关系、对沉默用户的覆盖，以及逾期时仍有人能够执行恢复。把这些事项留给售后友谊，等于把收购的一部分价值寄存在卖方收件箱里。

买方可以庆祝评分原封不动地留下来。只是那串星星，不会替任何一个老用户完成身份交接。