Overview of app transfer

Apps that offer auto-renewable subscriptions must use an app-specific shared secret.

• Initiate an app transfer

  Before initiating a transfer for an app that offers auto-renewable subscriptions, generate an app-specific shared secret. Then, share the code with the user of the developer account you are transferring the app to. After sharing the code, initiate the app transfer.

• Accept an app transfer

  Before you accept an app transfer for an app that offers auto-renewable subscriptions, obtain the app-specific shared secret from the initiator, so that you can update your servers to use the code to verify auto-renewable subscriptions. Once the app transfer is complete, generate an app-specific shared secret so that users outside of your organization no longer have access to it.

Keychain sharing continues to work only until the app is updated. Therefore, the keychain needs to be rebuilt when submitting an update. If the keychain group is defined in the Xcode project, it must be replaced with a keychain group created by the recipient (that includes the recipient's Team ID) for the app to continue using keychain sharing. After users update their app, it will not find an authentication token in the keychain and will ask for a one-time re-login.

Associated client SSL certificates, TLS certificates, and authentication tokens for push notifications aren’t transferred. If the app uses Apple Push Notifications service (APNs), the recipient needs to create a client SSL certificate using the recipient’s developer account to reenable it.

If you transfer an app that uses Apple Pay, the merchant ID is not transferred along with the app. Transactions continue to be successful as long as the original certificates are valid. However, when you submit an update, a new merchant ID must be created on the recipient’s account.

As part of preparing your data for the recipient before the transfer, you will need to generate a transfer identifier for each user in your database. You can do this via a REST service endpoint provided by Apple.

If you have grouped your apps for Sign in with Apple, you will need to ungroup them before initiating the transfer.

The Services ID associated with an app that has configured Sign in with Apple will also be transferred. If you don’t want the Service ID to be transferred, remove its association before initiating the transfer.

If your app distributes Wallet passes that require ongoing updates from your app or web service, the passes will eventually need to be reissued using a new identifier after transfer is complete so they can be signed with certificates issued from your Apple Developer account. To minimize user confusion and avoid interruption, we recommend providing a message in your app to let users know that their previously issued pass will become inactive and to download a new pass from your app or web service.

Learn about distributing, updating, and accepting passes.

Learn about best practices for setting alerts.

If your app uses any of the following, it will be transferred to the transfer recipient after they accept the app transfer.

• iCloud to store user data

• iCloud containers

• KVS identifiers associated with the app

If multiple apps on your account share a CloudKit container, the transfer of one app will disable the other apps’ ability to read or store data using the transferred CloudKit container. Additionally, the transferor will no longer have access to user data for the transferred app via the iCloud dashboard. Any app updates will disable the app’s ability to read or store data using the transferred CloudKit container.

If your app uses iCloud Key-Value Storage (KVS), the full KVS value will be embedded in any new provisioning profiles you create for the transferred app. Update your entitlements plist with the full KVS value in your provisioning profile.

Learn about building apps using CloudKit.

Multiplayer Compatibility: Apps that are part of a cross-app multiplayer compatibility matrix are no longer compatible with or appear in the other app’s matrix. After the app transfer, the recipient must add multiplayer compatibility to the app in order for it to work with their existing apps.

Game Center Groups: Apps that are part of a Game Center group are removed from the group during the transfer. After the transfer, all leaderboards and achievements revert to their original status. Leaderboards that were originally a group leaderboard retain the grp. prefix in their identifier. After the transfer is complete, the recipient can add the app to the Game Center groups.

Merged Leaderboards: Leaderboards that were originally single leaderboards but were merged into a group lose the grp.prefix after transfer. They also revert to the original leaderboard IDs they had before the merge. After the app transfer, the recipient must update the app build with the new leaderboard IDs so that scores post correctly.

Matchmaking: Matchmaking configuration isn’t transferred along with the app. For Game Center matchmaking to work, matchmaking rules must be created or modified on the recipient’s side after transfer is complete.

Before initiating a transfer, the transferor should notify any impacted alternative app marketplaces about the transfer of the app. Both the transferor and recipient are responsible for notifying marketplaces of any changes.

If you’re transferring an app that’s distributed on an alternative app marketplace, the recipient must have the same marketplace added in App Store Connect before the transfer and have signed the Alternative Terms Addendum for Apps in the EU for the app to remain available for download. Transferred apps will only be available on alternative app marketplaces that were added in App Store Connect by both the transferor and recipient before the transfer.

When you transfer an app that is part of an app bundle, you can no longer view your app bundle’s history. It is important to make a record of your app bundle information before you transfer the app.