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

151–160 of 485 posts

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

#151

Post by forrestthewoods »

WorldMaker wrote: post #105
forrestthewoods wrote: post #92

> 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. I’m an avid…

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 I’m on Windows and see Sign-in with Apple how am I supposed to sign in? By typing in a generated email address? It’d not that it can’t work, it’s that it’s a miserable user experience.

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

#153

Post by dahfizz »

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…

I feel like they address this in the article. What you say makes sense in a technical UML diagram point of view, but that's not how people work.

The examples they give are getting support and sharing things with another person with an account. As a user, both of those things are easier for me if there is an email associated with the account.

Said another way, the Account needs some human friendly global identifier. The email you use to log in is an obvious choice, and anything else would require extra work from the user to set up. You could have usernames, for example, but that complicates the signup process and still makes sharing things hard. I know my friends emails already, but I don't know what username they ended up with on this site.

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

#154

Post by ummonk »

lstamour wrote: post #148
tech-historian wrote: post #120

Earlier quoted context omitted.

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…

Wow you're not kidding that's actually surprisingly clear documentation and it should be very easy to implement.

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

#156

Post by mr_toad »

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…

I don’t see any technical reason this couldn’t be done, but it would be more work for both the app developers and the user.

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

#157

Post by crazygringo »

As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well.

So there's nothing specifically against Apple, despite the title seeming to imply it -- just that they're taking the move right now because of Apple's new policy coming into effect.

I've got to say, I really wish there were a way to know whether I already used Facebook, Google, or Apple to log into a site or app before. My password manager is usually pretty good at letting me know if I've got a "normal" account with user/password, but it doesn't do anything to remind me if I ought to log in with one of the other services.

Every time I'm occasionally asked to sign into Spotify, Pinterest, Medium, Quora, etc. -- it's like, I'm pretty sure I've signed up with something before, but who even knows which one, or multiple?

If password managers could start saving that you've got accounts associated with Apple/Facebook/Google and highlight the relevant button on sign-in, it would be a big feature improvement.

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

#158

Post by swagonomixxx »

renewiltord wrote: post #125
swagonomixxx wrote: post #102

Earlier quoted context omitted.

The anonymous e-mail that Sign-In with Apple generates forwards to the e-mail used to set up your Apple ID. So it's not like it's a random e-mail that acts as a /dev/null. This is by far the biggest selling point of Sign-In with Apple for me and I will continue to use it, and continue to not use apps that don't support it. I have plenty of e-mail aliases, but having an alias auto-generated for you is very convenient,…

Perhaps you don't use AnyList? It doesn't make sense to use with a private mail relay because they use email as an addressing system. And honestly, few users will go look up their per-app address and tell people to add them.

Ah, I wasn't aware that e-mail was used as an addressing system within AnyList. Do users not have any usernames associated with their e-mails?

Still, I think in this day and age, having a requirement in your product that says "e-mail that is provided should be the one the user uses the most" is pretty naive. In general, it's true, but when it comes to 3rd party authentication providers like Facebook, Google, and now Apple, this kind of requirement is not really useful and will likely cause issues for you down the line, which is why usernames are better for addressing people within apps (e.g, Instagram handles).

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

#159

Post by TheSpiceIsLife »

crazygringo wrote: post #157

As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well. So there's nothing specifically against Apple, despite the title seeming to imply it -- just that they're taking the move right now because of Apple's new policy coming into effect. I've got to say, I really wish there were a way to know whether I already used Facebook, Google, or Apple t…

This happened to me recently where, in a hurry and distracted, I logged in with one or another third party auth service then realised that wasn’t the correct login as it displayed a new account.
Post reply on HN