Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we won’t be supporting Sign in with Apple

blog.anylist.com

Post reply on HN
Print view View original

141–150 of 485 posts

Re: Why we won’t be supporting Sign in with Apple

#141

Post by scarface74 »

kinkrtyavimoodh wrote: post #134
scarface74 wrote: post #107

Earlier quoted context omitted.

It’s not any transaction. It’s any digital transaction. You can sell physical goods and services either without giving Apple any cut, or by using Apple Pay and Apple just gets your standard credit card processing fee. Does Walmart let you sell your product in their store and say you can look at it there but get it cheaper from Amazon?

My app is not the App Store. The user has already paid to download my app from the App Store and Apple has gotten 30% of the cut. What users do on my App after that is none of Apple's business, though of course Apple would like to claim otherwise. Similarly, once I have bought something from Walmart I can use it as I wish. Our business transaction ends there, so your analogy isn't really apt. > Does Walmart let you s…

Funny you say that, because Walmart and many other brick-and-mortal retailers will happily price-match Amazon and each other. You know why? Because they are not a monopoly or pseudo-monopoly and so need to do good by their users to compete.

Many stores get around that by having special SKUs that are only available in their store.

Also, Android has a slightly larger share in the US and a much larger share worldwide. Apple is no more of a “monopoly” than the console makers.

Re: Why we won’t be supporting Sign in with Apple

#142

Post by dukoid »

persona wrote: post #139

This seems to be a common problem, made more visible when using third-party authentication, that your application has taken the concepts of "Account" and "Authentication Method" as if they were the same thing. It appears that the "account ID", "preferred contact method+address" and "authentication ID" are all the same here - which then creates the "account management code into a rat’s nest" scenario they describe in…

+1 Any authentication method that I have enabled for my email should work -- there shouldn't be a need to remember which one is associated with a particular service...

Re: Why we won’t be supporting Sign in with Apple

#143

Post by dahfizz »

WorldMaker wrote: post #112

> Furthermore, if there are platforms where AnyList doesn’t support Sign in with Apple, like Android, and someone wants to log into their account, they’d have to know their privaterelay.appleid.com email address. (And that certainly won’t be easy to find if you no longer have an iOS device.) And then they’d have to create a password with us, since they wouldn’t be able to sign in using Sign in with Apple. The easy an…

They directly address this point. In the article they say they considered adding sign in with Apple everywhere. Besides the fact that it's more code to write and test, they say the documentation is very poor for other platforms, as it's not even great for iOS.

Re: Why we won’t be supporting Sign in with Apple

#144

Post by fiddlerwoaroof »

It’s pretty user-hostile to refuse to support the authentication provider the user wants to use. If I’m already in the Apple ecosystem, using Sign In with Apple, a service that doesn’t implement Sign In with Apple but could is preventing me from doing what I want, just as much as Walmart not accepting Apple Pay.

Re: Why we won’t be supporting Sign in with Apple

#145

Post by WorldMaker »

tech-historian wrote: post #120
WorldMaker wrote: post #112

> Furthermore, if there are platforms where AnyList doesn’t support Sign in with Apple, like Android, and someone wants to log into their account, they’d have to know their privaterelay.appleid.com email address. (And that certainly won’t be easy to find if you no longer have an iOS device.) And then they’d have to create a password with us, since they wouldn’t be able to sign in using Sign in with Apple. The easy an…

Sure, except there is no documentation for it. From the article: "For example, Apple vaguely states that you can implement Sign in with Apple on Android, but there is no direct documentation on how to do it. We understand that Apple probably doesn’t care much for Android, but if they are going to provide a login system, and are going to force developers of multi-platform apps to adopt it, then providing no real suppo…

Apple has provided documentation, it seems like the article describes a lack of attempt at trying?

On the Getting Started [1] page it lists three options: Apple platforms [use AuthenticationServices], Unity [use the asset from the Unity Asset Store], and "Web and Other Platforms" [use Apple JS/REST]. That "Web and Other Platforms" link provides a wealth of useful documentation [2].

Tbf, the exact word "Android" is missing, but this is an elementary school-level process of elimination that maybe Android is inferred in the words "other platforms".

[1] https://developer.apple.com/sign-in-with-apple/get-started/

[2] https://developer.apple.com/documentation/sign_in_with_apple...

Re: Why we won’t be supporting Sign in with Apple

#146

Post by danpalmer »

