Sign-In with Apple App Transfer and User Migration

Question

Created 5d

Replies 3

Boosts 0

Participants 2

Hi all, I am in the process of preparing for an app transfer, and have sign-in with apple enabled. I have read the documentation thoroughly and multiple times, yet there are a few things I'd like to have a confirmation about, before taking the leap and risking that some users might experience any issues.

If I understand correctly, after the migration if a user performs a sign-in with Apple, they will send an access_token that differs from the one they were sending when the app was assigned to the old team. In case I didn't take any action that means that my system would think this was a new user given the access_token has never been seen before, and therefore it will create a new user. Is that correct? Ok, so if that assumption is correct, I'd like to have a confirmation also of the way I intend to fix this, since we're doing an internal transfer and the database is going to be the same.

I would get a TransferID for all users in my database that have used sign-in with Apple (I have already done that for one of my test users, successfully). After that, I will start the transfer, and accept it from the other team. Once that is done, I will call the migrationinfo endpoint from the other team, getting all the new access_tokens related to the transfer ids. With that information, I will update my databse, adding a relation from the new access token from team B that points to the same user as the access token that was given by team A, and I know which one it is because of the TransferID.

Does that make sense? Would it work? I'm not a fan of messing with the login logic (having a look at transfer_ids, looking for matches, and so on), especially because there doesn't seem to be a way to test this. I believe the only risk is that a user might login after the app has been transferred but before I can upload the new access token to the database, but we can handle these (few, hopefully even zero cases) via ticketing.

These are the resources I have read so far:

https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer#Preparing-to-migrate-users-for-an-app-transfer https://developer.apple.com/documentation/sign_in_with_apple/transferring_your_apps_and_users_to_another_team#3546291 https://developer.apple.com/documentation/sign_in_with_apple/bringing_new_apps_and_users_into_your_team

My last question is: how can I test this before going live? Do I really have to just implement changes/update the DB and then go live, hoping that it will all work? Can't I do some sandbox transfer or anything like that? Even just creating like a "clone" of my app and transferring this one would be a huge boost for the confidence of this big leap. Thanks in advance.

Answered by DTS Engineer in 806268022

Hi @snemiot,

You wrote:

If I understand correctly, after the migration if a user performs a sign-in with Apple, they will send an access_token that differs from the one they were sending when the app was assigned to the old team. In case I didn't take any action that means that my system would think this was a new user given the access_token has never been seen before, and therefore it will create a new user. Is that correct?

Correct, but the app's migration to a new team (from Team A to Team B) also causes all tokens and identifiers for the user to change due to the new association of the recipient team (Team B). So, along with the access_token, the refresh_token, id_token, user ID (id_token.sub) as well as the private email address would differ from what Team A received, because all of this data is team-scoped.

Next, you wrote:

[...] Does that make sense? Would it work? I'm not a fan of messing with the login logic (having a look at transfer_ids, looking for matches, and so on), especially because there doesn't seem to be a way to test this. I believe the only risk is that a user might login after the app has been transferred but before I can upload the new access token to the database, but we can handle these (few, hopefully even zero cases) via ticketing.

I'd recommend looking at the following technote, which may help understand the expected flows:

TN3159: Migrating Sign in with Apple users for an app transfer https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer

Then, you wrote:

My last question is: how can I test this before going live? Do I really have to just implement changes/update the DB and then go live, hoping that it will all work? Can't I do some sandbox transfer or anything like that? Even just creating like a "clone" of my app and transferring this one would be a huge boost for the confidence of this big leap.

There is no test, debug or sandbox environment for Sign in with Apple, or app transfers. You can create a new Apple ID account and use that for testing purposes, however, you'd still have to perform the app transfer. As soon as the transfer is complete, the 60-day transfer period begins, where both teams' tokens, keys and secrets are valid. You can then transfer the app from Team B back to Team A once you've completed your tests and are content with your implementation of the user migration process.

Cheers,

Paris X Pinkney |  WWDR | DTS Engineer

Boost

Answer 1

DTS Engineer OP

Apple

5d

Recommended

Hi @snemiot,

You wrote:

If I understand correctly, after the migration if a user performs a sign-in with Apple, they will send an access_token that differs from the one they were sending when the app was assigned to the old team. In case I didn't take any action that means that my system would think this was a new user given the access_token has never been seen before, and therefore it will create a new user. Is that correct?

