出于内部原因，我正在将我们组织的应用迁移到新的开发者帐户。我已经了解到，在将应用程序转移到新帐户后，在我们从新开发者帐户发布应用程序更新后，我们将导致一次丢失钥匙串数据。 我担心的是，我们无法承受这种数据丢失。由于安全原因和使用该应用程序的客户类型的性质。
所以我的问题是2部分;
1）有什么方法可以防止这种钥匙串数据丢失？
2）如果没有，我可以使用哪些替代策略来阻止用户在此过渡期间退出？
答案 0 :(得分：1)
假设你正在谈论一个真实的，App Transfer，我认为这是不可能的。钥匙串不仅可以通过应用程序ID进行区分，还可以通过组织的ID进行区分（或者更准确地说，组织的ID是应用程序ID的一部分）。由于应用程序的ID实际上随传输而变化，iOS将阻止它查找其旧的钥匙串。甚至不是应用程序组都可以解决这个问题，因为一个组不能包含不同组织AFAIK的应用程序。 Apple至少需要在某个特定的迁移期内实现一种例外，但我怀疑这种情况是否会发生（出于安全考虑）。
绕过重新登录的唯一方法，以便转移的应用可以将凭据保存在其新的＆＃34; keychain将首先获得旧，尚未转移的应用程序的更新，并将其保存在其他位置，然后让转移的应用程序从那里查找它们。出于安全原因，我强烈建议不要这样做，但如果你绝对必须这样做，你可以安全地上传凭证（通过加密连接，显然，即SSL）。你甚至可以使用shared web credentials来解决这个问题，但我还没有深入研究过，所以我不确定这两个应用是否可以配置为与该网站相关联（他们＆＃39;毕竟，来自两个不同的团队，但可能会被允许）。
即便如此，一些用户可能会错过＆＃34;在转移之前更新旧应用程序（并更新到＆＃34; new＆＃34; one），然后他们将不得不重新登录。
如果你遵循这个想法，请注意你已经四处走动了＃34;用户＆＃39;私人数据以新的方式！考虑到最近的GDPR模糊，这甚至可能具有字符串法律含义，所以请咨询贵公司的法律顾问，了解这一点！
答案 1 :(得分：0)
1）由于应用程序转移期间应用程序ID前缀已更改TN2311 > A one-time loss in keychain data will occur if you switch your App ID prefix
，因此您无法阻止数据丢失<强> 2） 如果您的应用程序使用推送通知，您可以使用APNs设备令牌重新映射用户帐户。
推出新应用后：
对于那些不允许通知的人，只需强迫他们重新登录