Migrate Sign in with Apple Account

Issue

A few weeks ago, the app at the company where I work underwent the transfer of app ownership in the Apple Store, which means transferring from one Apple Developer account to another. There are many tasks to complete before the transfer; essentially, you need to follow the steps in the list they provided in order to begin the ownership transfer.

One of these tasks is to Migrate Sign in with Apple users to another team. All user accounts created by clicking the "Sign in with Apple" button integrated into the app need to have their user data migrated. Apple always emphasizes user privacy, so the app transfer to another account must also ensure privacy. There is some information that will change, with the most critical being the apple ID (or sub) and private email.

When users click the "Sign in with Apple" button, the data that we save to identify them is usually the email address and the apple ID. In cases where users choose not to share their real email address, we can only obtain the private email. The apple ID and email are essential for identifying a user when they log into the system; during the ownership transfer, these two critical pieces of information are at risk of being altered. In other words, if the app transfer is successful, the users who previously logged into the system will receive different apple IDs and private emails, and if this data does not match, we may treat them as new users.

Thus, we need to carry out this migration before transferring the app. Fortunately, Apple provides very detailed guidance, but it can be somewhat difficult to read, so this article aims to clarify how to carry it out.

Migrate Accounts

As mentioned, Apple has documentation on how to migrate accounts, with the ultimate goal of obtaining the new apple ID and private email to update the existing user data in the system. The process consists of two steps as follows.

Step 1 is performed on the account currently holding the app. The goal is to obtain a transfer identifier code called transfer_sub. Each account has its own code; after obtaining all the codes, transfer the transfer_sub to the team that will receive the app.

Step 2 is performed on the receiving account. The goal is to use the transfer_sub to extract the new user account information, including the new apple ID and private email.

The documentation also clearly outlines the API endpoints needed to perform the above steps. Therefore, you only need to write a piece of code to carry out the retrieval and use of transfer_sub. By coincidence, I found a repository that has rewritten these APIs into relatively clear functions. Readers can refer to yjiq150/apple-signin-migration-on-app-transfer.

Note that you need to modify the parameters inside the beforeAppTransfer and afterAppTransfer functions to ensure they match the app's information. During the migration process, Apple does not mention any rate limits for these APIs or the number of calls on the same account. From my practical experience, there are indeed no limits; the APIs can be called continuously at a very fast rate, but occasionally a few API calls may fail, so a retry mechanism or logging is needed to handle these cases.

Another important note is that these transfer APIs are only available for 60 days from the successful app transfer. If the migration is not executed within 60 days, you must transfer the app back to the old account before migrating again from the beginning.

Conclusion

Migrating "Sign in with Apple" accounts is an important step when transferring app ownership in the Apple Store to ensure continuity and user data security. This process mainly revolves around two steps: first, obtaining the transfer_sub identifier from the current account, and then using this code to update user account information on the new account. Although Apple's documentation provides detailed guidance, practical implementation may be challenging for those encountering it for the first time.

However, it is important to note that these APIs are only available for 60 days from the app transfer date, so timely planning and execution are crucial. Additionally, attention should be paid to retry mechanisms and logging to handle any unexpected API errors.