Sign in with Apple Announced, or On June 30 Your App will Turn into a Pumpkin

Apple announced that by June 30, 2020, all new and updated apps must use “Sign in with Apple” button for apps with third-party sign-in options (Facebook, Google, Twitter, etc.). This development would seem pretty straightforward — but it is not without its nuances…

March 4, 2020, Apple released a statement that “All new apps and app updates submitted to the App Store must follow these guidelines [Resources and Sign-in Guidelines] by April 30 (extended to June) 2020.”

The guidelines now require a “Sign in with Apple” (SIWA) button for apps with third-party sign-in options (Facebook, Google, Twitter, etc.).

This development would seem pretty straightforward — but it is not without its nuances…

Can you simply opt out of using “Sign in with Apple”?

Yes, actually — but only if one of the following conditions is met:

● Your app exclusively uses your company’s own account setup and sign-in systems.

● Your app is an education, enterprise, or business app that requires the user to sign in with an existing education or enterprise account.

● Your app uses a government or industry-backed citizen identification system or electronic ID to authenticate users.

● Your app is a client for a specific third-party service and users are required to sign in to their mail, social media, or another third-party account directly to access their content.

Company Experience

Some good articles on the technical side of these new guidelines have already featured:

● Detailed Guide from CIAN (in Russian) —

● — front, back

● Parallels (in Russian) —

Some write that users eagerly use the new button and even believe the new SIWA is growing their audiences.

Another pretty spot-on guide from Aaron Parecki —

The Fine Print

iOS 13 and iPadOS 13.1 and later will support SIWA, so you may have a reason to ask your company for a new test device :) Apple is a company that has their very own peculiar way of doing things, and this new button is no exception. While it may seem like a pretty simple thing, companies should be aware of the following details.

Sign in with Apple obtains a user’s first name, last name and email only one time, at the first log-in. The server doesn’t have access to the data. The next time the user signs in there will only be the authorizationCode from ASAuthorizationAppleIDCredential.

Therefore the client needs to store user data until registration on the server is successful.

The client_secret JWT token can only be generated for a maximum of 6 months.

Our advice — have a built-in token regeneration procedure in your pipeline and generate tokens for 1 month to ensure security and prevent a token from getting overused.

You may also want to do a health check which will check the token validity and time before expiration.

SIWA has no logout feature in the classical sense. The library does not save any data, unlike login APIs, and therefore there is no need to delete login data.

Users can select Hide my email, and Apple will generate a random proxy email along the lines of By default, you can’t send anything to these kinds of addresses without some additional footwork.

A good guide on how these types of emails work can be found here and instructions on setting up apple accounts and relay services in order to send mails to privaterelay inboxes can be found here.

The guidelines also contain the line “Avoid asking for a personal email address when people supply a private relay address.” (see the end of this article for a few questions to our readers).

The user can select any first and last name, and the last name field can actually be empty — so have another look at all fields in your app where these data are used.

And lest we forget, of course, to add Apple ID, first and last name, and email to our PII and GDPR procedures (we trust of course you have them in place, right?).

We’re all likely going to have to tinker about with client_secret. We describe how to generate it in detail here.

Just try to rotate the apple or adjust the margin just a bit — immediate ban.

The design specs can be found here —

Things to note:

● You can’t just use a logo as a button

● The logo height must match the button height

● You can’t clip or cut the logo

● You can’t add vertical padding

● You can’t customize the logo color

● You can only use system fonts

● The font size must be 43% of the button’s height

We have included an example and some questions for our readers at the end of this article.

You can add a sign-on via apple for web platforms and even Android apps using JavaScript API.

Questions to the Experts

Will Appstore verification allow a button like the one below?

All other buttons in our apps have similar buttons, and therefore a flat button made per the guidelines would appear a bit out of place.

Say a user had an app account and we took the user’s name and email from his Facebook account (Facebook clearly asks for this and users give their consent). Now, this user has linked it to his Apple Sign in, where he used a different name and used the “hide my email” option.

What data should you show in the app in this case — Facebook or Apple?

So now we’ve made SIWA — how can we be sure that everything has been done by the guidelines and our app will clear the Appstore verification after 30 June (or to confirm this already at this point?)

Maybe there are some official representatives lurking about here?


Hopefully, this news was little more than a note from Captain Obvious and you’ve already implemented SIWA long ago.

And if not… no worries — you still have 2 or so sprints to go!

How to Plan a Winning Product Strategy

A No-BS Localization Strategy For Your App

Author — Alexander Zinchuk, product manager. Translated and published in the Alconost Inc. blog with the author’s permission.

We localize apps, games, websites, & software and provide video production, multilingual marketing, & instant translation services. Visit us at