There's a subtle sense of exuberance shining through in this article that makes it a gratifying read, even if you've never heard of the company before. Kudos to them for their decision not to bow to Apple's demands. Please tell us how it goes!
Apple "demanded" companies either add their privacy friendly sign in option, or give up on the data-slurping Facebook google sign-ups. This company gave up FB sign in, which they acknowledge is pretty gross and bloated.
Worth noting that AnyList automatically subscribed me to a marketing list without double opt-in or any kind of consent, which is exactly the kind of behaviour that makes me not want apps to have my real email address.
They mention customer support so many times in that article, but it's a grocery list app! When is the last time I asked for support for the sticky note attached to my refrigerator? I don't doubt that there are indeed customers who need support from time to time, but surely it's a small minority.
These seem to just be contrived arguments to protect their customer data selling bottom line.
Yep, my feelings exactly after reading.
All this whining happens only when your business is very dependent on specific information that gets taken from you.
Using Gmail at all seems to have the same effect as well since they pre-load and proxy almost all email content. Only when you use alternative mail clients might they see the images/remote content being loaded from a non-google IP.
The blog post was long and winded. And it brought up some very desperate arguments, like the bug bounty offered to hackers when they report security vulnerabilities.
They want people's email addresses, period.
They say that no email breaks the sharing feature. True. But that's something that can be offered later when someone actually does share something with you. They say that the emails will go to the a seldom checked account. True. But users can change email addresses. They say it breaks support service for looking up accounts without email addresses. Again true. But what's another way of looking up accounts? Username. What is another? Apple ID.
They are email network harvesters. Plain and simple. And this is their business model.
The article says "When you provide us with your email address, it is never sold, shared, or used to invade your privacy." So, one of you is lying. I don't have the means to determine who, but I don't see what your motivation for lying would be, but can see what theirs may be.
And to extend that, if they are a spammy company, that would be exactly why they would be complaining about SIWAI.
That's exactly what I'm thinking! Further I can't find the EULA of the app on the internet - maybe I'll find it later. But I could bet that they sell the data for marketing purposes. And I could also bet that they removed Facebook not because they don't want to use it but because they had to implement Sign in with Apple which would result in the Data being not so valuable because the standard option is to obfuscate the mail address.
This makes perfect sense from their standpoint - especially since they've had similar problems to what they outline with Facebook sign-in and are now dropping that as well. This is also a win for Apple & end-user privacy, as there's one less app using FB's login feature now.
I think Sign in with Apple is a great step forward even if all it does is eliminate apps that require Facebook and/or Google accounts to log in. I hate that - I actually ran into a feature on my mesh router system that required a FB/G login, which made it a useless feature for me. Fortunately I didn't need it..
Lucky you! I've run into lot of these apps offering only FB/Google sign in. Or offering mobile number only login.
For e.g. I like playing scrabble and Scrabble Go only support FB login so I'm playing only as Guest user for months now.
Mobile number login is even worse! Why do I need to share my mobile number for something where you don't need to have it!
I think a lot of services use mobile number login as a way of bot-limiting; harder to create lots of phony email addresses than phone numbers. But it's still a pain in the butt :(
Mobile number login is common for apps from China as large number of Internet user there only have a mobile phone, no desktop and no email. Its the only way to verify account.
CalTopo[0] doesn't support email+password. It's one of the few websites I use that doesn't support it, but an unfortunate number of mobile apps don't either.
https://tailscale.com/ requires it, as do many other apps that explicitly "don't want to become identity providers and would rather offload that burden to someone else".
Yup, FWIW I think their selection is great, I was just using them as an example of a company that chose not to provide any in-house email+password option.
Pokemon Go's account own doesn't work. Even if you manage to create that account, it won't log you in. With Google account it works as expected. I tried to create two Pokemon Go accounts, gave up and created a Pokemon Go only Google account for child's playing. It has worked a few years.
When did you have this issue? My account is tied to my Google account because on launch the Go servers were completely inundated and the account creation was just constantly failing but using a Google account allowed you to skip that step and start playing.
This was the first month of Pokemon Go years ago. I haven't heard of it being an issue lately but I also haven't needed to create an account in a very long time.
I think the first time was around the spring 2017. I could create an account, use the credentials to log in, but trying on several days the game never started. There was some "please wait" kind of screen and waiting for hours didn't help. With a Google account things worked right away.
And a bit over a year the same thing happened. New Pokemon Go account -> log in -> no game. With Google account has been working since.
So, my experience is two tries in the span of two years it did not work.
Pokemon Trainer Club accounts (what you thing of as "Pokémon Go accounts", even though they're used for other Pokémon services) in the past were more buggy than Google accounts, but for at least the past two years I have had no more trouble with my account than my friends who have Google accounts. Additionally, they created a feature where you can link Google/FB to your PTC login so if it does go down in the future you can log in with those other services if you wish.
Yep, that in specific made me hold off on deleting my Facebook for a couple of years. About 2 years ago I noticed you could just click ‘forgot password’ and unbind them.
I’ve gotten rid of Facebook, but now my account name is just a bunch of numbers.
For my last two companies (both B2B), I implemented login via Google accounts only. Google login has a number of advantages:
1) Identity is an email address. If I wanted to rip out Google, or Google kicked me off the platform, all I need to do is add passwords and put a "forgot my password" link and my customers continue business as usual.
2) It's not a google-specific email address. You can create Google accounts for any email address.
3) Google login effectively lets other businesses federate their auth system with ours. When they terminate their ex-employee's @example.com account, the employee loses access to their resources at my company.
I don't think you could get away with this for a consumer company; too many people have strong feelings about FB/G/Apple/whatever. But it's fantastic for B2B.
point 3 is only true for G Suite customers - if someone is on O365 and signs up for Google normally with their company account, they can access that email after their company turns off access to the email unless they also specifically reset the Google password.
#1 is only sort-of true. You can get access to their current email, yes, but the email can change and you should be keying by the Google account ID really.
I mean it can be better for privacy if you think about Google/Facebook loging. But it will prevent adding all third party login services, potentially even ones that are more privacy respecting than Apple.
Also there are cases where a "sign in with <particular provider>" is the only option that makes sense because you really want to integrate with the API of this provider. Take for example a "sign in with GitHub". Or in case of services correlated, take for example Instagram where you obviously can sign up with a Facebook account.
I'm more for letting the developer choose what it prefers for authenticating the user and not having a authentication system that gets imposed by Apple.
I think Apple does allow apps to limit social sign in options where it makes sense. So for example, an email app could have sign in with Google, Microsoft, and Yahoo! but not Apple.
I love it. With password managers becoming better and by owning your domain, it almost feels like a self-sovereign identity system. It would be great if services would implement better support for browser form auto-fill, and ask the minimum amount of information during signup. That way it would be very little hassle to signup for a service.
I'm going to be fascinated to see what this does for conversions. My company built the Neil Young Archives, when doing so we initially launched with Social log ins and at one point Neil decided Facebook and Google were evil and wanted to remove the access. According to our logs a full 2/3s of all users were registering with a social account and we were having great success getting folks to log into a free service (We had 250k sign ups over the first weekend, we thought Auth0 might turn us off as we started on a tier capped around 40k)
We assumed this success would quickly taper off if it wasn't "one click" to sign up with your Google/Faceboook account an talked Neil off the ledge.
This escenario seems an clear candidate for A/B testing since I would be conflicted by wanting to provide privacy but understanding it might impact user signups.
Seeing some actual numbers would help me in making that decision.
I don't disagree with you and it was proposed. However we didn't have A/B infrastructure in place then and on a project that may never make money it just wasn't a high enough priority to justify the spend.
Fair enough, sometimes you have to make a decision with what you have. A/B testing adds complexity and specially when doing contract/agency work you don’t have either the time nor the budget to pull it off. Been there myself.
Personally I would have considered to hack something on my own time just out of curiosity :D
A/B testing auth methods is tricky. It's fine for "can we get better sign up rates" but it wreaks havoc on "can my previous users still sign in". At best you can AU/NA test - show different pre-auth treatments in different, very distant geographies that nevertheless have roughly similar user characteristics.
I just gotta say I both love and hate the Neil Young archives. I hate them because the website is genuinely awful, and a chore to navigate around. However, I love that I have access to a load of stuff I haven't heard before.
At any rate, thanks for the hard work you put into it and I've used this site a lot.
Yeah we didn't design it. Just did the best we could to make it all work. The design is actually a bit of a legacy as the original version was actually an interactive blu-ray set[1]
I kind of ended up with a love hate thing as well, it breaks pretty much every responsive, UX, accessibility rule out there, but at the same time it was Neil's vision. It's at least somewhat intentional that you have to dig at it a bit.
All that being said my first meeting with Neil I told him "This won't work on mobile" and his exact words were "Fuck Mobile ..."
> Most people who are not complete internet plebs have a second email for things they dont trust.
The vast majority of people don’t have a second email for things they don’t trust. You’re living in a nerd-bubble, but the rest of the world is on the internet too.
That was an interesting read. Also, they close with...
"These are both excellent points, and it’s absolutely true that some of the arguments above apply to creating an account via Facebook. That’s why we’re also announcing that we’ll be removing the Facebook Login from AnyList."
I said "Apple takes many anti-competitive and consumer-hostile actions. They can freely get away with it, though, as they aren't a monopoly." I did not say this action was consumer-hostile.
So, forcing them to give users a choice is somehow equivalent to... forcing vendors to not give customers a competitors browser?
Ok sure. That seems totally the same. Not at all as ridiculous as the invented "monopoly of iOS" that people use to justify the claim Apple is abusing a monopoly position.
Next thing you'll complain Coca Cola is abusing its monopoly position on Coke.
If you implement Sign In With Apple, you don't have a relationship with your customers anymore. They're Apple's customers, and Apple can take them away at any time.
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...
When you use Apple's Sign In it flat out asks whether you want to use your real email or an anonymous one. The user is purposely says, "Hey, Apple get in the middle I don't trust these clowns."
HN... where people go to complain about both companies requiring access your email, and companies requiring you to be able to block other companies from access to your email. I don’t get it.
Exactly! Which is as it should be. Way too many websites take for granted that they can do anything with the email addresses provided, including sending spam by default or with no way of opting out. With Sign In with Apple, if they don’t get in my email, that’s because I don’t want them to have it. Then, their poor marketing practices are irrelevant, which actually makes me more likely to create an account on their website.
Not sure about Google auth, but I created a Spotify account with their FB login years ago. About 1.5 years ago I wanted to decouple them, but they have no way to do it. I had to create an entirely new account. Not sure if it's a technical limitation or just a case of Spotify not prioritizing it, but their support tech did relate to me that they had lots of those switches occurring at the time.
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).
It's good that you read Hey's blog post and are repeating it here, but it's not very accurate in this case.
Specifically, if you implement Sign In with Apple, then they are still your customers as much as ever, they just might choose to hide their information from you because they don't trust you, which means that the power in the relationship is transferred to the user instead of the app developer.
Except that in many cases the email address is an obfuscated one controlled by apple, so Apple really is a gatekeeper between the user and the service.
> "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 used is not there
I actually think this wouldn’t really happen in practice as consumers are quick to respond negatively to this behavior, so I’d be shocked if Apple actually did this without some darn good reason (I imagine it will also include removing said app)
> The check on this is that you are now putting an inconvenience on that apps users.
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.
I’m not exactly sticking up for Apple as much as I’m trying to demonstrate practical thresholds that would realistically limit this behavior. I don’t think Apple wants 100,000 upset customers let alone millions.
Hardware requirements for software is a decades old concept, and it’s true they deprecate and obsolete supported software and hardware on for older platforms, but it’s rare I’ve seen Apple taken a user hostile approach here within supported lifetimes though it has happened yes it is rare.
Their developer experience on the other hand does not see the same care and attention a lot (most even) of the time. That’s because, and I believe this strongly, Apple never wants 3rd party software to have platform influential power over them again, like Microsoft and Adobe did for decades. It’s sad but not unsurprising that their platforms can be very developer antagonistic if you don’t take their happy path (and sometimes even then). To them though, it doesn’t matter until it affects a large quadrant of the Apple consumer base and in some occasions yes not even then, but largely it’s the consumer who has the biggest voting block with Apple in terms of pressure on the platform, as I’ve watched it play it they never had a history particularly after the iPhone came out of having the best developer relations relative to say, Microsoft, who provides a very positive experience in comparison
It’s just not in their DNA because of the fear of having too powerful of vendors putting pressure on the platform that they otherwise control outright. When you look at their policies in this context they make a heck of a lot more sense (even if you don’t agree. I certainly do not always)
Congratulations, now all of your email goes to a single different email address; your tracking profile is now associated with randomstring@email instead of john.doe@email.
If you wanted something truly private you could create an account at a provider like Fastmail or ProtonMail and create an alias for each account (or just wildcard a custom domain until you need to send from an address). I doubt any tracking system is based on the domain in your email address... not yet, at least.
I don’t want to have a relationship with every app developer. If you want a relationship with your customers that you control, you are free not to implement any third party sign on and implement your own.
I do wonder, though, whether the requirement for Sign in with Apple is coming in a few years. As in, if you allow users to sign in with email/password, you must allow users to sign in with "sign in with apple". It might be more subtle, like suggested auto-fill to create a new account.
That sounds like a bridge too far even by Apple standards. I can get on board with "if you support Facebook, you have to support us as well", but not allowing any kind of escape hatch feels particularly scummy. At some point it's none of Apple's business how people sign up with my service.
I don't understand how "if you support Facebook, you have to support us as well" is ok. Only by holding the relationship between the user and the developer "hostage".
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 address, our systems will believe that you don’t have an account
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? Of course this should be opt-in but you can always Under good faith explain benefits there in.
It’s more work, but I don’t believe that it’s going to run issue with Apple and provides end users with flexibility.
Of course this may not be worth it, at all. This is just a consideration worth thinking about as an app developer
edit: Of course another alternative here is they just make users aware of what their sharing email is and allow users to optionally change that, if they want to. This most definitely wouldn’t run counter to this I’d think
> 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 them pick a different e-mail goes against the spirit, if not the rules, of Sign In with Apple.
That said, it would be extremely beneficial to pop up a screen saying "Hey, is this the e-mail you want to use for communications?" and let the user decide.
That said, removing third-party sign-in is also a fine solution, almost definitely a better one, and simplifies things immensely for everyone involved (assuming their sign-in form in the app supports saving passwords to the keychain).
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 forwards with people being able to use Sign In With Apple (of course, that means some users may opt out of marketing emails entirely by refusing to provide a 2nd address).
This does probably go against the spirit of the feature, but if it actually is against Apple's rules to be doing this (anyone know the answer to this?), then it would definitely veer on the side of user hostility on Apple's part, since I would expect many apps to be taking a stance similar to the one taken by AnyList here.
Progressive consent makes sense though: in starting out with an app that i have no previous trust relationship, "Hide my email" sounds like a good idea in a trial balloon. If after using the application it tells me that to better use its collaboration tools it would like me to consent in giving a more direct email address, I might change my mind given changes in trust relationship (I have been using this app for some time and I trust it more now) and/or greater context for why the app is interested in a more direct email address ("make collaboration easier").
It's not necessarily shady or user hostile when done right, and there are plenty of opportunity to add trust relationship building as a part of the consent process (links to privacy policies; details about marketing policies; etc).
It's also not that different from how many iOS applications (at least) are encouraged (in App Store best practices) to handle consent models for location tracking and notifications: ask the user as they become familiar with the application, not up front, and provide as much context as you can.
I like this approach. And giving users that progresive consent is smart. If I open your app and am greeted with "You need to give us your email to get the most out of our app" then I'll be upset as that is user hostile. But If I click a share button and am told "In order to make it easier for people to send you things, would you provide your email" and being able to dismiss that and continue to use the app and all of its features, I'll be significantly happier.
That said though, I don't see why the app couldnt just change their sharing model to an "invite link" based pattern. If I want to share something with a friend, why do I need to provide their private information to the app to do it? Why can't I generate an invite link and send that through my already established channels of communication? I don't think the "but your friends don't know your Apple privacy email" reason is very compelling. That might not work in their current system, but it is definitely not an insurmountable problem.
That's something that bugged me about the article because it sounds like they do fallback to an "invite link" pattern when they don't know an email address, but it sounds like they've spent most of their UX optimization work on flowing people most directly from invite links into "Create Account" that they don't trust users not to create new accounts on receiving an invite link. (Maybe just stop assuming that people receiving invite links don't already have accounts and instead better your UX flows for existing users?)
(ETA: They make an okay follow up point that someone accepting an invite link sent to a different email sends a signal that they could just go ahead and link that email address directly to the account, and don't see why you wouldn't just give them that email in the first place. But in addition to being a squicky privacy faux pas to automatically link any email to an account without direct user consent, there are plenty of reasons to send emails to an address only indirectly linked to a person and/or that a user would not feel comfortable directly linking to an account. It's a somewhat flimsy argument below the surface, I think.)
While I can understand that AnyList (or any other app for that matter) would want to, on occasion, send marketing emails to users
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
Do you know if this is allowed within the scope of Sign In with Apple policies? A company I work with is implementing Sign In with Apple and said they can't do this. Not sure if they're right or if this is their weird interpretation.
I couldn’t find anything in an admittedly shallow search of the requirements or documentation.
Of course another alternative here is they just make users aware of what their sharing email is and allow users to optionally change that, if they want to.
I think their perfectly valid to do what they’re doing but I also don’t buy into this being an overly complicated logistical hurdle either
In a perfect world people would share things with you without entering your private email address in other people's systems. I don't want to be in the database of whatever app or system my friends decided to join, nor I want to receive spam from these companies.
Many of the objections come from wanting to do things the old way, without privacy and responsible handling of private data.
> Many of the objections come from wanting to do things the old way, without privacy and responsible handling of private data.
No, they come from the fact that privacy comes at a cost. In this case, it's much harder to receive support, find your account if you lose it, and get proper communication. Everything is a trade off, and anyone who thinks the reason things have been done this way is only to scoop up as much data as possible is either brainwashed or naive. These changes are adding a whole new layer of complexity, which may be worth it in some cases, but in others it just is a net negative for the customer.
Can you elaborate on "private email address"? I'd be offended if someone were careless with a more intimate identifier like my personal cell phone number, but I've always considered arms-length interactions with businesses and institutions I'm not fully on board with to be the whole point of email.
I have a private email address and a catch all address for a variety of websites.
{app_name}@example.com goes to the same place, but it is easy for me to see if they sell/lose my email. And if it gets lost I'm done with them I can just block that specific address.
The added benefit is no one can assume that {my_name}@example.com is my bank email address or my email login.
I used to have a standard {username}@gmail.com for a while, but now it is on 20+ breached site lists. Best case? Copious amounts of spam. Worst case? I may have been reusing a password prior to switching to a password manager.
Now, I can just block the email from receiving anything. Two, if I accidentally reuse a password the username is at least different.
I wonder if Apple would be ok with asking them to give up their email?
Apple clearly likes the idea of the hide option... personally I would expect a less than positive reception from Apple.
I get where both AnyList (if they asked) and Apple (if they didn't like it) would be coming from here.
It does seem to be a shortcoming here where outside of a user one time sign up situation... you don't want to have to burden the user with coming up with silly names and codes to use social like features that require someone else knowing an identifier for you that isn't email.
I don't want to go back to a time where we have to remember / pass along everyone's ICQ number. ...
I don't think Apple would care about asking for email for legitimate use. I thought the point of Sign in with Apple is that it decouples giving away your email from signing up. Not that it bans apps from collecting emails in any way.
That ship sailed long ago. Apple basically has apps and app-developers by the balls, not to mention the 30% extortion money they try to get not just for app purchases but any transaction done within the app, so much as even banning an app from telling the user that they can do the transaction elsewhere.
It makes my blood boil but from the discussions I see on HN about it, most people here seem to be more or less ok with it.
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 sell your product in their store and say you can look at it there but get it cheaper from Amazon?
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.
Of course you can justify Apple's behavior any way because you can claim that I am on an iPhone so I am on their property or something and so they are my overlords but that is precisely what users here are trying to argue against.
Or to be honest, you don't even need to justify it that way. The magical market justifies it because the fact that these apps are on the Apple ecosystem means that staying on it is better for them than staying off it. And no other justification is necessary. And you would not be wrong.
But people have a moral intuition about these things based on how they see the world work, and so they have an intuitive sense for when something seems 'off', even if the market seems like it's working. That's why they complain against things like exorbitant pay-day loans despite them too being an example of a market that seems to be working.
Last I checked, I did not get an iPhone on lease from Apple. This attitude where just because I am on an iPhone means I owe Apple in perpetuity needs to die.
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.
Providers of digital content seem to be absolutely all over the place with this stuff
Comcast of all people offers the ability to buy movies on demand. Not just rent but outright purchase. If you leave Comcast as a customer, you can have every purchase mailed to you as either a DVD (SD) or Blu Ray (HD) purchase
Steam has provisions in place that if its service ever gets terminated to allow users to continue to use games they've purchased on the platform. They also allow users to continue to download and play games either removed from the store or no longer sold (Alan Wake and Deadpool being two examples in my own library)
Conversely Microsoft's Xbox will de-list titles and make them excruciatingly hard to download, such as Marble Blast Ultra. Requiring you to find the game in your account history and then use that to navigate to a download page
Sony's Playstation is downright malicious with their digital store. Konami's "P.T" was offered as a free download as a teaser for an upcoming Silent Hill game
Once Konami changed their mind however, the game was not only removed from the store but actively wiped from the users console! If you connected to Playstation Network the game would be forcefully deleted from your device
You don’t own any of these things, you own a license to the content and the physical disc.
It’s completely different to owning something.
Steams provisions are helpful in practice but ultimately meaningless because you don’t own any of the actual games, you merely have a license to run the code under their terms.
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.
> 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.
They don't, the user controls this. When the user authorizes the client, they have the option to share their actual Apple ID email or use an obfuscated one.
I think it would come down to user hostility here.
If I sign in with Apple and opt out of giving my email only to be faced with a prompt demanding I give up my email address, I'll be upset. I JUST told the app (via checking the box in Apple) that I don't want to give my mail, so why is it now suddenly required?
However if the app allows me to sign in and only asks for my email when I try to interact with a feature that would be more usable had I given my email, then I would be more accepting of it. Though I would still fully expect to be able to use the app in its entirety even if I opt out.
Now what Apple will say to this, I have no idea. But as a privacy conscious user, I would be happier with this.
As for having to come up with silly names, I don't understand why I need to be discoverable within an app. We have established social media and communication platforms, use them. Let me send a link to a friend to connect with them in your random app. I don't need to be able to add them within the dang app.
I think the problem is that once you want to be found, like for a grocery shopping app, most folks think you search and just find them and when it doesn't work....they don't know to go find some settings and figure it out.
Yeah but I dont want to be found. That's why I don't share my email. If I want to share with someone, I don't want the use that app to establish a link between us, because I don't want the app to know anything about us except what it must to do it's job.
"Go find some setting and figure it out" is a UX fail. When I share eg a Dropbox link or a Google Photos link, you can get to it whether you have an established account or not. If there's something special about an app that requires an account before interaction is possible, then you can still make it a one-time share.
Yes, it does make user support more complicated. Yes, that's what I want and expect. I hope when I come asking for help, you can't help me because you have no clue who I am and have no way to get in touch with me because I used some email obscuring service. That's on me.
But in this case the company is someone who claims to be "The best way to create and share a grocery shopping list and organize your recipes."
Sharing is part of the deal with them and a sign in process that from the start complicates it is understandably a no go / introduces all sorts of complications that they detail in the article.
I get that sharing is a core thing for this app. I just don't think sharing should have anything to do with my identity. It can be a hash that is shared across any communications platform (even by meat-space, vocally!).
If the goal for the app is for itself to be a tool for identity management, then knowing my email is especially not needed...after all, all identity context is already in the app!
UX should center around ease of sharing some hash value across some other medium, not "searching by identity."
I do honestly empathize with the app creators. But anybody choosing an obscuring email by definition does not want to be identified by email.
My anecdote: About 4 years ago, I looked a shared google spreadsheet with logged with my account. I thought that my account isn't shown to document owner but it seems not. I don't know whether I clicked something like share-account button.
> 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 address, our systems will believe that you don’t have an account
Just create an invitation or "share list" link and let the user send it in any way they prefer, be it AirDrop, email or SMS.
The recipient clicks the link, and the service can connect the two accounts as needed (allowing the potentially new user to create an account as needed).
It depends mostly on the demographic in my experience. For example, my parents have icloud email addresses that they occasionally email me from and never reply to for the reasons mentioned in this post.
I’ve got a new sign in flow I’ll be using for all my indie apps. It solves 2 problems I have with Apple.
1) no PWA support for notifications
2) forcing stuff like this on everyone
I use a telegram chat bot. After signing up via the bot that sends you a link to set your password, you then also request a short expiry sign in link everytime you wish to sign in. The chatbot doubles as a notifications channel. I’m thinking of enhancing notifications do you can interact with them directly from the chatbot interface too.
The signin flow is great as it has 2fa built in by default.
Why is it user hostile? Maybe you're misunderstanding what it is but for signup it's just a wizard and for login it sends you a link. Pretty seamless experience. To signup you click a deeplink button into the chatbot follow some simple steps and then get logged into the app. Otherwise the notifications work just the same as you're used to except it leverages the chat platform instead of the developer hostile native platform.
I understand after having read the explanation. However, my experience with chatbots is that they are unreliable, unhelpful and obnoxious, and I tend to go out of my way to avoid using them. I don't think a conversation is a right model for this. I also don't think it looks good when a website or app wants me to install a messaging app to create an account (though of course some people already use Telegram). It would have to be very enticing for me to overcome that friction.
The platform (Apple's, in this case) might be hostile to developers to some extent, but the whole web is hostile to users, in no small part thanks to websites slurping as much PI as possible and then leaking it one way or another. I get spam and phishing attempts every day, as do all of us, and I regularly see some of my burner emails show up on haveibeenpwned. Any service that helps me separate my accounts from me is some progress.
Well I also have no intention of slurping PII beyond the bare minimum. I understand there may be some added friction for some users but as a one man show I can’t deal with the maintenance necessary to be on the mobile app stores. I look at it as a constraint to encourage creativity. As I develop ideas I am exploring more and more how to make the ux and the approach gel in a seamlessly natural manner. I guess I’ll find out if I’m successful after launch...
It certainly is creative, and not abusing data is commendable (and I am sincere). We would not be in this situation if websites were better behaved overall. However, I necessarily use heuristics informed by my experience, because I cannot afford the time or money to do a background check for every site or app.
> One problem is that most Apple IDs are tied to an iCloud email address. So most accounts created via Sign in with Apple will use an iCloud email address. But many of those iCloud email addresses are unused and unchecked, because a customer’s “real” email account is their Gmail, Yahoo, or Hotmail account.
Wow, this is a really good point. I just checked and yup -- my AppleID is directly linked to my icloud email, and I've never once checked my icloud email account. I wonder what's in there. Meh, too lazy to go check it
This seems strange to me. My iCloud account is my Gmail address (even though I also have an iCloud one on the account) and when I use Sign in with Apple I get an option to redirect all emails to Gmail.
But the system is indeed weird, I signed up for an account in an app with bike routes and wanted later to check it in the browser and had no idea what or how to find out what my account is or how should I sign in (could be also the app/website didn't implement this properly).
Things may differ from person to person depending on when they created their Apple account(s).
At first, before they had cloud services, you created an Apple account to purchase things from the iTunes store. You could use any email address.
Then they created MobileMe (which was rebranded to .Mac), and that came with an email address @mac.com. (I believe there were a couple of other domains you could choose instead, but don't remember what they were).
That was eventually discontinued, replaced with iCloud, and .Mac accounts were migrated.
Somewhere in all there Apple loosened requirements so that you could use an outside email address as your cloud ID, and made it so a cloud account could could also work as an iTunes account.
For those who created their accounts after that point, it's all sane. Create your Apple account using your outside email address if you want, or using an Apple provided address if you prefer, and then that one account can be used for all your Apple stuff. Buying music, buying or renting video, buying apps, and the cloud stuff.
For those of us who created our accounts before all that, we ended up with an account using our outside address which has our music, video, and app purchases on it, and an account using our @mac.com address that has calendars, photos, and the like.
When they changed it so all Apple accounts could be used for everything, it got even more annoying for us. Whenever we'd see some dialog asking us to sign in to our Apple account, we'd have to guess if it wanted our music/video/app account or our cloud account. If we guessed wrong, we could end up accidentally purchasing apps or media on the cloud account.
Apple does not provide any way to transfer purchases between your accounts, so if you end up with media or app purchases on both accounts there is no way to consolidate other than purchasing duplicates.
If you are willing to do that, or if you have avoided duplicate purchases, you can kind of manually consolidate accounts. You can export calendars, contacts, and the like from your original cloud account, and import them into your original iTunes account. Same for photos, online disk space, and anything else you have on the original cloud account.
Once you've got it all in the original iTunes account, delete everything from the original cloud account, and then just make sure to never again sign into that account. Any time you see the Apple account login dialog, give the original iTunes account.
Even if you have alternate email addresses associated with your iCloud account, you are free to update it to have your external email address be the default for your iCloud/Apple ID.
Although I will note that it says you can't change your Apple ID email address if you choose an @me.com, @mac.com, or @icloud.com email address for your Apple ID, which is the first time I've seen that warning.
My Apple ID was initially tied to my gmail address, and then at some point Apple forced me to change it, so I use my yahoo address. I never check that address, since I only use it for my Apple ID.
So you have an AppleID, which is a full iCloud account (i.e. not just an AppleID using a Gmail address.. So you login to iCloud on some device, and then specifically go untick the "Mail" option in iCloud preferences? Really?
I found it jarring that Apple would present themselves as the vanguard defenders of privacy by announcing what is basically an email relay service. Most privacy-conscious people wouldn't exactly think of their emails going through Apple as any particular win in privacy.
And even for the "general user" I find the argument very weak, since it doesn't look as being any easier than using any other email relay, and there is a huge obvious conflict of interest for Apple here (they get data they may not have had otherwise PLUS have yet another tool to bind you to their services).
It reminds me of the days where everyone in the www was making OpenID providers but no one was actually willing to do an actual OpenID _consumer_. So that I could actually use _my_ identity provider on a server of _my_ choice instead of going through the hoops of yet another large company for no reason.
How is it anything but a win to have an additional easy option to use a more trusted relay rather than not? Many people have never heard of a relay, and wouldn’t understand its benefit if the option wasn’t presented to them like this.
> 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
How is this ironic? It is by design and obviously they know why people do it because the very next sentence says that. Why on Earth would you'd want to use a list-sharing app that uses email as the addressing system and then not share your email.
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, and not having to generate a secure password is also very convenient.
The day AnyList gets hacked (not saying it will - but it's highly likely, the way security has taken a backseat due to "features") then at least my personal e-mail and password won't be there for every hacker on Earth to see and try to spam passwords to get into all of my other accounts.
Small nit: Potential hackers would only have access to your email, provider id and whatever other details they pass along (preferred name, profile picture URL, etc.). Social login doesn't provide consumers (AnyList in this case) with your password.
Agreed, social login like Facebook et. al do not provide passwords to consumers, but e-mail is already contentious enough.
Most people use the same e-mail for every single account they have. A large majority of these users use the same password for all of their accounts. (Just want to clarify that I do neither of these things - I have a large set of e-mail aliases and have a unique & secure password for each account I have to set up manually).
If you'll grant me that fact, then all I need is your e-mail from a dump of AnyList's users table, and look up that e-mail in my already vast database of dumped tables, and see that your password was "hunter2". Now I have access to your bank account, because you used the same e-mail and password for that account as well.
This is a bit of a contrived example, but in general, any personal information that is leaked (e-mail included) is bad - full name, address, and the like, which many websites ask for, is even worse, because crackers have even a better shot at guessing a lot of your personal information, and at that point, the ball is in their park.
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).
I'd personally for for the method used by Blizzard and Discord where a randomly generated ID is the actual unique value, while the username is just a display setting.
This is where their article lost credibility with me. Their decision to base their sharing and addressing system on email was their mistake, and Apple is just the first to force them to face their mistake.
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.
> If you use a unique password for every service, what would you need a unique email for?
Because then you control when the flow of marketing or "Service" related email stops. And you can tell which vendor leaked your email either deliberately or by accident.
The article also implies that if anyone can guess your email address, they can send you/share with you a list. I wonder what anti-spam measures AnyList implements?
Sign In With Apple would require that AnyList enable SPF protections on any outbound domain registered with Apple for SIWP use:
To send emails to users with private email addresses, you must register your outbound emails or email domains and use Sender Policy Framework (SPF) to authenticate your outbound emails.
If they really needed a user ID, just have account holders create a username after the Apple sign-in flow. Most people have a go-to username, and those are easy enough to remember and give to a support associate.
In my experience the “Sign on with Apple“ option makes it totally risk free to click and I don’t even think twice before clicking to create an account whereas a typical registration page will definitely raise the possibility of me bouncing.
Sign-in With Apple is perfect for those accounts that you basically never wanted to have anyway. If it’s something where I want a “real” login, especially one that I might want to share, then I’ll go through the trouble of actually registering and picking a shared secret that my wife and I know.
But for the average app that needs a way to keep a user profile for me, it’s just right, and from a UI perspective on iPhone it really is magic. Two taps and I’m just in with zero mental baggage and an email relay to eliminate the possibility of spam.
Um, it doesn’t forward to their iCloud email address, it forwards to the email they use for their iCloud login - eg the primary gmail or whatever address.
Users have the option to provide their personal email address, but given the track record of these being sold it’s reasonable to expect users to not trust you.
You can email them correspondence because as above that goes to their primary email.
What you lose is the value of the email address as an asset.
> 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 iOS user with a Windows desktop. I will never use “Sign-In with Apple” for this reason. It’s not useable unless you exclusively use Apple devices. Which I don’t.
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 devices. It should show up on the web and in Android apps, Apple only requires it on Apple devices because that's the only devices that they control.
I wish Apple communicated that better and/or developers better understood that Sign in with Apple really is a FB/Google/social login button like all of the others and should be supported everywhere, not just Apple devices.
(I'm in the iOS/Windows dual mode user team myself these days and find that I trust Sign-In with Apple, but I've definitely had to already email developers to request that they add the Sign-In with Apple button to websites and explain why they would/should.)
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.
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.
If you are on Windows and see Sign-In with Apple, Apple asks you to sign into iCloud, on their servers, if you are not already. It's almost the exact same sign-in flow you would see on Windows iTunes or Windows version of iCloud. You use your normal iCloud account information and 2FA verification (authorize the login in one of your Apple devices). Apple's servers look up the generated app-specific email address for you, just like your Apple device would, and passes that on when it passes the authentication token to the requesting application (which would use the same application identifiers it uses on iOS).
It's no worse a user experience than Sign in with Facebook or Sign in with Google, and in most ways it is the exact same user experience: click the button, get an Apple sign in prompt on Apple servers, sign in, get automatically redirected back to whatever app needed the sign in.
Side note: there's (almost) no problem implementing Apple sign in on Android. It is basically the same OAuth flow as Facebook or Twitter, with couple of minor quirks.
Apple's developer docs on the Private Email Relay Service are relevant to those evaluating the technicals of AnyList's position. Three specific highlights from that doc are relevant when considering AnyList's objections:
After the user has shared a private relay email address with your app, they can find, view, and manage it in their account settings at Settings > Apple ID > Password & Security > Apps Using Your Apple ID.
The relay server transforms your email address so it’s readable to the user. For example, sales@xyz.com may become sales_at_xyz_com_<something>@privaterelay.appleid.com instead of a random email address. Replies from the user are still routed back through the service to preserve the user’s privacy.
To send emails to users with private email addresses, you must register your outbound emails or email domains and use Sender Policy Framework (SPF) to authenticate your outbound emails.
> 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 answer is: they should just support "Sign in with Apple" on every platform. (That absolutely works. Sign in with Apple is a [mostly] standard OpenID Connect provider and has a web frontend that should work on every non-Apple platform just fine, just like FB/Google/etc.)
You wouldn't think to only support "Sign in with Google" only on Android devices? Maybe "Sign in with Facebook" should only apply to web browsers?
It's an interesting misconception or miscommunication that so many developers think "Sign in with Apple" should only show up on Apple devices.
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 support for a major platform that these multi-platform apps run on is not acceptable."
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".
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...)
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...
It was way worse when I had to implement it a few months back.
It's still incomplete, their implementation deviates from the standard or use some lesser used mechanism like the form_post response_type, requiring custom code.
Also, even if they support it, it does not look like Apple has released an app or SDK for Android.
So there would be no apple account registered on the phone.
So each app wanting to implement apple login would have to :
- pretty much implement it from scratch
- still have a very subpar experience compared to any other login mechanism (even way worse than email + password) since they would have to ask users to find their obfuscated apple email address.
Sign in with Apple asks for your normal iCloud email address. It's Apple's servers that look up your app-specific obfuscated relay email address if you've used one for the app.
A good sdk means that it is both quick to implement and that it can integrate with the OS account feature (meaning users only have to authentify once for their apple account)
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.
Absolutely not. Compare the native ios documentation[1] with their "other platforms" documentation[2]. Their native documentation has code snippets, helpful links, and explains in depth what is happening.
The "other platforms" documentation is "make this request, store some data, follow redirects". No code, no helpful links on how you might accomplish these things, nothing. You get the bare minimum.
I'm not saying its impossible, and neither is the article. I'm saying that Apple clearly doesn't care about supporting a platform as huge as Android, and that clearly signals to multi-platform developers that they are on their own.
The nature of "other" platforms means that example code could be in any language at all.
The fact that their iOS documentation is so much better than average doesn't mean their "other platforms" documentation is inadequate. It just means there's plenty of room for third parties like indie bloggers to documentation their own approaches in JavaScript, Python, Ruby, Rust, or whatever.
Part of the problem is that android is an "other platform" in the first place. Sign in with apple is supposed to be a cross platform feature, but Apple can't be bothered to even write out some decent documentation for a platform with over 2 billion devices. Compare, for example, the Google sign in for iOS[1]. They provide a working example project and full documentation.
If you are a developer supporting a cross platform app, you're not getting much help from Apple. That's what the article is saying: integrating this feature is going to be more work and more risk than it's worth. That's the point.
> It just means there's plenty of room for third parties like indie bloggers to documentation their own approaches in JavaScript, Python, Ruby, Rust, or whatever.
We are talking about signing in. This is one of the most fundamental features you need to have. This is not something that you just copy paste from some half baked blog post. It is amazing to me you think that's acceptable.
Not surprised the documentation that highlights the Apple Platform is better, however, give.
That said, it’s a REST API you query and you get a well defined payload:
> A successful response contains the following parameters:
code
A single-use authorization code that is valid for five minutes.
id_token
A JSON web token containing the user’s identity information.
state
The state contained in the Authorize URL.
user
A JSON string containing the data requested in the scope property. The returned data is in the following format: { "name": { "firstName": string, "lastName": string }, "email": string }
I could implement this using curl really it’s that straightforward. If you have any experience consuming REST APIs
To repeat myself, I know that this is more than possible to implement. But you're also hiding a lot of complexity about redirecting from your app to a browser, managing state, custom url schemes, etc. If you want to turn your curl request into an actual app, there's some nontrivial code you have to write and test yourself. And this code is important - if a user can't sign in, your entire app is broken.
And to what benefit? This is the point of the article. Sign in for apple is extra work and extra complexity for no benefit (to the developer, at least). It's an immature project and the fact that Apple is putting in the bare minimum effort into the docs does not encourage me to adopt this feature.
Google, in comparison, has a working sample project and step by step guide for implementing Google sign in on iOS[1]. Google sign in is just as much a "curl request" as apple sign in, but they put in the effort to give a high quality, well integrated, and native example.
Apple can't be bothered, which discourages people like OP from adopting the feature.
I agree in principal, but in practice this isn't as easy as one would hope. Each IdP has slightly different requirements and parameters for connecting clients. There may be significant code non-overlap across providers, not to mention across platforms.
Facebook, for instance, doesn't actually implement OpenID Connect, but has a custom layer on top of OAuth. Their recommended method of connecting is a client SDK for each platform.
For me it sounds like they didn’t like the additional work Apple made them do, that would actually benefit the end user - I love sign in with apple, the best part is the unified workflow without typing on a phone.
I dream of a world when I won’t have to type passwords on a phone anymore.
Their blog post is well written and explains point by point why implementing it would be problematic for them AND for end users. Strange that you arrived at the conclusion "they didn’t like the additional work Apple made them do"
They describe and edge case of someone not getting the email or wanting to login on another platform.
I’m talking about the most common happy path that they don’t want to optimize - the user registration/login
I hate typing a secure password on a phone and I want to evade this process whenever possible. Using Sign in with Apple you don’t have to type a thing and you confirm using FaceId.
It seems like the problems they were facing require different UX solutions than they already had or some bug reports to Apple (if the feature is really missing something).
For me it is much better to use Sign in with Apple as the user as the flow is simple, unified and Apple has a track record of caring about privacy, where it is often not the case for randomservice.io
Not an Apple use but I had a question. If one signs up with Signin with Apple, how can that user move over his stuff to say an Android app? Or even Desktop app? (Or does the Apple ID keep track of all this anonymous id to app mapping?)
You still have your apple account on your PC/Android phone/etc. You just login on apple's website with your apple account and it passes the token/id to whatever app needs it.
For example you can goto dropbox on your pc/whatever and click signin with apple to see how it works.
Last year we pulled all social logins (facebook, google, yahoo) out of our app, after supporting them for years. The UX / customer service issues mentioned in this post are absolutely legit, a complete PITA. While we were nervous about adding the extra signup friction, a year later I can easily say it was worth doing.
484 comments
[ 3.4 ms ] story [ 274 ms ] threadApple "demanded" companies either add their privacy friendly sign in option, or give up on the data-slurping Facebook google sign-ups. This company gave up FB sign in, which they acknowledge is pretty gross and bloated.
These seem to just be contrived arguments to protect their customer data selling bottom line.
Seems out of place to complain about not having email addresses for "support" reasons.
If they truly cannot help users without asking for their email address, maybe they should not have users (login) then.
Side note, disabling 'load remote content' in email client stops all spam in a while, they think emails are not read.
The blog post was long and winded. And it brought up some very desperate arguments, like the bug bounty offered to hackers when they report security vulnerabilities.
They want people's email addresses, period.
They say that no email breaks the sharing feature. True. But that's something that can be offered later when someone actually does share something with you. They say that the emails will go to the a seldom checked account. True. But users can change email addresses. They say it breaks support service for looking up accounts without email addresses. Again true. But what's another way of looking up accounts? Username. What is another? Apple ID.
They are email network harvesters. Plain and simple. And this is their business model.
And to extend that, if they are a spammy company, that would be exactly why they would be complaining about SIWAI.
I think Sign in with Apple is a great step forward even if all it does is eliminate apps that require Facebook and/or Google accounts to log in. I hate that - I actually ran into a feature on my mesh router system that required a FB/G login, which made it a useless feature for me. Fortunately I didn't need it..
Mobile number login is even worse! Why do I need to share my mobile number for something where you don't need to have it!
I think you got this the wrong way around.
[0]: https://caltopo.com/map.html
This was the first month of Pokemon Go years ago. I haven't heard of it being an issue lately but I also haven't needed to create an account in a very long time.
And a bit over a year the same thing happened. New Pokemon Go account -> log in -> no game. With Google account has been working since.
So, my experience is two tries in the span of two years it did not work.
I’ve gotten rid of Facebook, but now my account name is just a bunch of numbers.
Their whole point was that you could be confident the people were real because they were tied to a real Facebook account.
1) Identity is an email address. If I wanted to rip out Google, or Google kicked me off the platform, all I need to do is add passwords and put a "forgot my password" link and my customers continue business as usual.
2) It's not a google-specific email address. You can create Google accounts for any email address.
3) Google login effectively lets other businesses federate their auth system with ours. When they terminate their ex-employee's @example.com account, the employee loses access to their resources at my company.
I don't think you could get away with this for a consumer company; too many people have strong feelings about FB/G/Apple/whatever. But it's fantastic for B2B.
https://developers.google.com/identity/sign-in/web
There may be other options if you want to mess with oauth yourself, but this one is pretty near zero effort.
It's a choice they made, nothing specific to Google or OAuth.
Also there are cases where a "sign in with <particular provider>" is the only option that makes sense because you really want to integrate with the API of this provider. Take for example a "sign in with GitHub". Or in case of services correlated, take for example Instagram where you obviously can sign up with a Facebook account.
I'm more for letting the developer choose what it prefers for authenticating the user and not having a authentication system that gets imposed by Apple.
[1] https://www.anylist.com/auth/sign-in
[2] https://i.imgur.com/3uC0E9G.png
We assumed this success would quickly taper off if it wasn't "one click" to sign up with your Google/Faceboook account an talked Neil off the ledge.
Seeing some actual numbers would help me in making that decision.
Personally I would have considered to hack something on my own time just out of curiosity :D
At any rate, thanks for the hard work you put into it and I've used this site a lot.
I kind of ended up with a love hate thing as well, it breaks pretty much every responsive, UX, accessibility rule out there, but at the same time it was Neil's vision. It's at least somewhat intentional that you have to dig at it a bit.
All that being said my first meeting with Neil I told him "This won't work on mobile" and his exact words were "Fuck Mobile ..."
[1] https://www.amazon.com/Neil-Young-Archives-One-Blu-ray/dp/B0...
email remains the best and free-est login identifier. Most people who are not complete internet plebs have a second email for things they dont trust.
The vast majority of people don’t have a second email for things they don’t trust. You’re living in a nerd-bubble, but the rest of the world is on the internet too.
"These are both excellent points, and it’s absolutely true that some of the arguments above apply to creating an account via Facebook. That’s why we’re also announcing that we’ll be removing the Facebook Login from AnyList."
They didn't want to implement Sign in with Apple, so they had to remove FB login.
They're essentially using their control of the iOS ecosystem to benefit unrelated products.
I seem to remember that those kinds of actions didn't work out well for Microsoft :)
But I don't know how much a judge would care about that.
Ok sure. That seems totally the same. Not at all as ridiculous as the invented "monopoly of iOS" that people use to justify the claim Apple is abusing a monopoly position.
Next thing you'll complain Coca Cola is abusing its monopoly position on Coke.
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.
Specifically, if you implement Sign In with Apple, then they are still your customers as much as ever, they just might choose to hide their information from you because they don't trust you, which means that the power in the relationship is transferred to the user instead of the app developer.
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.
I actually think this wouldn’t really happen in practice as consumers are quick to respond negatively to this behavior, so I’d be shocked if Apple actually did this without some darn good reason (I imagine it will also include removing said app)
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.
Hardware requirements for software is a decades old concept, and it’s true they deprecate and obsolete supported software and hardware on for older platforms, but it’s rare I’ve seen Apple taken a user hostile approach here within supported lifetimes though it has happened yes it is rare.
Their developer experience on the other hand does not see the same care and attention a lot (most even) of the time. That’s because, and I believe this strongly, Apple never wants 3rd party software to have platform influential power over them again, like Microsoft and Adobe did for decades. It’s sad but not unsurprising that their platforms can be very developer antagonistic if you don’t take their happy path (and sometimes even then). To them though, it doesn’t matter until it affects a large quadrant of the Apple consumer base and in some occasions yes not even then, but largely it’s the consumer who has the biggest voting block with Apple in terms of pressure on the platform, as I’ve watched it play it they never had a history particularly after the iPhone came out of having the best developer relations relative to say, Microsoft, who provides a very positive experience in comparison
It’s just not in their DNA because of the fear of having too powerful of vendors putting pressure on the platform that they otherwise control outright. When you look at their policies in this context they make a heck of a lot more sense (even if you don’t agree. I certainly do not always)
If you wanted something truly private you could create an account at a provider like Fastmail or ProtonMail and create an alias for each account (or just wildcard a custom domain until you need to send from an address). I doubt any tracking system is based on the domain in your email address... not yet, at least.
Some makers just want things to work and to keep the process as simple as possible for the user.
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 address, our systems will believe that you don’t have an account
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? Of course this should be opt-in but you can always Under good faith explain benefits there in.
It’s more work, but I don’t believe that it’s going to run issue with Apple and provides end users with flexibility.
Of course this may not be worth it, at all. This is just a consideration worth thinking about as an app developer
edit: Of course another alternative here is they just make users aware of what their sharing email is and allow users to optionally change that, if they want to. This most definitely wouldn’t run counter to this I’d think
I'm fairly certain that detecting someone hiding their e-mail from you and then making them pick a different e-mail goes against the spirit, if not the rules, of Sign In with Apple.
That said, it would be extremely beneficial to pop up a screen saying "Hey, is this the e-mail you want to use for communications?" and let the user decide.
That said, removing third-party sign-in is also a fine solution, almost definitely a better one, and simplifies things immensely for everyone involved (assuming their sign-in form in the app supports saving passwords to the keychain).
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 forwards with people being able to use Sign In With Apple (of course, that means some users may opt out of marketing emails entirely by refusing to provide a 2nd address).
This does probably go against the spirit of the feature, but if it actually is against Apple's rules to be doing this (anyone know the answer to this?), then it would definitely veer on the side of user hostility on Apple's part, since I would expect many apps to be taking a stance similar to the one taken by AnyList here.
Anyone in that position would think the app is shady AF and user hostile.
It's not necessarily shady or user hostile when done right, and there are plenty of opportunity to add trust relationship building as a part of the consent process (links to privacy policies; details about marketing policies; etc).
It's also not that different from how many iOS applications (at least) are encouraged (in App Store best practices) to handle consent models for location tracking and notifications: ask the user as they become familiar with the application, not up front, and provide as much context as you can.
That said though, I don't see why the app couldnt just change their sharing model to an "invite link" based pattern. If I want to share something with a friend, why do I need to provide their private information to the app to do it? Why can't I generate an invite link and send that through my already established channels of communication? I don't think the "but your friends don't know your Apple privacy email" reason is very compelling. That might not work in their current system, but it is definitely not an insurmountable problem.
(ETA: They make an okay follow up point that someone accepting an invite link sent to a different email sends a signal that they could just go ahead and link that email address directly to the account, and don't see why you wouldn't just give them that email in the first place. But in addition to being a squicky privacy faux pas to automatically link any email to an account without direct user consent, there are plenty of reasons to send emails to an address only indirectly linked to a person and/or that a user would not feel comfortable directly linking to an account. It's a somewhat flimsy argument below the surface, I think.)
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
Of course another alternative here is they just make users aware of what their sharing email is and allow users to optionally change that, if they want to.
I think their perfectly valid to do what they’re doing but I also don’t buy into this being an overly complicated logistical hurdle either
Many of the objections come from wanting to do things the old way, without privacy and responsible handling of private data.
No, they come from the fact that privacy comes at a cost. In this case, it's much harder to receive support, find your account if you lose it, and get proper communication. Everything is a trade off, and anyone who thinks the reason things have been done this way is only to scoop up as much data as possible is either brainwashed or naive. These changes are adding a whole new layer of complexity, which may be worth it in some cases, but in others it just is a net negative for the customer.
{app_name}@example.com goes to the same place, but it is easy for me to see if they sell/lose my email. And if it gets lost I'm done with them I can just block that specific address.
The added benefit is no one can assume that {my_name}@example.com is my bank email address or my email login.
I used to have a standard {username}@gmail.com for a while, but now it is on 20+ breached site lists. Best case? Copious amounts of spam. Worst case? I may have been reusing a password prior to switching to a password manager.
Now, I can just block the email from receiving anything. Two, if I accidentally reuse a password the username is at least different.
Apple clearly likes the idea of the hide option... personally I would expect a less than positive reception from Apple.
I get where both AnyList (if they asked) and Apple (if they didn't like it) would be coming from here.
It does seem to be a shortcoming here where outside of a user one time sign up situation... you don't want to have to burden the user with coming up with silly names and codes to use social like features that require someone else knowing an identifier for you that isn't email.
I don't want to go back to a time where we have to remember / pass along everyone's ICQ number. ...
It makes my blood boil but from the discussions I see on HN about it, most people here seem to be more or less ok with it.
Does Walmart let you sell your product in their store and say you can look at it there but get it cheaper from Amazon?
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 sell your product in their store and say you can look at it there but get it cheaper from Amazon?
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.
Of course you can justify Apple's behavior any way because you can claim that I am on an iPhone so I am on their property or something and so they are my overlords but that is precisely what users here are trying to argue against.
Or to be honest, you don't even need to justify it that way. The magical market justifies it because the fact that these apps are on the Apple ecosystem means that staying on it is better for them than staying off it. And no other justification is necessary. And you would not be wrong.
But people have a moral intuition about these things based on how they see the world work, and so they have an intuitive sense for when something seems 'off', even if the market seems like it's working. That's why they complain against things like exorbitant pay-day loans despite them too being an example of a market that seems to be working.
Last I checked, I did not get an iPhone on lease from Apple. This attitude where just because I am on an iPhone means I owe Apple in perpetuity needs to die.
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.
Not if it's a movie, music, or video game. I.e. anything with digital content.
Comcast of all people offers the ability to buy movies on demand. Not just rent but outright purchase. If you leave Comcast as a customer, you can have every purchase mailed to you as either a DVD (SD) or Blu Ray (HD) purchase
Steam has provisions in place that if its service ever gets terminated to allow users to continue to use games they've purchased on the platform. They also allow users to continue to download and play games either removed from the store or no longer sold (Alan Wake and Deadpool being two examples in my own library)
Conversely Microsoft's Xbox will de-list titles and make them excruciatingly hard to download, such as Marble Blast Ultra. Requiring you to find the game in your account history and then use that to navigate to a download page
Sony's Playstation is downright malicious with their digital store. Konami's "P.T" was offered as a free download as a teaser for an upcoming Silent Hill game
Once Konami changed their mind however, the game was not only removed from the store but actively wiped from the users console! If you connected to Playstation Network the game would be forcefully deleted from your device
It’s completely different to owning something.
Steams provisions are helpful in practice but ultimately meaningless because you don’t own any of the actual games, you merely have a license to run the code under their terms.
> 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.
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.
So Apple is being extra controlling here. They consider all Apple users property of Apple, so they take a cut off all digital transactions.
Apple isn't forcing anything here.
If I sign in with Apple and opt out of giving my email only to be faced with a prompt demanding I give up my email address, I'll be upset. I JUST told the app (via checking the box in Apple) that I don't want to give my mail, so why is it now suddenly required?
However if the app allows me to sign in and only asks for my email when I try to interact with a feature that would be more usable had I given my email, then I would be more accepting of it. Though I would still fully expect to be able to use the app in its entirety even if I opt out.
Now what Apple will say to this, I have no idea. But as a privacy conscious user, I would be happier with this.
As for having to come up with silly names, I don't understand why I need to be discoverable within an app. We have established social media and communication platforms, use them. Let me send a link to a friend to connect with them in your random app. I don't need to be able to add them within the dang app.
"Go find some setting and figure it out" is a UX fail. When I share eg a Dropbox link or a Google Photos link, you can get to it whether you have an established account or not. If there's something special about an app that requires an account before interaction is possible, then you can still make it a one-time share.
Yes, it does make user support more complicated. Yes, that's what I want and expect. I hope when I come asking for help, you can't help me because you have no clue who I am and have no way to get in touch with me because I used some email obscuring service. That's on me.
But in this case the company is someone who claims to be "The best way to create and share a grocery shopping list and organize your recipes."
Sharing is part of the deal with them and a sign in process that from the start complicates it is understandably a no go / introduces all sorts of complications that they detail in the article.
If the goal for the app is for itself to be a tool for identity management, then knowing my email is especially not needed...after all, all identity context is already in the app!
UX should center around ease of sharing some hash value across some other medium, not "searching by identity."
I do honestly empathize with the app creators. But anybody choosing an obscuring email by definition does not want to be identified by email.
Just create an invitation or "share list" link and let the user send it in any way they prefer, be it AirDrop, email or SMS.
The recipient clicks the link, and the service can connect the two accounts as needed (allowing the potentially new user to create an account as needed).
Is that actually true? None in my household are.
But, when I setup the account for my mom and my wife, I just created an iCloud email address.
My wife never uses her iCloud email address. I don’t think she uses the default mail client - she uses the gmail app.
1) no PWA support for notifications
2) forcing stuff like this on everyone
I use a telegram chat bot. After signing up via the bot that sends you a link to set your password, you then also request a short expiry sign in link everytime you wish to sign in. The chatbot doubles as a notifications channel. I’m thinking of enhancing notifications do you can interact with them directly from the chatbot interface too.
The signin flow is great as it has 2fa built in by default.
I understand after having read the explanation. However, my experience with chatbots is that they are unreliable, unhelpful and obnoxious, and I tend to go out of my way to avoid using them. I don't think a conversation is a right model for this. I also don't think it looks good when a website or app wants me to install a messaging app to create an account (though of course some people already use Telegram). It would have to be very enticing for me to overcome that friction.
The platform (Apple's, in this case) might be hostile to developers to some extent, but the whole web is hostile to users, in no small part thanks to websites slurping as much PI as possible and then leaking it one way or another. I get spam and phishing attempts every day, as do all of us, and I regularly see some of my burner emails show up on haveibeenpwned. Any service that helps me separate my accounts from me is some progress.
Wow, this is a really good point. I just checked and yup -- my AppleID is directly linked to my icloud email, and I've never once checked my icloud email account. I wonder what's in there. Meh, too lazy to go check it
But the system is indeed weird, I signed up for an account in an app with bike routes and wanted later to check it in the browser and had no idea what or how to find out what my account is or how should I sign in (could be also the app/website didn't implement this properly).
At first, before they had cloud services, you created an Apple account to purchase things from the iTunes store. You could use any email address.
Then they created MobileMe (which was rebranded to .Mac), and that came with an email address @mac.com. (I believe there were a couple of other domains you could choose instead, but don't remember what they were).
That was eventually discontinued, replaced with iCloud, and .Mac accounts were migrated.
Somewhere in all there Apple loosened requirements so that you could use an outside email address as your cloud ID, and made it so a cloud account could could also work as an iTunes account.
For those who created their accounts after that point, it's all sane. Create your Apple account using your outside email address if you want, or using an Apple provided address if you prefer, and then that one account can be used for all your Apple stuff. Buying music, buying or renting video, buying apps, and the cloud stuff.
For those of us who created our accounts before all that, we ended up with an account using our outside address which has our music, video, and app purchases on it, and an account using our @mac.com address that has calendars, photos, and the like.
When they changed it so all Apple accounts could be used for everything, it got even more annoying for us. Whenever we'd see some dialog asking us to sign in to our Apple account, we'd have to guess if it wanted our music/video/app account or our cloud account. If we guessed wrong, we could end up accidentally purchasing apps or media on the cloud account.
Apple does not provide any way to transfer purchases between your accounts, so if you end up with media or app purchases on both accounts there is no way to consolidate other than purchasing duplicates.
If you are willing to do that, or if you have avoided duplicate purchases, you can kind of manually consolidate accounts. You can export calendars, contacts, and the like from your original cloud account, and import them into your original iTunes account. Same for photos, online disk space, and anything else you have on the original cloud account.
Once you've got it all in the original iTunes account, delete everything from the original cloud account, and then just make sure to never again sign into that account. Any time you see the Apple account login dialog, give the original iTunes account.
Visit https://appleid.apple.com/account/manage to make those changes.
Help article: https://support.apple.com/en-us/HT202667
Although I will note that it says you can't change your Apple ID email address if you choose an @me.com, @mac.com, or @icloud.com email address for your Apple ID, which is the first time I've seen that warning.
That has never been an issue.
So you have an AppleID, which is a full iCloud account (i.e. not just an AppleID using a Gmail address.. So you login to iCloud on some device, and then specifically go untick the "Mail" option in iCloud preferences? Really?
And even for the "general user" I find the argument very weak, since it doesn't look as being any easier than using any other email relay, and there is a huge obvious conflict of interest for Apple here (they get data they may not have had otherwise PLUS have yet another tool to bind you to their services).
It reminds me of the days where everyone in the www was making OpenID providers but no one was actually willing to do an actual OpenID _consumer_. So that I could actually use _my_ identity provider on a server of _my_ choice instead of going through the hoops of yet another large company for no reason.
Ironically, this is also why I use Sign Up with Apple at every opportunity I can
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, and not having to generate a secure password is also very convenient.
The day AnyList gets hacked (not saying it will - but it's highly likely, the way security has taken a backseat due to "features") then at least my personal e-mail and password won't be there for every hacker on Earth to see and try to spam passwords to get into all of my other accounts.
Most people use the same e-mail for every single account they have. A large majority of these users use the same password for all of their accounts. (Just want to clarify that I do neither of these things - I have a large set of e-mail aliases and have a unique & secure password for each account I have to set up manually).
If you'll grant me that fact, then all I need is your e-mail from a dump of AnyList's users table, and look up that e-mail in my already vast database of dumped tables, and see that your password was "hunter2". Now I have access to your bank account, because you used the same e-mail and password for that account as well.
This is a bit of a contrived example, but in general, any personal information that is leaked (e-mail included) is bad - full name, address, and the like, which many websites ask for, is even worse, because crackers have even a better shot at guessing a lot of your personal information, and at that point, the ball is in their park.
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).
Riot does this with Valorant too and the implementation is a nightmare.
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.
It's dead clear that you don't work with consumers. Your technical bias shows what you care about and you're(an me) are an utter minority.
If you want security, btw - you should have multiple passwords for different things. And ideally not even use a password manager.
What's the point in password manager, if all you need is one time auth - and you're in!
If you use a unique password for every service, what would you need a unique email for?
Because then you control when the flow of marketing or "Service" related email stops. And you can tell which vendor leaked your email either deliberately or by accident.
To send emails to users with private email addresses, you must register your outbound emails or email domains and use Sender Policy Framework (SPF) to authenticate your outbound emails.
Sign-in With Apple is perfect for those accounts that you basically never wanted to have anyway. If it’s something where I want a “real” login, especially one that I might want to share, then I’ll go through the trouble of actually registering and picking a shared secret that my wife and I know.
But for the average app that needs a way to keep a user profile for me, it’s just right, and from a UI perspective on iPhone it really is magic. Two taps and I’m just in with zero mental baggage and an email relay to eliminate the possibility of spam.
Users have the option to provide their personal email address, but given the track record of these being sold it’s reasonable to expect users to not trust you.
You can email them correspondence because as above that goes to their primary email.
What you lose is the value of the email address as an asset.
I’m an avid iOS user with a Windows desktop. I will never use “Sign-In with Apple” for this reason. It’s not useable unless you exclusively use Apple devices. Which I don’t.
I wish Apple communicated that better and/or developers better understood that Sign in with Apple really is a FB/Google/social login button like all of the others and should be supported everywhere, not just Apple devices.
(I'm in the iOS/Windows dual mode user team myself these days and find that I trust Sign-In with Apple, but I've definitely had to already email developers to request that they add the Sign-In with Apple button to websites and explain why they would/should.)
It's no worse a user experience than Sign in with Facebook or Sign in with Google, and in most ways it is the exact same user experience: click the button, get an Apple sign in prompt on Apple servers, sign in, get automatically redirected back to whatever app needed the sign in.
I’ve also never come across a “sign in with Apple” button on Windows. Not sure I’ve seen it on iOS either...
https://developer.apple.com/documentation/sign_in_with_apple...
After the user has shared a private relay email address with your app, they can find, view, and manage it in their account settings at Settings > Apple ID > Password & Security > Apps Using Your Apple ID.
The relay server transforms your email address so it’s readable to the user. For example, sales@xyz.com may become sales_at_xyz_com_<something>@privaterelay.appleid.com instead of a random email address. Replies from the user are still routed back through the service to preserve the user’s privacy.
To send emails to users with private email addresses, you must register your outbound emails or email domains and use Sender Policy Framework (SPF) to authenticate your outbound emails.
The easy answer is: they should just support "Sign in with Apple" on every platform. (That absolutely works. Sign in with Apple is a [mostly] standard OpenID Connect provider and has a web frontend that should work on every non-Apple platform just fine, just like FB/Google/etc.)
You wouldn't think to only support "Sign in with Google" only on Android devices? Maybe "Sign in with Facebook" should only apply to web browsers?
It's an interesting misconception or miscommunication that so many developers think "Sign in with Apple" should only show up on Apple devices.
"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 support for a major platform that these multi-platform apps run on is not acceptable."
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...
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...
It's still incomplete, their implementation deviates from the standard or use some lesser used mechanism like the form_post response_type, requiring custom code.
Implementing this was not a pleasant experience.
So there would be no apple account registered on the phone.
So each app wanting to implement apple login would have to :
- pretty much implement it from scratch
- still have a very subpar experience compared to any other login mechanism (even way worse than email + password) since they would have to ask users to find their obfuscated apple email address.
Still pretty meh that it is the only solution of its kind without an sdk
Any OpenID Connect (or OAUTH2) library of the devs choice is the SDK.
The Facebook/google SDKs are simply there to add trackers and bloat.
https://developer.apple.com/documentation/sign_in_with_apple...
The "other platforms" documentation is "make this request, store some data, follow redirects". No code, no helpful links on how you might accomplish these things, nothing. You get the bare minimum.
I'm not saying its impossible, and neither is the article. I'm saying that Apple clearly doesn't care about supporting a platform as huge as Android, and that clearly signals to multi-platform developers that they are on their own.
[1] https://developer.apple.com/documentation/authenticationserv...
[2] https://developer.apple.com/documentation/sign_in_with_apple...
The fact that their iOS documentation is so much better than average doesn't mean their "other platforms" documentation is inadequate. It just means there's plenty of room for third parties like indie bloggers to documentation their own approaches in JavaScript, Python, Ruby, Rust, or whatever.
Part of the problem is that android is an "other platform" in the first place. Sign in with apple is supposed to be a cross platform feature, but Apple can't be bothered to even write out some decent documentation for a platform with over 2 billion devices. Compare, for example, the Google sign in for iOS[1]. They provide a working example project and full documentation.
If you are a developer supporting a cross platform app, you're not getting much help from Apple. That's what the article is saying: integrating this feature is going to be more work and more risk than it's worth. That's the point.
> It just means there's plenty of room for third parties like indie bloggers to documentation their own approaches in JavaScript, Python, Ruby, Rust, or whatever.
We are talking about signing in. This is one of the most fundamental features you need to have. This is not something that you just copy paste from some half baked blog post. It is amazing to me you think that's acceptable.
[1] https://developers.google.com/identity/sign-in/ios/start
Have you ever actually implemented a proper sign-in process e.g. with OIDC, JWT, SSO etc ?
Because half baked blog posts is the industry standard.
That said, it’s a REST API you query and you get a well defined payload:
> A successful response contains the following parameters: code A single-use authorization code that is valid for five minutes. id_token A JSON web token containing the user’s identity information. state The state contained in the Authorize URL. user A JSON string containing the data requested in the scope property. The returned data is in the following format: { "name": { "firstName": string, "lastName": string }, "email": string }
I could implement this using curl really it’s that straightforward. If you have any experience consuming REST APIs
And to what benefit? This is the point of the article. Sign in for apple is extra work and extra complexity for no benefit (to the developer, at least). It's an immature project and the fact that Apple is putting in the bare minimum effort into the docs does not encourage me to adopt this feature.
Google, in comparison, has a working sample project and step by step guide for implementing Google sign in on iOS[1]. Google sign in is just as much a "curl request" as apple sign in, but they put in the effort to give a high quality, well integrated, and native example.
Apple can't be bothered, which discourages people like OP from adopting the feature.
[1] https://developers.google.com/identity/sign-in/ios/start
Even though there is way more value in supporting Google, than Apple. Google SSO is widely used in small businesses, unlike Apple ID.
Facebook, for instance, doesn't actually implement OpenID Connect, but has a custom layer on top of OAuth. Their recommended method of connecting is a client SDK for each platform.
I dream of a world when I won’t have to type passwords on a phone anymore.
I’m talking about the most common happy path that they don’t want to optimize - the user registration/login
I hate typing a secure password on a phone and I want to evade this process whenever possible. Using Sign in with Apple you don’t have to type a thing and you confirm using FaceId.
It seems like the problems they were facing require different UX solutions than they already had or some bug reports to Apple (if the feature is really missing something).
For me it is much better to use Sign in with Apple as the user as the flow is simple, unified and Apple has a track record of caring about privacy, where it is often not the case for randomservice.io
For example you can goto dropbox on your pc/whatever and click signin with apple to see how it works.