Sign in With Apple Through the Eyes of a Developer

It’s been a while since the WWDC19 keynote, where Apple introduced a lot of cool stuff not just for iOS users, but also for developers, with a brand new social login called Sign in with Apple being one of them. Since we at Ackee have implemented and use Sign in with Apple in all of our apps which require social login, we have decided to share some of our insights and experience.

Why Sign in with Apple?

Sign in with Apple is a privacy and security focused single sign-on service, which serves as an alternative to the existing social sign in options like Facebook or Google. It promises a fast, secure and privacy-friendly experience. All accounts are protected with two-factor authentication, users can simply create a new account using Apple ID associated with their device and authenticate with Face or Touch ID, all in a nice native way.

Apple claims not to track any user’s activity and also gives an option to hide email addresses by providing its own private email relay service. It works natively on iOS, macOS, tvOS and watchOS, but can be also deployed on websites or other mobile platforms, such as Android. If all of these buzzwords haven’t yet convinced you to implement it in your application, you might end up doing so after all - App Store review guidelines make it mandatory for all new apps and app updates submitted to the App Store using other third-party or social login service to implement Sign in with Apple by April 30, 2020.

How it Works

When you choose to login using Sign in with Apple for the first time, a nice native popup is presented, explaining the main advantages and features. After that you can choose whether you want to share or hide your email. If you choose to hide it, Apple generates a unique email address ending with @privaterelay.appleid.com that developers and apps can communicate with, without revealing your true email and thus keeping it totally private. But don’t worry, all of the emails sent to your new unique email address will be automatically forwarded to your real email address associated with your Apple ID, so you won’t lose any important communication from the app. And if everything goes well, hooray, you have successfully signed in to the app using Sign in with Apple! So what’s not to like about this, right?

Our experience

Apple tries to make the implementation of Sign in with Apple as easy and straightforward as it can possibly be, but unfortunately, we have stumbled upon a few small drawbacks during the process. 

First of all, Apple provides its own Sign in with Apple button with Apple-approved title, font, color and style along with an API to render it in your applications. However, you can’t manually adjust the font size of the button. You might expect the font size to get bigger as the frame of the button expands, but as you can see on the image below - this doesn’t always apply. Oh, and did I mention that the button, although it is totally native and advised to use, doesn’t automatically adapt to dark mode? You have to handle the changes all by yourself, as opposed to other native UIKit components, which adapt to trait changes without any additional hassle. In regard to this behavior, we have decided not to use the default button in some of our apps. At first we were not sure if Apple would approve such apps, because the guidelines were not very clear at the time, but in the end the apps passed the review without any further problems.

Let’s say your app contains a profile page, where you would like to display the user's basic information, such as full name, email or photo, after the user logs in. With Sign in with Apple, you can only retrieve this information when the user logs in for the first time. On every other login, this information is not retrieved, so you need to keep in mind to store the user’s information on the first registration. Also, the photo associated with Apple ID can’t be retrieved at all.

Testing your Sign in with Apple implementation, while the feature is still in development, can also be a little tricky. Basically, if you want to test sign in for the first time and receive a full name and email, there is no easy or fast way to do that. You need to remove the permission in Settings > Apple ID > Password & Security > Apple ID Logins/App Using Your Apple ID > Your app name > Stop using Apple ID, which after a few tries, can get unnecessarily tiring.

Last but not least, it is important to mention that Sign in with Apple is only available for iOS 13+. We were thinking about “hacking” this and implementing it in a similar way as websites or Android do it, by simply putting a redirect to Apple’s authorization page, but this behavior could be considered as not the desired experience, as it is not native, and could get rejected during App Store review. Sadly, we were forced to hide the Sign in with Apple button with all the functionality for the older versions of iOS. Although the adoption of newest iOS releases is pretty quick, some of the users can still feel a little left out.

Summary

As mentioned above, Sign in with Apple maybe has small shortcomings for us as developers, but overall it is really a great feature which we love. I personally prefer to use it over any other option in apps I use on a daily basis, and believe that so will most of the Apple users. Not only this, but the whole WWDC19 was a clear sign that Apple truly cares about its community, including developers.

If you would like to see how we implement Sign in with Apple in code and integrate it to our apps using Firebase in more detail, don’t hesitate to check out the video of our talk at Cocoaheads Prague meetup. If you’re interested in what new features Apple has comes up with at WWDC20, stay tuned for our next blog post! ????