Sign In with Apple

Many apps allow you to register and login with Facebook or Google, rather than having to create an account; some even require it. This is much more convenient than creating a new account for every app you use, but comes at the cost of providing personal information that Google and Facebook then use to target ads at you.

Apple wants to provide users with a secure method of logging into these apps that keeps your private information secure. To support this end, at WWDC this year, Apple has introduced a “Sign In with Apple” button that look like this:

Not only is Apple offering this to app developers, but Apple is going to require that all app developers that offer alternative login methods (like Facebook or Google) to also offer Sign in with Apple. This will ensure that users will be given the option of using Apple’s more private method of logging in.

How is it more private? Facebook and Google use login information to help with user tracking and advertising. The Apple sign in method will not be used for this.

Another new privacy feature is that, upon signing in using ‘Sign In with Apple’, the user will be given the option of using a randomly generated “dummy” email address for their account that will forward emails to users’ real accounts. This protects you from having to share your real e-mail address. Every app the user uses will use a different dummy e-mail, so vendors of multiple apps will not even be able to tell if you use more than one of their apps.

Apple provides a sample app demonstrating the basics of the functionality, and we will be running through some of the details here, along with some code for checking notifications that are not in the sample app.


So how do you, as a developer, set this up in your app?

1. First you need to add the AuthenticationServices framework to your iOS 13 / Xcode 11 project.

2. Then under “Signing and Capabilities” tab of your project, add the “Sign In with Apple” capability:

3. Make sure you also set your team in the “Signing” part so that Xcode can create a provisioning profile that uses the Sign In with Apple capability.

4. Add the Sign in with Apple button to your app. Add this to your login view. You can either add it in Interface Builder by creating a UIView and making its class ASAuthorizationAppleIDButton and setting up an action for it, or by adding it programmatically:

The import and button:

5. Now make sure that the button action handles the login request:

Right now the only scopes you can request are .fullName and .email. The name and email will be returned in the delegate function, shown in step 8.

Note that you can also check for login when you login view first shows up, and that if you have a username/password system already in your app, you can ask to see if you’re authorized that way as well:

6. The function in step 5 sets up the controller as the presentationContextProvider, which specifies this function:

This returns the most appropriate view for the login authorization UI to be presented over.

7. The function in step 5 also sets up the delegate, so we need to handle the delegate functions. The first is error handling:

The second is actually handling the login result:

8. We can check to see if we’ve already been authorized when the app starts in our AppDelegate:

9. As well, you can watch for changes to the login state:


During our testing we ran into a few issues.

1. Testing should really be done on the device. The call to ASAuthorizationAppleIDProvider().getCredentialState(…) always fails in the simulator with a result of .notFound. While on a device, the function returns expected results.

2. The sample app does not illustrate how to handle logging out of the app. Nor does it say how apps handle logging in on a new device when the user has logged in on another one already. The WWDC session mentions it, but it is not illustrated in the sample app. The Sign Out button in the sample app just clears local information about the user, so that the check for the username fails and it tries to sign in again. It does not have an actual sign out procedure.

3. Rotating the device into landscape, then back into portrait, breaks the UI.
4. As well as on a user, we would receive this error after authorizing.

Bug reports have been filed for these and we will update in the future when we hear back.

And that’s it! Using Sign In with Apple is very straightforward. Most (if not all) users that open your app have an Apple account. Having a 1st party log in integration for authorization will speed up development, and not require any social media accounts.

Henning Hoffmann believes that great code is an elegant weapon, towards a more civilized age.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store