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_token
s 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.
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