Correct, but the app's migration to a new team (from Team A to Team B) also causes all tokens and identifiers for the user to change due to the new association of the recipient team (Team B). So, along with the access_token, the refresh_token, id_token, user ID (id_token.sub) as well as the private email address would differ from what Team A received, because all of this data is team-scoped.

Next, you wrote:

[...] Does that make sense? Would it work? I'm not a fan of messing with the login logic (having a look at transfer_ids, looking for matches, and so on), especially because there doesn't seem to be a way to test this. I believe the only risk is that a user might login after the app has been transferred but before I can upload the new access token to the database, but we can handle these (few, hopefully even zero cases) via ticketing.

I'd recommend looking at the following technote, which may help understand the expected flows:

TN3159: Migrating Sign in with Apple users for an app transfer https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer

Then, you wrote:

My last question is: how can I test this before going live? Do I really have to just implement changes/update the DB and then go live, hoping that it will all work? Can't I do some sandbox transfer or anything like that? Even just creating like a "clone" of my app and transferring this one would be a huge boost for the confidence of this big leap.

There is no test, debug or sandbox environment for Sign in with Apple, or app transfers. You can create a new Apple ID account and use that for testing purposes, however, you'd still have to perform the app transfer. As soon as the transfer is complete, the 60-day transfer period begins, where both teams' tokens, keys and secrets are valid. You can then transfer the app from Team B back to Team A once you've completed your tests and are content with your implementation of the user migration process.

Cheers,

Paris X Pinkney |  WWDR | DTS Engineer

0

Answer 2

snemiot OP

2d

Hi, and thanks for the prompt reply.

I'd recommend looking at the following technote, which may help understand the expected flows:

TN3159: Migrating Sign in with Apple users for an app transfer https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer

As you can see in my original post, I have already had a look at the technote you have linked here, and unfortunately things are not that clear. Since you confirmed some info, I'll try narrowing down the scope of my doubts, hopefully you can tell me if that is a correct way of handling this or not.

Let's say I have a table in my database where I store a relation between the sub (which I get from the Apple Token), and our userId. My plan is the following:

TEAM A: Generate transferId for each sub I have saved in my database
TEAM A: Start App Transfer
TEAM B: Accept App Transfer
TEAM B: Generate team B sub identifiers with the migrationinfo endpoint
Store the new team B sub as related to the same user that the team A sub was related to (we can find this because they have the same transferId)

If all that is done, after the transfer I will open new tokens finding team b sub inside, and with that I can get the same user that the same AppleId was putting inside the sub when the app was assigned to team A.

Is this correct?

In step 5 I might also change the email address if they use a private relay. Should I keep the old email for any reason? Maybe for a rollback?

Later, about the testing you said

[quote='806268022, DTS Engineer, /thread/764888?answerId=806268022#806268022']

There is no test, debug or sandbox environment for Sign in with Apple, or app transfers. You can create a new Apple ID account and use that for testing purposes, however, you'd still have to perform the app transfer. As soon as the transfer is complete, the 60-day transfer period begins, where both teams' tokens, keys and secrets are valid. You can then transfer the app from Team B back to Team A once you've completed your tests and are content with your implementation of the user migration process.

[/quote]

There is no test, debug or sandbox environment for Sign in with Apple, or app transfers. You can create a new Apple ID account and use that for testing purposes, however, you'd still have to perform the app transfer. As soon as the transfer is complete, the 60-day transfer period begins, where both teams' tokens, keys and secrets are valid. You can then transfer the app from Team B back to Team A once you've completed your tests and are content with your implementation of the user migration process.

0

Answer 3

snemiot OP

2d

Later, about the testing you said

There is no test, debug or sandbox environment for Sign in with Apple, or app transfers. You can create a new Apple ID account and use that for testing purposes, however, you'd still have to perform the app transfer. As soon as the transfer is complete, the 60-day transfer period begins, where both teams' tokens, keys and secrets are valid. You can then transfer the app from Team B back to Team A once you've completed your tests and are content with your implementation of the user migration process.

I do not see any benefits here, as with the transfer I'm exposing my app to user login issues, so doing it twice could only make it worse, or am I missing something?

Would it be possible to "clone" my app and transfer a clone of it instead of the version installed by the users of the store so it does not affect them? Or maybe creating a brand new app, just for testing purposes? I see the App Store requirements are quite strict, and a "test" app of course wouldn't pass those (even if just with restricted access to a few selected test users)

0