How can we test an update from a specific pre-transfer app version to the first post-transfer release?

TestFlight is the supported path: install the old build, then update via TestFlight. Ad Hoc works too, but needs previous-application-identifiers, request it via Apple Developer Support.

TestFlight is also the tool I would reach for. The simplest case — installing the app from the App Store and then upgrading that from TestFlight — is something I’ve seen a bunch of developers do.

Testing the upgrade from older versions of the app is gonna be trickier. There isn’t a good way to install an arbitrary version of the app from the App Store, so the standard process doesn’t work. And installing Development or Ad Hoc signed .ipa isn’t a great option because the old team’s signing assets will expire at some point.

Given that, I think you need to look at the specifics. What aspect of the upgrade process are you trying to test? For example, if you’re trying to test whether the new app handles the content of the old app’s container, you have more options.

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

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:

1. Detect the missing Keychain data.
2. Restore the required data from our separately migrated data.
3. Store the restored data under the recipient team’s Keychain access group.
4. Continue to operate correctly.

Therefore, we need to test the following complete sequence:

1. The previous-team build creates and uses the original Keychain item.
2. The app is updated in place to a recipient-team build.
3. The recipient-team build cannot access the original Keychain item, as expected.
4. The app detects the missing Keychain data.
5. The app restores the migrated data into the new Keychain access group.
6. 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.

Two questions:

• Have you already migrated the App ID?
• Is the code that generates the “separately migrated data” already in the app that’s currently in the App Store?

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

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.

Thanks for those clarifications.

If you use the recipient team to create a new profile for the app, does it list previous-application-identifiers in its entitlements allowlist?

For information on how to dump the entitlement allow in a profile, see TN3125 Inside Code Signing: Provisioning Profiles.

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

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?

Is there an additional step required to enable previous-application-identifiers for this App ID … ?

I don’t believe that there’s any self-service mechanism for this, so you should reach out via Apple > Developer > Contact Us.

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

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