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…
Yes! Especially once you start juggling multiple accounts for different companies and projects. Becomes a guessing game, and each wrong guess creates another account magically. Infuriating
Why we won’t be supporting Sign in with Apple
171–180 of 485 posts
Re: Why we won’t be supporting Sign in with Apple
#172Earlier quoted context omitted.
> Since you know this to be the case, why not have an onboard if flow they Sign In with Apple where you have them A) choose a visibility email used for sharing/communication etc. and B) allow for this email to be their backup email? So if they forget their login or whatever you could just transfer the account to this email instead? I'm fairly certain that detecting someone hiding their e-mail from you and then making…
> making them pick a different e-mail I think it's more about _letting_ them pick a different email. While I can understand that AnyList (or any other app for that matter) would want to, on occasion, send marketing emails to users, I don't think any app would, in their right mind, _require_ the user to provide a 2nd email address. But by allowing them to optionally give that 2nd address, they can provide a path forwa…
I am not an AnyList user but do they ask when signing up if users would like to opt in to such marketing messages? It’s become such a pet peeve buying something from an online purveyor and not even having the choice to opt in or not on marketing emails and any other form of communication I did not explicitly ask for beyond completing a purchase.
seems like another reason for progressive consent and ASKING your users how they would like to be contacted and honoring those preferences
Re: Why we won’t be supporting Sign in with Apple
#173As 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…
That section of the post was surprising. If they're not supporting Sign in with Apple, then obviously they're going to remove support for all other third-party sign-ons, because those third-party sign-ons are what trigger the obligation to support Sign in with Apple.
Ending their post about "why we won't be supporting Sign in with Apple" with a note that they're also ending Sign in with Facebook on the merits of third-party sign-in is quite disingenuous. It doesn't matter at all what they think about the merits of Sign in with Facebook; those thoughts are completely irrelevant to their decision.
Re: Why we won’t be supporting Sign in with Apple
#174This 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. T…
The assumption both you and AnyList are making is that an email is "THE obvious choice". From a user experience perspective perhaps this "global sharing identifier" should be defined by them.
You'll notice that different generations have different online behaviors. For some, email is their main id. For others, it's their phone number (they don't know most of their friends' e-mail, but know their phone). For others, it's either online handles or nothing at all - think about the device set up for grandma with her daily To Do list.
Of course, having this approach would add some upfront dev work to them but allow them to navigate this much easier later on. And for anyone starting to develop their new app/site/product thinking about this early on can reduce a lot of future headaches.
Re: Why we won’t be supporting Sign in with Apple
#175Is this really true? I've had Apple IDs for pretty much as long as they've existed, but I've never had an iCloud email. Any email address can be an Apple ID.
(...in fact, early on, it didn't even have to be an email address. I still have one of those old-style Apple IDs.)
Re: Why we won’t be supporting Sign in with Apple
#176Earlier quoted context omitted.
Yes! Especially once you start juggling multiple accounts for different companies and projects. Becomes a guessing game, and each wrong guess creates another account magically. Infuriating
Time to create a new service to unify all your SSO accounts! One single SSO!
Of course, there may be competing SSSO solutions...
Re: Why we won’t be supporting Sign in with Apple
#177Earlier quoted context omitted.
Yes! Especially once you start juggling multiple accounts for different companies and projects. Becomes a guessing game, and each wrong guess creates another account magically. Infuriating
Time to create a new service to unify all your SSO accounts! One single SSO!
Re: Why we won’t be supporting Sign in with Apple
#178Earlier quoted context omitted.
> "Apple reserves the right to disable Sign in with Apple on a website or app for any reason at any time." I think GP is absolutely right here. Apple can take the customers at any time for any reason . Apple could ban you from using Sign in with Apple simply because Tim Cook doesn't like what food you eat for breakfast. So, I have to agree with GP that these are Apple's customers at this point.
The check on this is that you are now putting an inconvenience on that apps users. Maybe it’s okay in some isolated circumstance however, I imagine this won’t sit well if it becomes a reoccurring theme for iOS users, as they will come to view Sign In With Apple as unstable/unsafe (like Google and it’s graveyard). It would quickly render Sign In With Apple useless if the trust that it will continue to work whenever us…
That hasn't stopped Apple from remove apps or preventing updates -- clearly inconveniences on users -- for whatever reasons they want. It has happened and it will happen again.
There is no check on this unless your app's audience is Netflix/Spotify/Facebook huge. If you're just an average developer you can be killed off at any time.
Re: Why we won’t be supporting Sign in with Apple
#179Earlier 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.
I don't want to share my spam email with all my friends to get them to share with me. And I don't want to give my primary email to an app that will spam me.
If I want to share something, I'll send a link and the recipient can connect to me that way. I don't need to search them within the app to get in contact, that's useless.
> so when they enter your email address, our systems will believe that you don’t have an account. At that point, you’ll get an email from us asking you to create an account.
This is a trivial part of the problem to solve. Why am I being asked to create an account in an invite email? Why not "log in or create account" and having the link itself be the piece that connects the share to me.
Re: Why we won’t be supporting Sign in with Apple
#180> Another issue is Sign in with Apple’s “Hide My Email” feature. With this feature, if you create an account with us, Apple will generate a special email address just for that account. So rather than your email address being john.doe@icloud.com, we will see your email address as something like dpdcnf87nu@privaterelay.appleid.com. Ironically, this is also why I use Sign Up with Apple at every opportunity I can