Thank you for the clarification. We’ll contact Apple Developer Support through the provided channel.

We created a new Development provisioning profile for the transferred App ID using the recipient team after the app transfer was completed. We inspected the profile’s entitlements allowlist as described in TN3125. The profile does not contain previous-application-identifiers. The profile uses the transferred app’s explicit App ID, and its application-identifier contains the recipient team’s App ID prefix. Is there an additional step required to enable previous-application-identifiers for this App ID, or does this require assistance from Apple?

Yes to both questions. The app transfer has already been completed, and the App ID has been transferred to the recipient team. The version currently available on the App Store, which was signed by the previous team, already contains the code that generates and stores the separate recovery data while it can still access the original Keychain item. The recipient-team build contains the logic that detects that the original Keychain item is no longer accessible, restores the value from the separately stored recovery data, and saves it to the recipient team’s Keychain access group.

Thank you, AbdulraheemGad, and thank you, Quinn, for the guidance from Developer Technical Support. Our specific goal is to test the complete Keychain recovery flow across the team transfer. We want to start with an archived build signed by the previous team and create Keychain data associated with the previous Team ID / App ID prefix. We then want to update it in place with a build signed by the recipient team. Our expected behavior is that the recipient-team build will not be able to access the Keychain item associated with the previous Team ID. When the Keychain lookup fails, the app should: Detect the missing Keychain data. Restore the required data from our separately migrated data. Store the restored data under the recipient team’s Keychain access group. Continue to operate correctly. Therefore, we need to test the following complete sequence: The previous-team build creates and uses the original Keychain item. The app is updated in place to a recipient-team build. The recipient-team build cannot access the original Keychain item, as expected. The app detects the missing Keychain data. The app restores the migrated data into the new Keychain access group. The app continues to operate correctly with the restored data. Building the older app version with the recipient team and distributing it through TestFlight would not reproduce this condition. In that case, both the old and new builds would use the same recipient-team App ID prefix. The Keychain lookup may therefore succeed, and our recovery path would not be exercised. Can we perform this test by obtaining a provisioning profile for the recipient team that authorizes the previous-application-identifiers entitlement? We would use this entitlement only to allow an in-place update from the previous-team build, not to retain access to the previous team’s Keychain access group. If so, could you please clarify the following? Can a currently valid Ad Hoc build signed by the previous team be updated in place with an Ad Hoc or TestFlight build signed by the recipient team? Would this reproduce, or closely approximate, the update and Keychain behavior experienced by users updating through the App Store? Is previous-application-identifiers the appropriate entitlement for enabling this test? If this is the appropriate testing method, we would like to request the necessary entitlement and provisioning profile for the recipient team. Thank you.