yeah turns out Dynadot enforces a 7 day wait on deleting the domain and it's only been 6 days. should be free for registration on June 18 (i assume in 3 hrs if they mean UTC)
It's strange to hear the author isn't a fan of cryptocurrency. There are a lot of dubious use-cases for crypto, but facilitating donations for sketchy services is an obvious one.
- 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 other third-party account directly to access their content.
There's an additional point above that which is more important:
> 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.
You only have to offer "Sign in with Apple" if you already have third-party login options. It would be completely unreasonable to require adding a third-party login option if you don't already have one. But if you already have third-party login options, having uniformity seems reasonable.
> It would be completely unreasonable to require adding a third-party login option if you don't already have one. But if you already have third-party login options, having uniformity seems reasonable.
What if they required the same thing on websites by having their browser engine look for Facebook/Google sign ins and require an Apple one be present before displaying the page?
Not explicitly as you implied. But implicitly it is required. Let me explain.
You own a service that has social authentication with Google, Facebook, Twitter, etc.. You have web, desktop, and mobile apps for this service (or some combination thereof).
Your iOS app now requires you to offer "Sign in with Apple" as an auth provider, because you already offer Google, Facebook, Twitter, etc.. So you add "Sign in With Apple" to your iOS app because Apple requires because of their monopoly for distribution on iOS devices. So you now add Apple auth as an authentication option within the iOS app.
Now what happens if a user signs up in your iOS app with Apple's Auth? How are they going to log in on your website, desktop, Browser extension, or anything else? Well, I guess you now need to add "Sign in with Apple" on those devices too.
Once you offer an auth provider as an option on one device, it must now be offered throughout your platform on all devices or you risk locking users out.
Thus, if you offer social auth for authentication, and you want distribution on at least one iOS device, you are implicitly required to offer Apple Authentication across your entire platform.
And that is the power of Apple's distribution monopoly on iOS.
Oh, and before you think "well we will just boycott iOS" for my platform. Good luck. You won't get very far (in the US at least) without iOS support if you are just starting. Even an established company would struggle to succeed without iOS support. Imagine if Uber just said "Fuck it, no more iOS app". All their iOS users would say "Fuck it, no more Uber then, Lyft here I come".
> Once you offer an auth provider as an option on one device, it must now be offered throughout your platform on all devices or you risk locking users out.
Is it feasible to not do this, and instead tell users to add any one of the existing auth methods to their account in addition to Apple's, if they want to use the app on another OS?
What’s frustrating about this change is that Apple keeps changing the terms on it. Until last week the T&C’s included the phrase “exclusively”. This allowed you to provide the user with your own sign in system and avoid forcing the google/facebook lock-in, however removing this crucial word means for those of us with apps in the market with social logins, we have to add yet another one.
This is going to lock more users to iOS, and doesn’t allow users on popular apps to migrate to Android and maintain their login. (Note no Android SDK is provided)
It might technically not be antitrust, but as an app developer we’re now forced to include Apple sign-in.
Isn't it? It should be. You're forcing developers to add your sign-in method everywhere... they can't add it on Android. You're essentially forcing sub-par android support.
AWS is great about dogfooding, most all their services run on top of native AWS (ec2, lambda, dynamo)... but they don't do that for billing. It's all just fake money being thrown around internally.
