SignInWithApple: Dealing with iOS app transfers to another Apple Developer TeamID

[marcotta]

When transferring an application to another Apple Developer Team, it is required to also transfer all users who logged int via Apple Signin.
When this process is initiated, the credentialState will return a state CredentialState.transferred

In this scenario, apple documentation says "you can consider the current session approved."

Looking at existing code I would like to amend:

case "getCredentialState":
            // Makes sure arguments exists and is a Map
            guard let args = call.arguments as? [String: Any] else {
                result(
                    SignInWithAppleGenericError.missingArguments(call).toFlutterError()
                )
                return
            }

            guard let userIdentifier = args["userIdentifier"] as? String else {
                result(
                    SignInWithAppleGenericError.missingArgument(
                        call,
                        "userIdentifier"
                    ).toFlutterError()
                )
                return
            }

            let appleIDProvider = ASAuthorizationAppleIDProvider()
                
            appleIDProvider.getCredentialState(forUserID: userIdentifier) {
                credentialState, error in
                if let error = error {
                    result(
                        SignInWithAppleError
                            .credentialsError(error.localizedDescription)
                            .toFlutterError()
                    )
                    return
                }

                switch credentialState {
                case .authorized:
                    result("authorized")
                case .revoked:
                    result("revoked")
                case .notFound:
                    result("notFound")

                default:
                    result(
                        SignInWithAppleError
                            .unexpectedCredentialsState(credentialState)
                            .toFlutterError()
                    )
                }
            }

and deal with the case .transferred like:

case .transferred:
                result("authorized")

Do you see any drawbacks in amending the current implementation to also support the transferred state?

[tp]

@marcotta I would agree that we should support transferred and not default into an error state.

I would suggest to use result("transferred") though, in order to give the caller the details.

We could always add an extension on the credentials state like bool get isValid that would return true for authorized and transferred.

Apple's doc state

The app has been transferred to a different team, and you need to migrate the user’s identifier.

What does it mean though to "migrate the user"? I would have to read up on that, but if you already made any investigations, please feel free to share those already.

[marcotta]

Thanks for the quick feedback @tp,
Apple offers an endpoint for starting and completing a user migration.

POST /auth/usermigrationinfo HTTP/1.1
Host: appleid.apple.com

an initial call is made from the transferring team to generate a user transferID
a second call is made from the receiving team submitting the transferID and receiving a new subId and private relay (if available).

I have been looking at this process mainly as an admin task and did not think much about having it as part of the plugin.

Full details are available on:
https://developer.apple.com/documentation/sign_in_with_apple/transferring_your_apps_and_users_to_another_team
https://developer.apple.com/documentation/sign_in_with_apple/bringing_new_apps_and_users_into_your_team

I like the sound of result("transferred") + bool get isValid as it would not hide the details in case developers decide to make some use of them.

Let me know if there is anything I can contribute to help out.

[tp]

I have been looking at this process mainly as an admin task and did not think much about having it as part of the plugin.

Yeah, I just wonder if in practice you can just continue to use that user when getting the transferred state, or whether one would need to do something (in one's backend) then, as the docs state

The app has been transferred to a different team, and you need to migrate the user’s identifier.

So from reading the docs is seems that during this process the user identifier changes (from the old team to the new one), and I am not entirely clear on the timeline.

Wouldn't you migrate all the users at ones by generating transfer tokens and then importing into the new team that way? If that's the case I don't see why the status enum docs state "you need to migrate the user’s identifier", as that would already have happened 🤔

But for now I could offer to add support for the transferred enum case, so you can start testing the flow and not run into any error. I would then add an extension like isApproved to match Apple's nomenclature.

[marcotta]

I have the same understanding, the user identifier will change and the user email private relay will also change.
Those changes will need to be reflected on backend.

I suppose it is there to cover the gap between "generating transfers" and "importing new ids" when multiple team/companies are involved.

The identity token continues to include the transfer identifier, for up to 60 days from the transfer date.

They seem to allow up to 60 days for the migration to complete.

But for now I could offer to add support for the transferred enum case, so you can start testing the flow and not run into any error. > I would then add an extension like isApproved to match Apple's nomenclature.

That would be awesome!