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

241–250 of 485 posts

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

#241

Post by habosa »

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…

I worked on a product that can do that (Google Smartlock for Passwords) but these “identity provider” hints were extremely confusing to both users and developers. The UX definitely could have been better but overall I just don’t think it works.

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

#242

Post by ramraj07 »

alister wrote: post #240

> Apple reserves the right to disable Sign in with Apple on a website or app for any reason at any time. Holy cow, how is this acceptable to any app developer or software company? This is reason enough for me to never use Apple/Facebook/Google sign-on as a developer -- huh, or even as a user. Apple/Facebook/Google could lock out all your users and literally destroy your business in a split second for an arbitrary pol…

This seems like the only bummer rule of all. I really would like to use this service on my next project but this dictator rule cannot be tolerated.

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

#243

Post by tomklein »

grishka wrote: post #211
sequoia wrote: post #192

Earlier quoted context omitted.

Because you can frequently avoid account creation, setting a new password etc if you click “sign in with google.” It’s a tradeoff but if you don’t see any value in it you maybe haven’t used it- it’s convenient.

Also there are services that log you out after some time. You aren't doing anything wrong, you're simply using the service, but at some point you open it and see a login form. Now, I don't understand why do sessions have to have a lifetime at all, this is terrible UX, but clicking one button to log back in instead of actually typing stuff on the keyboard is much more convenient.

I guess a lot of times it’s for security or to minimize storage over time. Sometimes you are only logged in for the browser session, so if you close it, it removes your session. Most smaller sites do have the remember me button to opt in for longer sessions and do not implement a session renew feature.

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

#244

Post by jbarches »

stickfigure wrote: post #43
djrogers wrote: post #16

Earlier quoted context omitted.

How is that different from FB/Google's login services? The only apps that are required to support Sign in with Apple are those that also support FB/G/etc sign in, so those companies have already chosen a path...

Google provides an email address. You could replace your Google auth with password auth in an afternoon just by adding a "forgot your password" link. Facebook auth used to provide an email address, but it's been almost a decade since I last used their APIs so I don't know if that has changed. Apple's "provide an anonymous email address" inserts them between you and your customer.

Facebook does not guarantee an email address, either. (Just went through this process with Apple/Google/Facebook/Email auth - even using Firebase Auth library - surprising how many edge cases there were).

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

#245

Post by nexuist »

alister wrote: post #240

> Apple reserves the right to disable Sign in with Apple on a website or app for any reason at any time. Holy cow, how is this acceptable to any app developer or software company? This is reason enough for me to never use Apple/Facebook/Google sign-on as a developer -- huh, or even as a user. Apple/Facebook/Google could lock out all your users and literally destroy your business in a split second for an arbitrary pol…

You know the reason. It's on the front page of HN today even. Apple will support Sign in with Apple until it is co-opted by "white nationalists" or other scary characters, at which point they will disassociate with that website or app and prevent their services from working with them.

Which is their right of course, but at the end of the day it means we get changes like these in the fine print. Gatekeepers like Apple and Google gain more control over what is allowed on their platforms, and subsequently what is allowed for the majority of the population to see.

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

#246

Post by AnonC »

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…

Not agreeing with what are arbitrary rules on the App Store and with the percentage that Apple takes as a cut, but this paragraph opens up many issues with running a platform:

> 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.

If the App Store runs the way you describe, then everybody would offer their apps for free to avoid the 30% cut and also not have any in-app purchases (since those also have a cut). The result would be the user installing the app and having to go to a website (even if it’s embedded in the app in a web view) to create yet another account, finish the signup process, go through a separate (and usually lengthy) payment process to actually buy the app and managing those payments in cases where those are subscriptions.

One can argue on the merits and demerits of Apple’s current system (which needs an overhaul, IMO), but the other option isn’t without demerits as far as users and user experience are concerned.

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

#247

Post by dwaite »

danudey wrote: post #14
no_wizard wrote: post #12

A lot of the points they make here are real points, and I think AnyList has validity in their actions. I also think it’s not as unmanageable as it seems. Let’s analyze this quote, from the article, as it highlights what I imagine are a big crux of this issue: > with the “Hide My Email” option, your spouse or friends obviously won’t know your privaterelay.appleid.com email address, so when they enter your email addres…

> 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…

You don't have to ask for the email at all, if you don't want to. Pinterest apparently does not, so for them SIWA is just an authenticator.

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

#248

Post by Thorrez »

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…

> all their arguments apply to all third-party sign-ons

What about the argument that users check their gmail addresses regularly but rarely check their icloud email addresses?

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

#249

Post by dwaite »

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…

> 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.

It seems like you are the one who would like to claim otherwise, since to get your app in the store you have already agreed both to the terms of the developer program and to follow Apple's guidelines.

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

#250

Post by nikitaga »

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…

With rare specialized exceptions, pretty much nobody needs all this complexity. Certainly not a simple app like AnyList. All this flexibility is not free, it comes at the cost of obviousness, as they described. It's not worth it much of the time.

The real problem is Apple shoving their proprietary, poorly designed services down everyone's throats.

No, I don't want to use icloud email, I already have an email address. No, I don't want to provide a "real" email address after I provided an obfuscated one. No it's not my fault that messages sent to the obfuscated one will go to some icloud inbox that I didn't create and I don't read. No, it's also not my fault that when I contact support I do it from my normal email address and not from the obfuscated one (how would I even do that). It's not the support's fault that they can't connect the two.

It's not the user's fault, and it's not the developer's fault. Apple is the sole designer of this mess. There is no excuse.

Post reply on HN