Another issue with Sign in with Apple is the fact that their private relay has a pre-set allow-list per app for sending email to relay addresses.

This means that you must either prove ownership of domains, or pre-add email addresses to Apple's systems. I understand why they have done this, it will reduce spam considerably, but the private relay system is already designed to empower users to do this and this extra step may be impossible for some developers.

Take for example a retailer – they need to dispatch goods and use different carriers in different countries. When the user buys something they very likely want email notifications about delivery, a feature that most carriers provide. For the carriers to send those notification emails you'll need to pre-add them all to Apple's systems. You can't prove domain ownership because fedex.com isn't your domain, but where are those emails going to come from? Better hope your carrier doesn't change sending address at some point or the email goes into a black hole.

Apple also limits the number of domains and addresses you can send from. In the original documentation it was "10 domains and addresses" (not sure if 10 of each, or 10 total). This was raised to 100 I believe, but that's still probably an issue for larger multi-national companies, or those who necessarily have to integrate with many external services.

The really hard-line privacy stance is that the retailer shouldn't share the emails and should do the notifications themselves, but for many this is prohibitively difficult to do, or at least detracts from places where the retailer can actually add value. The benefits are also very small, as the contracts with carriers typically protect user data, require deletion quickly after delivery, and retain most privacy benefits while allowing for a good UX.

Re: Why we won’t be supporting Sign in with Apple

#147

Post by WorldMaker »

dahfizz wrote: post #143
WorldMaker wrote: post #112

> Furthermore, if there are platforms where AnyList doesn’t support Sign in with Apple, like Android, and someone wants to log into their account, they’d have to know their privaterelay.appleid.com email address. (And that certainly won’t be easy to find if you no longer have an iOS device.) And then they’d have to create a password with us, since they wouldn’t be able to sign in using Sign in with Apple. The easy an…

They directly address this point. In the article they say they considered adding sign in with Apple everywhere. Besides the fact that it's more code to write and test, they say the documentation is very poor for other platforms, as it's not even great for iOS.

It seems sufficient to me?

https://developer.apple.com/documentation/sign_in_with_apple...

Re: Why we won’t be supporting Sign in with Apple

#148

Post by lstamour »

tech-historian wrote: post #120
WorldMaker wrote: post #112

> Furthermore, if there are platforms where AnyList doesn’t support Sign in with Apple, like Android, and someone wants to log into their account, they’d have to know their privaterelay.appleid.com email address. (And that certainly won’t be easy to find if you no longer have an iOS device.) And then they’d have to create a password with us, since they wouldn’t be able to sign in using Sign in with Apple. The easy an…

Sure, except there is no documentation for it. From the article: "For example, Apple vaguely states that you can implement Sign in with Apple on Android, but there is no direct documentation on how to do it. We understand that Apple probably doesn’t care much for Android, but if they are going to provide a login system, and are going to force developers of multi-platform apps to adopt it, then providing no real suppo…

https://developer.apple.com/documentation/sign_in_with_apple... is more “direct” than most of the documentation I’ve seen on how to implement “OAuth” with other providers. (Trying to figure out how to integrate with “Microsoft 365” is particularly painful...)

Eventually you might realize it’s based on an open standard https://openid.net/2019/09/30/apple-successfully-implements-... and that it’s relatively similar to other such standards, except with the option to mask your email, etc.

As an geeky end user, the only way I trust these services for login is if I can link more than one, or even more than one email from the same provider. That way I know I’ll have a backup in case I lose access to the social network or email address that I signed in with... it’s annoying when I can’t add a password or set an email just because I also want to login without a password sometimes...

Re: Why we won’t be supporting Sign in with Apple

#149

Post by WorldMaker »

tech-historian wrote: post #136
WorldMaker wrote: post #105

Earlier quoted context omitted.

Sign-In with Apple is a (mostly) standard OpenID Connect provider that works everywhere (and works just like sign in with FB, Google, et al from a technical implementation), including the Web and Android. It's an interesting miscommunication or misunderstanding (and I was not surprised to see it in this article) that applications and developers think the "Sign in with Apple" button should only show up on Apple device…

If you read the article, you'd see they address the reason they cannot implement it on Android yet. Apple hasn't provided documentation for it. Apple doesn't seem to be taking it seriously.

To keep my reply in a single place: https://news.ycombinator.com/item?id=23684452
Post reply on HN