Preserving keychain access after app transfer already completed (ITMS-90076) — wallet app with device-bound keys

Dear community,

I recently transferred my iOS app to a different developer account as part of an app acquisition. When uploading now on the new team the first build from the new team via Xcode Cloud, I get:

ITMS-90076: Potential Loss of Keychain Access - The previous version of software has an application-identifier value of ['OLDTEAMID.ch..'] and the new version of software being submitted has an application-identifier of ['NEWTEAMID.ch..']. This will result in a loss of keychain access.

I understand this is expected, since the App ID prefix changed from the old Team ID to the new one. The problem is that this app is a crypto wallet: it stores the user's private key in the keychain using the default access group ($(AppIdentifierPrefix)$(CFBundleIdentifier)), with kSecAttrAccessibleWhenUnlockedThisDeviceOnly and no iCloud synchronization. If existing users update to a build signed by the new team, they permanently lose access to their keys — there is no server-side recovery.

	<key>keychain-access-groups</key>
	<array>
		<string>$(AppIdentifierPrefix)$(CFBundleIdentifier)</string>
	</array>

It was extremely stupid to do it like this :(

I've read the "App ID Prefix Change and Keychain Access" post, which describes migrating keychain items into an app-group-based access group before the transfer, then transferring the app group along with the app. Unfortunately, my transfer has already completed.

My questions:

  1. Is transferring the app back to the original team, shipping a migration update that moves keychain items into an app group access group, and then re-transferring the app together with the app group still the recommended (and only) path in this situation?

  2. Are there any pitfalls with migrating items protected by SecAccessControl (.userPresence) into an app group access group, given that reading them requires biometric/passcode authentication?

  3. Is there any timing constraint or cooldown I should be aware of when transferring an app back and then transferring it again shortly after?

  4. Any other less time intensive options? Is it possible to "transfer a team id"? Or rename/handover the old account to the new developer?

Thank you for the team and guidance on this.

Answered by DTS Engineer in 894210022
1- Is transferring the app back to the original team, … still the recommended (and only) path in this situation?

It’s the only supported path that I’m aware of.

1- Are there any pitfalls with migrating items protected by SecAccessControl (.userPresence) into an app group access group … ?

I’m not aware of any, but this is something you can and should test. Specifically:

  1. Using a standard iOS device, install the old version of your app from the App Store.
  2. Run the app to create your keychain item.
  3. Then install the new version of the app from TestFlight.
  4. And confirm that it has access to your keychain item.
3- Is there any timing constraint or cooldown I should be aware of when transferring an app back … ?

Not that I’m aware of, at least not from the Apple side of things.

There is, of course, the question of how long to wait for step 4 of the process (per section Transfer Your App to Another Team of App ID Prefix Change and Keychain Access), but only you can judge that.

4- Is it possible to … rename/handover the old account to the new developer?

Kinda.

You can’t transfer accounts per se, but you do have this option:

  1. If the app’s current team is an Individual team, convert that to an Organization team. It’s likely that this will involve starting a new company.
  2. Sell that company to the new developer.
  3. As part of that, change the team’s Account Holder to be the new developer.
  4. And then have them remove you from the team.

As to whether this is “less time intensive”, it’s hard to say, but I suspect not. The issue is that the new developer gets an entirely new company to wrangle, which is likely to involve a lot of ongoing paperwork.


If I were in your shoes I’d think seriously about the Do Not Transfer option explained in App ID Prefix Change and Keychain Access. It’s a hassle for your users, but it’s by far the safest option because, if anything goes wrong, you can ship fixes to either or both apps.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1- Is transferring the app back to the original team, … still the recommended (and only) path in this situation?

It’s the only supported path that I’m aware of.

1- Are there any pitfalls with migrating items protected by SecAccessControl (.userPresence) into an app group access group … ?

I’m not aware of any, but this is something you can and should test. Specifically:

  1. Using a standard iOS device, install the old version of your app from the App Store.
  2. Run the app to create your keychain item.
  3. Then install the new version of the app from TestFlight.
  4. And confirm that it has access to your keychain item.
3- Is there any timing constraint or cooldown I should be aware of when transferring an app back … ?

Not that I’m aware of, at least not from the Apple side of things.

There is, of course, the question of how long to wait for step 4 of the process (per section Transfer Your App to Another Team of App ID Prefix Change and Keychain Access), but only you can judge that.

4- Is it possible to … rename/handover the old account to the new developer?

Kinda.

You can’t transfer accounts per se, but you do have this option:

  1. If the app’s current team is an Individual team, convert that to an Organization team. It’s likely that this will involve starting a new company.
  2. Sell that company to the new developer.
  3. As part of that, change the team’s Account Holder to be the new developer.
  4. And then have them remove you from the team.

As to whether this is “less time intensive”, it’s hard to say, but I suspect not. The issue is that the new developer gets an entirely new company to wrangle, which is likely to involve a lot of ongoing paperwork.


If I were in your shoes I’d think seriously about the Do Not Transfer option explained in App ID Prefix Change and Keychain Access. It’s a hassle for your users, but it’s by far the safest option because, if anything goes wrong, you can ship fixes to either or both apps.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Preserving keychain access after app transfer already completed (ITMS-90076) — wallet app with device-bound keys
 
 
Q