At the 2019 Worldwide Developers Conference (WWDC), Apple introduced Sign In with Apple for iOS 13. It’s a great service offering centralized authentication without reducing privacy for users, but it’s not without some drawbacks.
AnyList has decided not to support Sign In with Apple (link via The Loop):
Starting June 30th, Apple will be enforcing a new rule in the App Store requiring many apps to support Sign in with Apple. AnyList is one of the apps affected by this new rule, which means that we must either implement Sign in with Apple or make other changes to our app. After considering the merits of Sign in with Apple, we have decided not to support it. We understand that this may surprise some of our customers, so we’d like to explain in detail why we made this decision.
Why AnyList won’t be supporting sign in with Apple. (2020, June 29). AnyList Blog. https://blog.anylist.com/2020/06/sign-in-with-apple/
Here’s the relevant rule:
4.8 Sign in with Apple
Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user’s primary account with the app must also offer Sign in with Apple as an equivalent option. A user’s primary account is the account they establish with your app for the purposes of identifying themselves, signing in, and accessing your features and associated services.
App store review guidelines. (2020, March 4). Apple Developer. https://developer.apple.com/app-store/review/guidelines/
AnyList supported Facebook Login, so they had to make changes to comply with rule 4.8. But rather than add Sign In with Apple, they took a step back. This gave AnyList a good chance to review what they were doing and re-focus on what was important to them. That didn’t include Sign In with Apple or Facebook Login.
I work on an app called BeLooped. BeLooped doesn’t support any third-party login services. We’ve kept things simple. As such, rule 4.8 doesn’t impact us. We don’t need to make any changes to comply. A lot of apps out there are going to be in the same position.
BeLooped runs on both iOS and Android, and users can switch between them while keeping their data. We need something that works for both iOS and Android users.
We could use Sign In with Apple, because it does work on Android. As Apple describes it:
Sign in with Apple works natively on iOS, macOS, tvOS, and watchOS. And it works in any browser, which means you can deploy it on your website and in versions of your apps running on other platforms.
Sign in with Apple. (n.d.). Apple Developer. https://developer.apple.com/sign-in-with-apple/
We decided not to do this, though.
There’s a few reasons:
- It seems weird to do this on Android.
Yes, we can do Sign In with Apple on Android. I’m less sure Android users would like this showing up in their app. Some Android users can be really prickly about connections to Apple. If we include Sign In with Apple only on iOS, it means anyone who moves to Android is going to have a hard time keeping their data. - Where does it end?
Sign In with Apple is one thing, but what if Google adopts a similar rule and we’re required to support Google Sign-In? Can we guarantee the privacy of that? What if users start demanding sign in with Facebook or Twitter? - We’re not really in the business of sharing anything without user consent.
Users can already share as much or as little as they want about themselves with groups (including sharing different or less data with different groups). Not only do you not have to share your email address with groups you’re in, you don’t even have to share your name.
There’s other reasons, too, why we prefer to keep BeLooped logins limited to email addresses which I might get to in the future. (This isn’t meant to be a BeLooped blog, but it’s definitely something I’ll talk about from time to time.) I’m not prepared to say “never,” but for now I’m not interested in adding any third-party logins.