How Popular Is “Sign in with Apple”? | Hacker News Reader

How Popular Is “Sign in with Apple”?

daringfireball.net

307 pointscpach323 comments

I tried to do a Sign in with Apple integration on Android (wanted the app to have the same options across platforms).

Testing on Android was next to impossible. To test I needed an Apple ID with 2FA. But SMS 2FA was not good enough, you need the hardware-based 2FA. To get that you need a recent macOS or iOS device. As an Android developer I have no reason to own either of those.

Eventually I just had a friend who owns an iPhone try my app a few times.

Besides that, the Apple interface guidelines are nearly impossible to follow on Android because Apple doesn't provide the logo or font assets you need to comply. There is no SDK whatsoever, just a spec.

Seems like a nice sign-in option for iPhone owners but it's a portability disaster.

Apple continues to not give any care whatsoever to anything outside their walled garden. For the longest time you couldn't even preview songs on iTunes store without having iTunes. Want to watch their biggest WWDC live? Had to use Safari until last year. Obviously iMessage and FaceTime are complete no-gos outside their walled garden too.

This is how they keep people in. They have to close down their walls as tightly as possible, to force people in. And once you're in, they make it as hard as possible to leave.

>This is how they keep people in. They have to close down their walls as tightly as possible, to force people in. And once you're in, they make it as hard as possible to leave.

I call old wives tales. I'm a close-to-20-years Apple user. The walled garden has never been a problem, more of a strength (integration, cohesion, etc).

Especially today where everything is a subscription, there has never been LESS of a walled garden in that regard. I can move anytime (and I do use also Windows and Linux) and I wont have any issue with OS X/iOS.

I just wont have my apps -- which has been the case for every OS ever.

My music is in Spotify and Apple Music, my video is Netflix and Amazon Prime and Apple+, my email is Gmail, my eBooks in Kindle for Mac and iOS, I talk with friends with Skype, Facetime, Messenger and Whatsup. Even my iCloud apps (Calendar, email, etc) are available from any browser.

Some "walled garden".

The reason I don't want to move from OS X/iOS is cohesion and usability. Despite BS like the 3+ years MBP keyboard fiasco or the not-really-useful BS touch strip, it's still the best HW/SW combo for my kind of computing (programming, lots of UNIXy stuff, lots of video and music as well).

> My music is in Spotify and Apple Music, my video is Netflix and Amazon Prime and Apple+

Does Spotify somehow integrate with Apple Music and Netflix with Apple+? Because, if not, your counterargument is just "there's no walled garden because I'm outside it".

Spotify, Netflix, Google, Kindle, etc work on both platforms. Apple stuff doesn't. That's the definition of "walled garden", that you can't use Android and still use any Apple stuff.

FWIW Apple Music does work on android, reasonably well too. I switched to that when it became apparent that Google Play Music is a dead product, soon to be sent to the glue factory.

Do you know if Apple Music is available on Windows? I know iTunes has been on Windows for years, so I assume it supported Apple Music initially, just like on the Mac?

Why do people use Apple Music over Spotify?

>Does Spotify somehow integrate with Apple Music and Netflix with Apple+? Because, if not, your counterargument is just "there's no walled garden because I'm outside it".

No, my argument is "there's no walled garden because with subscriptions there are no walls to close you in".

Apple Music is a subscription, you move to Spotify or Pandora or Youtube Music or whatever and that's that. You don't have the loss of your music or whatever locking you down to either OSX/iOS or even Apple Music alone as the parent said. That would be an argument back when music was DRM files you have bought and which would have stopped working outside Apple's ecosystem.

Ditto of course for Netflix, Mail, etc.

The closest you can get to the "walled garden" is iBooks -- Kindle wont display books you've bought there. But you can trivially just use Kindle app on macOS/iOS and problem solved. Apple's not forcing you to use iBooks.

> You don't have the loss of your music or whatever

You just lose playlist and ratings

> you can trivially just use Kindle app on macOS/iOS

Except Apple cripples features of the Kindle app (you cannot buy books through the app because if you did, Apple would demand a 30% cut that represents all of the Amazon profits) that are not crippled in Apple's own offering.

AppleTV+ is also available on the web and on Roku and Samsung TVs. So again, not a walled garden even when using their products.

Oh okay, if it's on Samsung TVs that's pretty much FOSS levels of openness, I agree.

Your reply here seems to try to twist the thread to a point where all uses of 'open' or 'non-walled' has to equate FOSS or EFF ideals, while you probably know that is neither feasible nor what is being discussed. It feels like you're intentionally acting obtuse at this point.

how about the $5k or so in media i have in googles ecosystem? their apps are literally garbage on ios and i had to resort to using youtube to watch content i paid for. even this didn’t work after some time as i have so much media even the youtube app started timing out when loading my purchases. there is no compatible format for ios, so you gotta use their garbage apps. it became such a huge problem that i bought everything that moviesanywhere didn’t already give me over again on itunes store just so i could have an actual file and, you know, actually watch the content i bought. google is substantially worse in their walled garden attempts

>how about the $5k or so in media i have in googles ecosystem? their apps are literally garbage on ios

I've never seen any Google app being a problem on iOS, much less garbage. It just doesn't have the native look due to Material theming.

I feel like reason you can move is because you haven't put all your eggs in their walled garden, not that they don't have one. I know people who either won't or have regretted switching from an iPhone because they have trouble talking to their friend who only use iMessage. I think Apple is only increasing their walled garden into more areas by expanding into music streaming, TV, etc. You can still use their hardware and OS without fully buying into their walled garden though and maintain more freedom, as you seem to do!

edit: I should mention that while I don't like their walled gardens in general, I don't mind them for other people except iMessage. iMessage makes me fairly angry because they're using & dividing people's social connections for profit.

iMessage is the greatest thing to happen to text messaging since text messaging itself. I refuse to use any Facebook owned product to communicate; so, that pretty much only leaves me SMS and iMessage.

I think you should be pissed at bottom barrel Android manufacturers putting shitty messaging interfaces on Android phones more than Apple for having a good messaging system.

I have Facebook Messenger, Messages (iMessage), WhatsApp, Signal, Hangouts, Slack & Discord all installed on my iPhone. Why hold back?

Every app is another opportunity to get a tracker on your phone. I like to limit how many native apps I have installed whenever possible.

iMessage has done more to hold back messaging in the US than anything else. Even if Google was competent at messaging it wouldn't matter because iOS users wouldn't switch and Apple refuses to open up iMessage to non-Apple devices.

I'm still using SMS for most of my messaging, and I primarily blame Apple for that.

Are you asking for Apple to pay for infrastructure for non-customers to use? Or even further, that Apple design and support an Android iMessage app?

If iMessage is a walled garden, then pretty much every other messaging system is also a walled garden since the death of XMPP. Can anyone build a a third party client for WhatsApp or any other popular messaging system in 2020? Im unaware of any. In fact the top result for “third party whatsapp client” is “Use a third party WhatsApp client and be banned for life”. [0] Hardly the behavior of an open system.

What your real complaint is that there isn’t an client for a nonApple operating system. It’s reasonable to not want to switch OSes, but there are many apps that are iOS exclusive, as there are many android exclusive apps, but I wouldn’t call them “walled gardens”.

Also, iMessage doesn’t make money. It an e2e encryption app with sms support. Because it’s provided by Apple, a company that famously makes money on hardware rather than services, there’s no incentive to mine your (and your connections’) data for profit, like say WhatsApp, or the others, so it is incorrect to claim they are “using & dividing people’s social connections for profit”. If anyone is dividing their connections based on iMessage, it’s your friends.

[0] https://www.cultofmac.com/314343/use-a-third-party-whatsapp-...

A bit of a late reply, but there were a couple of points that I wanted to respond to. The first is that I'm not holding up WhatsApp as a great example! I use, promote, and have done a bit of development on Matrix, a true open messaging system. If XMPP or IRC floats your boat, I'm all for that as well, and I'll be able to chat with you over the XMPP and IRC Matrix bridges because all 3 are open systems. Second is how high the wall of your walled garden is matters, and matters a lot. Sure I can't write my own WhatsApp client, but I can download the app relatively easily on both Android and iOS. To communicate with people over iMessage I would have to buy a different phone and accept everything that comes with it (including the rest of the walled garden, appwise, oswise, etc). Finally, when I said they were doing it for profit I meant that the fact that iMessage only works with Apple products makes it such that if you want a good communication experience with your Apple-only friends you also have to buy into the ecosystem, and once you have it's hard to get out because you might lose those connections.

> If iMessage is a walled garden, then pretty much every other messaging system is also a walled garden since the death of XMPP.

No whataboutism please.

iMessage is backwards compatible with SMS.

Are you talking about the unwillingness of users to migrate their chats to WhatsApp, Facebook Messenger, etc? That’s not a walled garden - that’s the natural hesitance to leave any comfortable/familiar system that any social media / network effect site/app has. It’s more like a psychological moat. And even the app you want Apple users to migrate to has it.

He's talking about the fact that iMessage only runs on Apple hardware. That's what a walled garden is.

ok? and googles messaging app only runs on android. the app doesn’t require the recipient to have imessage, however if they do you get benefits (like increased message size) over sms due to limitations in sms.

iMessage with macOS works fine on non-Apple hardware. Perhaps you intended to write iOS and the iOS version of iMessage only runs on Apple hardware? Or was it more a point of legality? Or end-user acceptance? Or availability to the general public?

>iMessage makes me fairly angry because they're using & dividing people's social connections for profit.

Can you point me to a company that doesn't do this? I would think "but $hardware to use $network" is preferable to "use $network for free, but sell everything you put on the $network"

Cohesion does not force you to lock your software to a single device. Why can Google Duo be available on iOS and Android, while FaceTime is locked to iOS? You know full well it's to force you and your family to stay inside the garden and stop you from leaving. Has nothing to do with cohesion.

> I'm a close-to-20-years Apple user. The walled garden has never been a problem.

Obviously it's not a problem to people inside the garden, that's the whole point. It's meant to be a problem to people who are outside, to get them to come in.

As someone who has never had any Apple product, every time I come anywhere near anything by Apple, it's nothing but issues. As mentioned above, any time I'm linked an iTunes album page, I can't do shit with it. I'm not going to install iTunes just to listen and purchase the album. Is it cohesion to force me to download and install a program to purchase an album?

I haven’t been able to get any one to use Google Duo. Isn’t it still only 1 on 1? Yes, it’s cross-platform, but if the cross-platform apps aren’t that good (Hangouts feels bulky, some other apps have more hoops to go through), that’s also saying something.

>The walled garden has never been a problem, more of a strength (integration, cohesion, etc).

>My music is in Spotify and Apple Music, my video is Netflix and Amazon Prime and Apple+, my email is Gmail, my eBooks in Kindle for Mac and iOS, I talk with friends with Skype, Facetime, Messenger and Whatsup. Even my iCloud apps (Calendar, email, etc) are available from any browser.

How do you actually benefit from the 'cohesion' in this situation, more say than my KDE/android setup which provides fairly seamless integration between my phone and computer?

One really egregious and incredibly frustrating example of a walled garden by Apple is the fact that I can't accept an invitation to view a shared iPhoto library unless I accept that invitation from Apple Mail. I'm using a Mac, I have iPhoto installed, there's no reason other than consumer-hostile behaviour to not allow me to accept that invite from Gmail in a browser. Hell, make me copy the link and paste it in iPhoto if I need to. Forcing me to use a particular e-mail client is just ridiculous.

And what company does care about the open web, no strings attached? Google and Facebook sure as hell don’t.

I’m not going to apologise for Apple, but I thought this sign in feature was iOS specific. They’re offering to proxy your email on their own account and buying an iPhone pays for that. It’s a privacy feature so that you can protect your personal email, it’s not federated auth.

A better example is that I think the Apple Music API is pretty robust now. That’s been some time in the making.

110% - Google wouldn’t let me use Safari for youtube TV or for Stadia. The open web is a total mirage.

Goes both ways. It shouldn't be too surprising that people don't bother testing against the only browser that isn't just a download away.

For all of IE's/Edge's faults (and there are tons), at least they offer public VM images.

> It shouldn't be too surprising that people don't bother testing against the only browser that isn't just a download away.

What does that mean? If you want to test Safari you only need a Mac or an iPhone, which Google has plenty of since they make native software for those platforms. If they want to test Chrome on a Mac, they can also test stuff with Safari on that same Mac.

> people don't bother testing against the only browser that isn't just a download away

Considering that a) Stadia officially supports macOS and b) most Google engineers use Macs, I don't think that's really a valid argument here. They just want people to use Chrome, full stop.

That does not apply to Google though.

Didn’t the Homebrew creator give some huge stat number for amt of Google employees who use Homebrew (so Mac) during the drama of him not being hired?

Most Google apps are available on both iOS and Android unlike Apple products. Compare Duo to FaceTime, Hangouts to iMessage, etc.

Stadia is still very early tech, it doesn't even support 90% of Android phones, let alone other devices and browsers. YTTV works on iOS, but yes the lack of Safari support is a bit shitty. Still, most of the limitation are technical, not forced.

If this feature were iOS only, how would you ever switch to a non-Apple device? Would you just have to leave all of your accounts behind?

I think this is meant for apps that ask for emails without really requiring them for the app to run. If you want to sync across devices, this is the wrong solution, because your random email isn’t random any more.

It’s not oAuth or SSO.

It's account federation, so no. You are still going to be able to log in with a local account or another federated authentication system.

Isn't this kind of in the DNA of the company? Even going back to its first decade, what distinguished Apple from other early PC companies was that its O/S was only meant to run on its hardware, and its hardware was only meant to run its O/S.

This obviously didn't work out for it in the late 80's and 90's. But its fortunes changed by the mobile device era. One challenge of this model is that you have to maintain execution excellence in not one, but two separate areas. Both your hardware and design execution, as well as your software engineering, have to be industry leading. If either one falls short, it brings down the other.

Ironically it didn't work out both ways: for a short time you could run Mac OS on non-Apple hardware, licensed and stuff, but all it did was hurt hardware sales while not making enough money to cover software engineering for the OS. Then again, a ton of stuff went bad for Apple at that time.

NeXT on the other hand was always intended to run on diverse architectures, not sure on the timeline vs. Windows NT, which had the same model (with the HAL, multiple kernels etc.). It's pretty sad to see that go away, but it also makes total sense; modularity and USP-as-a-service doesn't pay off and doesn't make users (the mass of them) happy. Loosely coupled but highly cohesive systems work best, it's why classic Mac OS completely failed in at the end of its life, and why all the other projects at Apple were a dead end compared to the *nix projects (and of course buying NeXT). It's also why NT worked, and why at some levels Android fails miserably. (but Google notices and started to fix the cohesion issue at the OS level with Android One and their patching methods vs. complete monolithic OS upgrades which then needs vendors to back port)

For this and many examples I think it's more ignoring those use-cases than maliciously blocking them.

> For the longest time you couldn't even preview songs on iTunes store without having iTunes.

I'm confused what the use case for this is?

> Want to watch their biggest WWDC live? Had to use Safari until last year.

Keynote streaming has had a long, weird history over the past decades. Even when Quicktime was dominant, they would only occasionally stream it live. My understanding over the past decade or so has been they've used "standards" to stream, but just the standards Safari had implemented. I just don't think they cared that much about getting it to any home users live.

> My understanding over the past decade or so has been they've used "standards" to stream, but just the standards Safari had implemented.

It's just HLS, which Chrome didn't support

I’ve long wondered why Chrome doesn’t support HLS (HTTP Live Streaming for those who don’t know) given that it’s been standardized for a while.

I get that we’ve got stuff like MPEG DASH and Web RTC now and so the use case for HLS is mostly fulfilled, but having a couple different options for streaming live video with low latency to massive audiences is nice and allows folks like me who have worked in this space to offer multiple options when designing a streaming systems.

Well, Chrome also "doesn't support" MPEG DASH: all of Chrome, Firefox, and IE11+ instead chose to support the Media Source Extensions API, which allows you to, with very little JavaScript glue, support any of these other standards you want, as well as new standards or custom streaming solutions. Apple, always the ecosystem's asshole, hardcoded HLS support into their browser and provided no way to implement any alternative as they refused to implement Media Source Extensions.

So no, Chrome should really not support HLS nor should it support MPEG DASH: Safari should just support Media Source Extensions. Apple finally did support Media Source extensions at some points on desktop Safari, which makes some sense as they effectively lost the war for the browser on macOS: no one was going to go to the ludicrous cost to support HLS (which would require you storing not just extra copies of all of your assets but also storing many copies of your audio as I am pretty sure HLS doesn't support separated streams) for Safari users given the existence and already-dominance of Chrome.

(FWIW, the cost of the duplicate storage was such a "bottom line" reason for websites to not support HLS that Apple finally decided to break a bit and support the MPEG DASH fragment files in Safari 10. It still is an extra implementation burden to support this hard coded spec and hobbles the entire industry to "whatever capabilities are sort of supported by HLS" instead of "whatever can be imagined on top of Media Source Extensions", but it no longer isn't "a major cost of our business operations is going to more than double".)

But, they still have not implemented it on iOS, because there they have control over the browser (disallowing any alternative) and are also a force in the mobile market you can't ignore (which is why this should be illegal). This means that you are forced as a content provider to support HLS so you can target iOS users (and before Apple lost, macOS Sadari), and that's the only reason anyone cares at all about HLS. HLS offers absolutely no advantages to MPEG DASH to anyone but Apple, and so would be dead if it weren't for Apple's active resistance to Media Source Extensions.

Keep in mind that while everyone always thinks that Apple does things to be an asshole or 'special' or whatever, it's far more likely that it was just coincidence or bad timing. Apply hanlon's razor and the wold is a whole lot less shitty.

Regarding HLS vs. the rest: HLS was developed around 2008 and published somewhere in 2009 IIRC, while MSE was at least 5 years later. At the same time; MSE has been supported since Safari 8 (macOS) Around 2015, according to WikiPedia, which is the same year FireFox gained support for it. Not sure about iOS.

Practically: Apple supports MSE and some DRM natively on the desktop just fine, and YouTube, Netflix etc. are using it at least since 2015 or thereabout. Also, most embedded video players in HTML5 just load a simple player framework that switches to the best available option. That might be MSE or HLS, but in the past it would also switch to Flash, RTSP and that windows media stuff.

HLS can be rather readily supported with a JavaScript library that works just fine on Chrome.

Imagine if Google would just "forget" to keep supporting H.264 on YouTube and only served VP9 unsupported in Safari and iOS.

I didn't want to get into it, but I was going to make the YouTube/Google comparison to keynote streaming an Apple. When YouTube moved off of Flash and added hardware acceleration, Chrome got first and best support with codecs and features compared to any other browser.

I did recently get a ticket where hls.js failed to render something that safari can play just fine, but it's the first time that's ever happened and the scale we're talking about it is massive. I kind of want to file a bug with hls.js

Oh there are Chrome extensions which inject JS HLS libraries, adding support to Chrome.

> I'm confused what the use case for this is?

I want to buy an album by an obscure artist that decided to only put their songs on iTunes. There is literally no way for me to by said album without downloading and installing a giant program.

They've seen fixed their web store and also split iTunes into pieces, but that was an issue for many years.

> Keynote streaming has had a long, weird history over the past decades

Sure but I'm not talking about decades ago, but even 2 years ago. In 2017.

> I just don't think they cared that much about getting it to any home users live.

Right, that's my point, they don't care about anyone outside their ecosystem.

Why would they care? What do they have to gain? While they are not the typical shareholder-directed company you'd normally see they are definitely still in it for the money. And since the market has shifted to services, ecosystem and larger user bases, there is no money or benefit to be gained from an investment to include people that are not your target audience.

That has shifted slightly since as a services company you can now make money without selling devices, and as other standards have become available (HLS was an Apple-only thing in the past, the rest had to use either Adobe or MS streaming stuff, unless you were into QTSS from 1995).

While there are plenty of things to like and dislike about Apple and what it produces, in the end, they are not going to care about people that will neither deliver money nor increased brand status.

Why does Google make Duo and Hangouts work on iOS and Android?

I'm sorry but outright making it hard for a non-significant subsection of people to buy music on your music store is just plain stupid. The only way to justify it is that losing such customers is worth it if it helps them keep their walled garden tight.

Because Google makes money by harvesting data and providing paid services to as many users as possible, while Apple makes money by selling a UX. It's much harder to sell UX to every possible market segment than to have varying degrees of UX and still make money off of just that. That's why the business models between them differ (just like Microsoft differs from both of them yet again - even if there are a lot of comparable practises).

> This is how they keep people in.

But sometimes, it also keeps iOS users out of stuff. For example, in Germany, Android has a market share of 70%. Hence, iMessage is useless here, because the majority can’t be reached. Thus, WhatsApp has the biggest market share for messaging services.

Now, it probably doesn’t matter for Apple, but it prevents the iMessage experience for most iPhone users in Germany, because it’s kinda useless here. I guess the same is true for most European countries.

> And once you're in, they make it as hard as possible to leave.

Nonsense. On my Mac, I can export all my pictures from Photos as jpeg (or several other formats); contacts as .vcf; calendars as .ics; documents in several portable formats; my music is in iTunes as (unencumbered) mp3 or m4a, nicely organised by Artists and Albums; emails are in traditional .mbox files, unless I'm mistaken, but at any rate mailboxes can be exported; even Messages are available in some directory in the Library folder, though in an ugly XML-y format; etc.

I don't know how easy other OSes make it to "leave", but you can't really argue that Apple is trying to make it hard (except by making the garden more beautiful, safe, and well organised than the others).

I use a mix of Apple and non-Apple devices. It's a shame that I can't, for example, use Safari on Windows or Android.

Firefox might be the answer or cross platform applications. Always good to get out of the ecosystem when you can.

I've been using Firefox for the last couple of months but I'm not satisfied with it. I'm using Brave now but it only syncs bookmarks... I'm using a password manager but it doesn't sync extensions, autofills, settings, etc.

What are your problems with Firefox?

Major issues:

1. Lack of multilingual spell checking (without having to manually switch languages). For non English natives this is a must since we write in at least 2 languages every day. There is an extension that tries to solve this but it is quite slow to the point that I've had to disable it.

2. It just feels slower than Chromium browsers and Safari, at least on macOS. In Windows it's blazing fast but I have a Ryzen 3700X there.

3. On my MBP I get random CPU spikes from time to time and I'm forced to close and reopen FF. I haven't seen this in my iMac or Windows machine. I've never experienced this with any other browser.

4. On Android FF seems to be a battery hog. I haven't done any serious measuring but since I switched to FF my battery has gone from 3-4 days between charges to 2-3 days.

Minor issues:

1. I think the UI is inferior to all other browsers

2. I've had sync issues. I try to login to a website and for some reason FF will not write the credentials unless I manually sync. This has happened in iOS and Android.

3. I've had several minor issues on iOS. For example yesterday there was a weird bug in Twitter with the keyboard suggestions. I know it uses WKWebView under the hood but Chrome for iOS does not have those issues.

4. For some reason Mozilla decided to remove an extension that I use very frequently called UI Stack.

There used to be a Safari for Windows. No one used it so Apple dropped support.

More specifically, Apple never made it good enough compared to alternatives, so no one used it. It eventually died at the hands of its maker.

IMO what killed it was the text rendering. They brought their font smoothing over from Mac OS and that's not what Windows users are acclimated to.

It might be more "correct" in some ways, especially from a graphic design / typography standpoint, but it looks fuzzy when you put it next to ClearType on the same screen.

https://damieng.com/blog/2007/06/13/font-rendering-philosoph...

https://blog.codinghorror.com/whats-wrong-with-apples-font-r...

Well, there was Mac GUI toolkit for Windows, which Safari and iTunes used, wasn't really Safari for Windows

I would rather have a delightful user experience than multi platform support. Worst service to ever come out of Apple is Apple Music because it is multi platform. Their desktop app is just a shell around their BETA web version. Sluggish UI, memory usage goes up to 4GB easily...They didn't even try...all in the name of making it easier to support multiple platforms.

Sounds like they did not make a modicum of effort to support any platform.

iTunes was multiplatform (Windows & OS X), if Apple wanted they could invest the resources to do so for Apple Music. Apparently it is not a priority tho

wanted the app to have the same options across platforms

I guess this is the part I don't understand. How did you plan to test across platforms if you don't have an iOS device with which to test?

I don’t know the author, but in a typical company, a project that is meant to work on iOS and Android will be dispatched to separate teams.

In this case, the author might be part of the Android team, instructed to make Sign in with Apple work on Android, and they may not even be in the same physical location as the iOS team.

But, if he's at a company with the resources for 2+ mobile dev teams, surely he could convince his manager to purchase an iOS device? We have several drawers full of mobile devices for testing our web apps. Our mobile dev teams have their own piles of devices. It's a cost of doing business.

>In a typical company, a project that is meant to work on iOS and Android will be dispatched to separate teams

Truth. And why cross platform tools like React and Flutter are just getting more popular.

I’m right in the middle of making that choice right now. But it’s definitely clear I can’t support true native apps.

They might mean their website rather than iOS.

> To test I needed an Apple ID with 2FA.

Apple make it such a pain in the ass to get Apple IDs. For example, they block emails from small domains. So I can't use my company email address to get an apple ID.... and I found that out by googling cryptic error messages, they don't even tell you.

They don't want you to have multiple Apple IDs, so you need to store the credentials of your main Apple ID on your build server if you want to notarize apps (which is required for distribution). Also, the notarisation service doesn't support 2FA, so you need to get an app-specific-password that bypasses 2FA.

It's ridiculous. Their security system is so complex and full of holes...

You should be using this:

https://support.apple.com/guide/apple-business-manager/what-...

https://support.apple.com/guide/apple-business-manager/creat...

Not the consumer Apple IDs. This lets you programically generate the Apple IDs (you can even set permissions on them).

Works great.

Not that they've made it straightforward to make it explicit who should use what, or anything, but they do have solutions for this. It also has other perks (like being able manage distribution of your app)

To be fair to anyone, the Developer Documentation does not talk one bit about this, at all, as a solution.

I guess this also requires an organisation/business account? Because I can't get that either, because Apple doesn't allow sole proprietors like myself to get a business account. I can only get an individual account. Which means that I can't add my employees to my team.

Only a DUNS number, IIRC, which any registered business can get for free

This is news to me. My apple ID is on my personal domain (Google Apps) with only one email address on it, and it works fine. Could it be a recent change?

About 6 months ago I was unable to use my email on a personal domain to create an Apple ID. I had to create an @icloud.com address. And I don't think it's an issue with my domain, it's been fine for the last 9 years.

FYI you can normally change the email on an Apple ID after creation, without the domain restrictions that are present for initial creation.

Great to know, thank you

In my experience it's randomly prohibited by some algorithm.

> SMS 2FA was not good enough, you need the hardware-based 2FA

OT, but Apple is doing the right thing here: SMS is not a robust 2FA solution. A recent discussion: https://news.ycombinator.com/item?id=22016212

Their approach is still ridiculous. I once tried to log into a brand new iOS device in a shop, and has unpleasantly learned that I absolutely can't log in using my regular Apple ID, cause, you know, they are showing a popup with code on my Mac which is 50km away.

That's... how 2FA sans texting works in the Apple ecosystem, yes. It's working as designed.

That's exactly what I am complaining about: it is designed badly, I didn't ask for this and I can't turn it off.. I didn't ask for this, and still can't turn it off.

On the other hand, Google does even worse: sometimes it requires 2FA with SMS when I have specifically turned it off, knowing I'll be abroad without SMS connectivity. Still, Google doesn't give a shit on disabled settings and still demands 2FA auth on connects from previously unused addresses. The only reliable way to circumvent this is to use a VPN with a fixed address, so Google always thinks it's a 'same' location.

PSA: If you're going to implement Sign in with Apple, PLEASE implement Sign in with Google (and vice versa).

This is the EXACT issue we had when Apple Pay/Android Pay came out. The solution was for POS vendors to just implement both, always.

SO, that's the solution here.

But Apple Pay and Android Pay both use identical underlying technology, don't they? I.e. it's not possible to support one without the other, because they are the same.

By default, supporting one means supporting the other, but in practice, several large chain stores deliberately disabled ApplePay specifically at first, hoping to choke it off. That seems to have failed, and I can't remember the last time I saw a place that took contactless payment but not ApplePay, but it was a thing for a while.

Do you know of a source where I can read more about this (particularly about the stores disabling Apple Pay)? I'm interested in learning more. I was under the impression that any terminal that accepted contactless payments would also work with ApplePay.

https://www.macrumors.com/2014/10/25/cvs-disabling-nfc-apple... mentions Rite Aid and CVS disabling all contactless payments, after previously supporting them, shortly after Apple Pay launched.

Yeah, it's all or nothing, they disabled all NFC-based contactless payment just to stop Apple Pay from working.

in practice, several large chain stores deliberately disabled ApplePay specifically at first, hoping to choke it off.

This is FUD spread by Apple after poor uptake of Apple Pay. The reality is that many retail chains and restaurants either hadn't enabled the NFC chips in their payment terminals, or were using old terminals that didn't even have NFC functionality, and thus did not work with Apple Pay. Retailers that supported NFC payment prior to the launch of Apple Pay supported Apple Pay at launch.

Retailers are not about spending millions of dollars to upgrade working point-of-sale machines just to make Apple more money.

According to news reports from the time, both Rite Aid and CVS initially supported NFC payments (at least at some locations), then proceeded to disable them shortly after Apple Pay launched:

https://www.macrumors.com/2014/10/25/cvs-disabling-nfc-apple...

Best Buy supported NFC payments generally until Apple Pay launched in 2014. After that I saw the NFC logo on their terminals still, but every time I tried to use Apple Pay, it would report an error. Cashiers told me each time that "Google Pay" would work, but not Apple Pay.

Perhaps they were lying, or mistaken.

But you were specifically calling out my claim of chain stores deliberately eschewing Apple Pay as FUD, which is weird, because they were quite open about it at the time. Walmart has kept up their QR-code-only approach, while the others gave up on CurrenC eventually.

You seem confused. Apple Pay works using the exact same tech as contactless payment cards, a widely supported standard.

Doesn't matter, you can configure the terminal to block certain issuers, like when you try to tap your Amex and get the "no supported applications" message. ApplePay is considered an issuer like the others.

This is false...

The store chooses which credit cards to accept (at the birds-eye level, i.e., Amex, Discover, Mastercard, Visa), and the POS sends the transaction to the appropriate card processor based on the identifying digits in the card number (the first 4).

Apple Pay transactions are identified as Visa transactions, so Visa would handle the transaction...if the POS terminal is configured to accept NFC cards. Most older ones don't even have NFC functionality, and until 2 years ago even terminals with NFC functionality didn't have it enabled because they were shipped before NFC payments was a thing. Today, almost all POS terminals come with NFC payment built-in and enabled.

> Doesn't matter, you can configure the terminal to block certain issuers, like when you try to tap your Amex and get the "no supported applications" message.

What's the deal with that? I've pretty much given up even trying to tap with my Amex because of how frequently it gives that message.

Doing it through Firebase might be easier: https://firebase.google.com/docs/auth/ios/apple

Maybe I'm missing something but isn't that iOS only?

https://firebase.google.com/docs/auth/android/apple

Ah thanks!

> Seems like a nice sign-in option for iPhone owners but it's a portability disaster.

So basically it's like everything that Apple makes

Not to be that guy but you can get a used iPhone SE for $75, and it should last you a couple years for testing purposes.

Really, you need an iPhone model with each of the iOS versions you want to support on that hardware. If you want to go back to iOS11 up to current, then you need that many devices. Otherwise, because it works on that hardware and iOS combo doesn't mean it will work on a different combo. So it's $75 multiplied by the number of variations you want to support. It adds up quickly. As others have stated, it's just part of the cost of doing business.

And you can't forget - you need to get at least one with the silly notch in it.

Oh, and don't even consider emulators - the iOS device emulators are trash.

Edit: a lot of people are asking how I am working on a cross-platform app but I can't afford an iPhone / Mac to test on.

To be clear I did resolve this situation with the Apple ID by asking an iOS-focused teammate of mine to test the app for me, that's somewhat besides the point though.

I was trying to add a feature, Sign in with Apple, to my Android app. This is supposed to be possible. It turns out it is, but it was significantly harder than adding any other form of authentication to my app than I've ever tried.

If they want it to be developer friendly they could:

  * Allow the creating of "testing" Apple IDs without the 2FA requirement

  * Have docs that actually mention best practices on non-iOS platforms

  * Maybe even provide a basic SDK

I wasn't calling Apple evil or saying I couldn't afford a Mac, I was just calling out a bad developer experience.

> As an Android developer I have no reason to own either of those.

Of course you do: Please implement this iOS application/feature in Android.

Not being able to run an application from Xcode onto an iOS device severely hampers your career. I have to deal with so many Android developers and their output I absolutely cannot afford the luxury to not run Android apps from Android Studio.

I don't think Sign In With Apple will be a huge hit on Android anyway. But perhaps you could share your code on Github for people that run into the same requirements?

Anyone with a computer can get Android Studio for free in 5 minutes. You can't download a free iPhone.

The Simulator comes free with Xcode. And it's actually pretty usable in terms of performance compared to the Emulator you get with Android Studio.

Either you get a $75 iPhone SE or you have something for free with your MacBook. Anyone with a computer still wants to use a hardware Android device for any serious testing. And then there's the differences between all of the builds between the brands. I bet you want to test on a Xiaomi before you want to declare that push notifications work.

> your MacBook

Yes, this is the expensive part. Obviously if you are developing for iOS or porting an iOS app then you need the hardware. But it seems like an unusually high barrier for implementing a "sign in with" button.

I hate that I can't use Xcode on Linux.

The real problem is that it's origins are making NextStep applications which you would typically do from a NextStep workstation. Still every Xcode update is coupled to the OS version because of that. I guess we need to be grateful that we don't need to install macOS betas to target the beta version of iOS.

I have no idea what you're trying to say. Is the comment on career an insult or genuine?

If the only thing you want to do is pull really detailed tickets from a JIRA queue and work on that until they go to the QA, that's fine. But you're stuck on medior level.

As soon as you're going to be involved in designing or building back-end API's and features that cross a lot of layers not being able to run applications from Xcode and Android Studio and understanding the other platform no matter if you're an iOS developer or Android developer limits your career.

I need at least to see what my Android developer did for me before I can accept his or her work. That's what happens when you go up the ladder. That's why I have the full toolchain on my computer and obviously bought an Android phone.

This isn't really a fair comparison because any OSX user can just download and run Android studio for free, while your average Android programmer would require over a thousand dollars (to get a bottom-level Apple device with the worst specifications, or closer to two thousand+ to get competitive hardware) and then a yearly subscription to XCode at $100/year, and that's without having any actual iPhones to test on as well.

So it makes sense that for you, spending $0 to test on Android makes sense, but on the flip side, Apple has intentionally engineered their developer program to have a four figure entrance fee, and frankly most indie developers can't shell out potentially several thousand dollars on OSX/iOS devices and licenses just to do some testing, especially when as the developer above said, "they can ask a friend to test".

> ... and frankly most indie developers can't shell out potentially several thousand dollars on OSX/iOS devices and licenses just to do some testing ...

Sounds like these so-called “indie devs” who cannot afford to build for iOS devices should not tackle projects/clients that require building for iOS. Or, if a client is in the mix, bill the client a large enough fee to cover the cost of testing on real devices. That’s not a problem Apple is responsible for solving.

I would never rely on developing, testing, and releasing an Android app on a simulator alone. I don’t want to buy a bunch of Android devices. So I don’t take on work that is meant for Android, or I hire people who can properly test on devices. Pretty simple—and it’s both my choice and a matter of professional responsibility and accountability to ship work I can stand behind.

Apple isn’t going to change any time soon. I’m so tired of the disingenuous moaning from “indie devs” who want to take on projects for and make money from iOS, but can’t be bothered to get over their own personal anti-Apple feelings to buy a device.

The ecosystem of Apple devices are hardware and software. The simulators and build tools are never enough. You wouldn’t ship an app for Apple Watch without testing it on a watch, would you? Or would you ship it relying only on having one friend with an Apple Watch test it? Sounds lazy and unprofessional—and if an indie dev can’t do the job right, they shouldn’t take on the job.

How much revenue will you generate from supporting Apple users or implementing Apple features? Bottom line is you run a business as a developer and if you can’t afford to spend, maybe a couple hundred bucks then you probably shouldn’t be in business anymore. Companies have no obligation to give you things for free.

As a hobbyist, thank you for your sympathy

On the flip side, 80% of all devices sold are Android and Android devices are the majority of sales, web usage, etc so there is no obligation for any developer to support the minority of devices and users at extreme cost when they can already achieve mass coverage.

That razor cuts both ways, and I'd point out that this situation is very similar to how OSX comes with Windows bootcamp, but a Windows 10 machine can't run OSX. If you run OSX, running Windows is something that you might just have to do. But if you're a Windows user, outside of walled garden development, there's not much point to OSX

Yet despite all that, we’re still having this conversation and a single iOS feature has hit the top of Hacker News.

While Android may make up the majority of devices worldwide, Apple devices are still very popular among wealthy clients (anyone living in the west would meet this criteria), which is ultimately the part of population business care about most.

Simply put, supporting Apple devices is very profitable. No company is going to leave money on the table due to niche ideological concerns.

That's slightly dishonest, as iOS has a ~50% market share in the US. Ignoring half of the US market seems a poor choice.

https://www.statista.com/statistics/266572/market-share-held... https://gs.statcounter.com/os-market-share/mobile/united-sta...

> On the flip side, 80% of all devices sold are Android and Android devices are the majority of sales, web usage, etc

That's nice if the only thing you do is selling eyeballs with adware. If you're actually looking to make money in sales you'd be a fool to not support iOS. I'd call it an obligation to your wallet.

Xcode can be downloaded for free, developer accounts are also free. What isn't free is shipping stuff to users in any form unless you're part of a development team.

My first MacBook (used for Xcode that is) costed 250 dollar coupled with a 200 dollar iPad 2 around 2013-2014. The iPad 2 was stolen and the MacBook 2008 kept working until around 2018 but was replaced in 2015.

But the grandparent simply needed to test a login feature that required iCloud. Any iPhone would do.

You don’t need a subscription to test iOS code, FWIW.

> while your average Android programmer would require over a thousand dollars (to get a bottom-level Apple device with the worst specifications)

A new one, sure. You could buy a 2012 MBP on Craigslist for $200, and a refurbished iPhone 6 for $50 or less.

Professionals in all fields have to spend money on tools. That’s business.

Interesting justification/rationalization for the extraordinary cost of supporting the minority of users. Paying the Apple Tax is a cost of doing business in the Apple garden, but for folks outside of that walled garden, the extraordinary costs of Apple hardware (often sold at 3 times or more their cost!) usually isn't going to make business sense.

If you're going to be a mobile developer, supporting the android 80% is far cheaper and easier than supporting the iOS 20%. It then shouldn't be a surprise if the 80% get better support than the 20%.

You’re an engineer who wants to implement Apple features, yet you don’t want to spend maybe, what, $200 for a test phone? These kinds of complaints are really irritating and disingenuous. My interpretation is that you’re more interested in complaining and finding problems than just buying a test phone and being done with it. It’s not that hard.

Why should anybody need to buy an iPhone to develop an android app? Using an API that is supposedly supported on android and shouldn't need an apple device?

Btw $200 is not throwaway money for everybody.

> Why should anybody need to buy an iPhone to develop an android app?

You don't, you can perfectly develop an android app without owning an iphone

BUT, if you're using features from another ecosystem, let's say something like an authentication system that has requirements, you have to fulfill those requirements, otherwise skip the feature.

Same goes if you want to support hardware-level U2F, you're gonna have to buy a key then.

It's different having to buy a device to test a product you are developing for that device. Apple is just gatekeeping access to their API to developers who buy one of their otherwise unrelated products.

> Apple is just gatekeeping access to their API to developers who buy one of their otherwise unrelated products

I don't know how that's news for anyone, Apple has been doing this forever and they explicitly chase that goal as far as I know.

If you're saying "yeah, I want to support iOS/Sign in with Apple/AirDrop/Screenshare/Any other Apple feature" then you're entering the need of having more things to do with Apple. That's the cost of joining and leaving the ecosystem they created for themselves.

Depends on how you look at it, really.

End users say, "I would like to be able to sign in with xxx." Developers say, "Your OS vendor doesn't want you to."

If I want to add "sign in with github" I need to read some docs, get an api key, implement the feature, done.

If I want to add "sign in with apple", I need to read some docs, then read a bunch of forum posts because the docs are incomplete, then go out and buy a used iphone somewhere, and you think that is completely normal??

My interpretation of this situation is that as an Apple user, Apple has done me a disservice by putting artificial barriers up that make it harder for third-party developers to provide me, an Apple user, good service.

I don't see any reason to defend that, it seems to be only in Apple's best interest, not mine.

Anyway, it's not $200 for a test phone, it's $200 just for a 2fa device. Meanwhile Yubikeys are $20 and have better battery life.

Well to be fair he wanted the app to have the same options everywhere. So regardless if he had a test iPhone, he wanted apple sign in to work on android. And probably vice versa too, google login on iPhone.

Personally not a fan of either, separate email/passwords everywhere is what I prefer. But I cant say I have come across a non-apple service/site that offered apple login.

For the purposes of authentication the closest equivalent Android side is "Sign in with Google" which can be done with 0 dollars and is a pretty straightforward and well documented API call that has specific SDK support in a lot of languages and settings.

Developer of a recently launched app with Sign in with Apple here.

I watched the keynote where they launched Sign in with Apple and was honestly surprised at how easy the implementation was. I thought it was a no-brainer to add it to my app. So, I follow their (severely lacking) docs and the keynote and get a solution working. Once the user logs in, their APIs hand you a token that you can then send to the server.

Then, I thought, how do I verify this token on the server? While they do have docs on it [1], they simply omitted it from the keynote to make their example "just work". I would be very surprised if everyone was verifying the token on their servers. Not doing so seems like a loophole for many apps.

[1] https://developer.apple.com/documentation/signinwithappleres...

They didn't include more information because they implemented the OpenID Connect specification which is awesome. That means that you can use any OIDC library and it will work for Apple, even verifying the keys. If you want to know more you should read up on OAuth2/OIDC/JWKS.

Apple's public key can be found here.

https://appleid.apple.com/auth/keys

Unless I've missed something, it's worse than that: even if you do verify the token, it only lasts for ten minutes, so you are obligated to tie it to some other form of auth unless you want your users to re-authenticate every ten minutes.

However many developers can correctly follow the meager instructions to validate a token, the number who will properly implement a full auth system is even smaller...

Well, it is called "Sign in with apple", not "Sessions with apple". Keeping sessions in a secure way is on the developer.

What are the security implications of this?

The biggest one is that you're essentially trusting data that the client is providing (Apple gives user id to the client and the client sends it to the server). Unless you can verify the token and exchange it for your own session id, you're opening up your users to be easily impersonated (if they get a hold of the user id).

Other than that, Apple also provides server-side verification for the validity of the token. Without that, the client could send a random string and the server wouldn't know the difference.

Why would someone be more likely to get a user id compared to your session id?

It depends on what the app does and how it does it.

The first step (authenticating) returns a token with your app id, user email address, a unique user id, an expiration time 5m from issuance, and various other info.

Suppose the token is not verified. If the app only uses the email to identify a client, then a malicious/compromised user could pass your app a forged token to access another user's account.

If the app uses email and id, but not the other fields, then a replay attack is possible on a compromised user: the eavesdropper could simply send along an intercepted token to identify as the compromised user. If the timestamp is checked, this gets harder but is still doable.

The other benefit: once you have verified the token, you can also refresh it in the future (1/day max) to silently re-verify the user. If you instead "re-"verify by repeating the initial credential issuance process, the user will be prompted for 2FA verification.

How does someone eavesdrop on the session?

100% agree with this. I had to develop a system to accept Apple tokens and validate them in exchange for our own system's token. When I did this the documentation was sorely lacking (looks the link you posted is fairly recent).

I've seen "Sign in with Apple" exactly once since iOS 13 launched. I am kind of surprised it's not being rolled out more widely. The first app I've seen and used it with was Byte (the Vine successor) over this past weekend.

Is there any good reason to do the Sign In With <giant data aggregator>?

I never take that option if there is anything else available. They don't need to see my signins on other sites, why should I just give it to them? For a few sites where it is utterly unavoidable I make one-off twitter accounts instead, because Twitter doesn't require your phone number to make an account and doesn't have a "only one account per person" policy I think.

Well, Sign In with Apple is different because:

1. It’s fast

2. It gives you a pseudonym

3. It doesn’t leak all your other social graph data

4. Doesn’t require a new password

The rest are:

1. Faster than creating an email, but will require redirects, and possibly logging into fb/google

2. May give you a pseudonym but often reveals your real name

3. Are used typically to build profiles of you and create stats on app popularity across demographics

4. Don’t require a new password.

Maybe it's just me, but one bummer about this kind of system is that's is A+ top security for a lot of stuff I don't care about. To create some account on a random forum to give feedback about how I got a stuck oil filter off of my '03 Civic, for example. With email+password I can just use a low security password because I'm typing on a phone. With these all-in systems my device isn't recognized so I'll need to type in some code from 2FA and type my long, unique password.

I know they're very popular, but there's so much long-term unintended baggage with using these singe signon systems...even assuming Apple's doesn't have the nefarious parts most others have.

Even setting aside Sign In With Apple, why are you consuming mental space and energy with a reused password and whether they should be throwaways or not in 2020, when all mobile OSes and desktop browsers integrate seamlessly with password managers?

Over here, I just use Face ID and 1Password does the tedious filing-and-remembering part that computers are good at.

I use 1Password on both my phone and desktop for logging in. Saving a new password on the desktop is easy. For the phone it seems rather tedious. Especially when, even on the desktop, many sign up pages have me submit 2 or 3 times because the username is taken, password too complex, or I didn't give them my phone number. I find it way less mental space and energy to reuse a weak password.

Sign in with Apple has the advantage that the service on the other side of the auth window doesn't get to see you actual email address. They're provided instead with an anonymized email address from Apple that serves as a forwarding address for you.

It's also easy in general to revoke permissions with these SSO providers rather than dealing with whatever the service's account cancellation protocol is.

What’s cool about that anonymized email address is that even if it gets leaked, only the registered service can use it to communicate with you.[1]

[1] https://support.apple.com/en-au/HT210318

Does this just cement you too apple? I'm assuming if you lose your Apple address, you have lost all linked addresses?

In most sensible authentication flows, your email address is not the primary key on your account, but rather just a credential with a link to an account, where an account HAS MANY credentials. You can usually "Sign in with X" and then "link" your now-existing account to credentials from "Sign in with Y" and "Sign in with Z."

Apple IDs can be arbitrary emails, and can be changed at any time (https://support.apple.com/en-us/HT202667).

I suppose it does. In the same way that using your gmail address to sign up for anything cements you to Google. But unless Apple or Google suddenly go out of business, I have a hard time seeing a problem with this.

Login fatigue. Yes, I use a password manager (1password). But it means I need to stop going through the sign-up flow, jump over to the password manager, create a new login, change the password recipe from random-letter to random-word (which I prefer), generate a password, then go further modify it to accommodate the site's particular password complexity rules (upper/lower/special/numbers), add the URL, save, then go back to the sign-up flow to finish.

And... 90% of the time, that's what I do, because I prefer to have separate logins for every site.

But sometimes, I just click the 'sign in with google' because it's a hell of a lot faster and easier.

Hear hear. I’m amazed 1PW hasn’t defaulted to random word recipes by now, as well as providing checkboxes to fold in all the upper/number/special character rules, or min/max length. (My passwords usually look like this nowadays: “turtle megaphone house 6@B”)

Twitter does require your phone number to make the account sometimes. (I suppose if it can’t determine enough about you.) Recently I was able to make one, only to be locked out a few minutes later until I “confirmed my identity” by providing a phone number.

Do you signup with your self-hosted email?

I don't think I've ever seen it. I have, however, seen Apple Pay on the web a few times (and in apps many more times), and that has been a great experience.

Apple Pay on web is fantastic. I don't use an iPhone, but specifically use my iPad for online purchases from any retailer that supports Apple Pay.

I don't think I've seen it either. What I have seen are requests for my App Store password on occasion when I launch, say, Google Maps. It's infuriating because when I'm out in the world, I don't have access to my passwords and I don't remember them.

It's a sign in to Apple, if not a sign in with Apple, and it's weird because what I'm trying to use is Google's Maps application without signing into anything. What is going on with all of this?

I think that the point of using Sign In w/ Apple is to prevent you from having to remember more than one password. It is only used when you would have to create/remember a password anyway so it won’t get in your way when you are out an about any more than signing in with Google/Facebook or your own email/password.

Turns out it's only required if you already exclusively use FB/Google sign in (I thought it would also apply to your-app-auth+FB+G but I guess not) https://developer.apple.com/app-store/review/guidelines/#sig...

That's not true. Any social sign-up except given exceptions will require SIWA.

Where "given exceptions" are mostly limited to obvious situations, like using Twitter signin for a Twitter client.

Huh, that was not my understanding, and your link goes on to state:

> not required if...Your app exclusively uses your company’s own account setup and sign-in systems.

So there’s no official guidance on the both/and case?

I interpret that as:

- If you only have social logins, you must implement apple sign in.

- If you only have your own login, you don't need to implement apple sign in.

- If you have both apple sign and your own login, you must implement apple sign in.

> - If you have both apple sign and your own login, you must implement apple sign in.

I would think that too, but the text is odd by saying "exclusively"

> Apps that exclusively use a third-party or social login service

I think you meant

> If you have both social logins and your own login, you must implement apple sign in.

which is my understanding as well! Would be nice if they explicitly handle this case as it's probably the majority.

The deadline to make it mandatory for apps and that use google and Facebook is still a few months away if I recall correctly

Yes, that's what i read also... so hopefully in a few months all apps that have 3th party logins like Google and FB are required to add SiwA and we will see a spike in popularity too...

I'm not sure I'd notice if it rolled out to a lot of the apps I use, though. I mostly stay logged in for things that don't require login every use (lastpass, banks, etc).

The rollout for Sign in with Apple was a disaster when it came to email deliverability. They seem to have given zero thought to people who used third party email services like CustomerIO or Sendgrid, indicating that they "weren't supported," leaving those providers to scramble to meet the strict DKIM / SPF / Return-Path requirements. Not only that, but if you were sending from an appropriately aligned and verified domain, in the first couple of weeks, deliverability might take in upwards of 12 hours for receipt. I believe they've since improved on the deliverability and the third-party email providers have accommodated appropriately, with Apple even providing brief integration tips for the most popular ones, but it left a pretty horrible taste in our mouths as we were jumping through all the integration hoops.

EDIT: This is referring to email deliverability when attempting to contact private Apple relay addresses.

> It’s utterly private, where signing in with Google or Facebook is not at all, yet far more convenient than signing up with your email address.

What is different in the privacy design of 'sign in with apple'?

> At your first sign in, apps and websites can ask only for your name and email address to set up an account for you. You can use Hide My Email—Apple's private email relay service—to create and share a unique, random email address that forwards to your personal email. That way you can receive useful messages from the app without sharing your personal email address. Only the registered app or site developer can communicate with you using this email, and you can turn it off at any time.

> Sign in with Apple won’t track or profile you as you use your favorite apps and websites, and Apple retains only the information that’s needed to make sure you can sign in and manage your account.

From https://support.apple.com/en-us/HT210318

Interesting - Apple is requiring that you register sending domains as an app developer. So even if your email address database leaks (or you try to sell your user data), only messages that are from your domains and pass SPF/DKIM would be able to send to those addresses. Really smart. I wish Google Oauth would support something like this!

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

As a application owner, I won't see the users email, instead Apple generates a unique address for each signup. That email also redirects any emails to the users email.

For someone who doesn't like a lot of what Apple does, this is a really nifty feature.

We just started integrating "Sign in with Apple" last week and are about to deploy it. Discovering the shielding of email addresses was a happy discovery, which I haven't seen before.

What happens when the customer contacts you for support and is using the shielded email service. You don't know the "real" email for the account, and the customer can't email you from the "shield" email. So you have limited means of verifying they are who they say they are. So how do you for disclose account information to them if you can't be sure they are the account owner?

I assume what Apple would like you to do is to build an "open a support ticket" flow into the app itself, which either asks for the customer's "contact email", or allows correspondence directly through the app. Such in-app support flows are already pretty standard for e.g. mobile carriers' apps, I've noticed.

You send them an email to the address associated with to account with a verification code.

When I used the feature with Byte it gives you the option whether you wish to mask your email address or send your real email address.

Is this on Apple's side of the authentication? Because if you implement the web version (on a non-Apple device) and login with credentials, you don't seem to get a choice, it always uses a masked email address.

Yeah, gives you a choice when you login with iOS.

Then again most application owners won’t be that happy they have one less data point to sell.

I think if you look at most application owners (not the top 1%/10%), they don't care that much about selling the data to someone. Better to use it themselves to gain better understanding. And as long as you can reach the user, it's good enough.

But maybe I'm naive, or biased because of my location and personal wants.

Here's a link for ya:

https://support.apple.com/en-us/HT210318

In essence, Apple generates a unique email address through their relay service that forwards to (and thus hides) your actual email address. It was widely considered a pretty major step in the right direction for user privacy.

How does account recovery work?

If you signed in the Apple, it would be through Apple's recovery process.

Sounds like it is good for privacy, unless Apple decides to snoop?

If you're using iOS or macOS, Safari, etc. you're already trusting them significantly. This avoids introducing a third-party who otherwise would not be involved in the session.

Well, as is any online service. I think the idea is the site you sign up with doesn't know your actual email address.

"Utterly private" is a very odd term here.

At the very least, Apple knows which sites you're signing into, and has the unique e-mail addresses used at those sites, and has likely issued the authentication tokens for those sites. I'm not sure what's "utterly private" about this setup.

You are already trusting Apple regardless if you are using iOS.

Your email isn't revealed to the site, so it's privacy from the site you are signing into. Although I'm sure they are still requesting basic info like name and potentially age.

As covered on Macrumors [1], you have the option of using a unique generated email on Apple's servers which then forwards to your own email without the service provider getting any info about you. You also have the option to choose what data, if any, you share with the service.

[1] https://www.macrumors.com/guide/sign-in-with-apple/

So is the unique generated email one-time use or it's persistent? Also, if an app owner gives that generated email address to a third or fourth party, and that party sends an email to the unique address, does the mail still reach my inbox? If so then what is the purpose?

The app developer has to tell Apple which domains are allowed to send emails to the generated address. If the domain isn't on the list, no emails will be received.

Ah ok. Pretty neat.

I feel like it isn't all that meaningful to compare Apple vs. Google vs. Facebook auth if the data is coming from a community that already has a favorable view of the Apple ecosystem, eg. the crowd that reads Daring Fireball. The majority of the global market at large is not using Apple devices and Apple sign-in is not going to resonate so strongly or even be a possibility.

If you are developing an iOS or Mac app, sure, that's a meaningful data point and feature suggestion. It won't be equally important for everyone.

1.5 billion active devices with all of them tied to an easy payment method is very meaningful. Also, the wealthiest 1.5 billion and the most willing to spend money on tech/app purchases.

This is a big deal. If you're trying to sell an app instead of trying to sell ads, Apple users is your target market, even if your app is web, native Windows, or Android.

I have a similar setup for signing up for services. I set up a custom domain with Fastmail with a wildcard alias that forwards all emails to my inbox. I can then sign up for services with a custom email like "hn-cbsks@myemail.example". If a service leaks my email, I'll know immediately and I'll be able to blacklist that address.

Yeah, I have the same setup for my self-hosted server. It's only a pain when I don't save the login info and need to go dig it up (or if I'm on mobile). If only I could make a custom "Sign in with" button on every site that tracked all that for me, while remaining self hosted, I'd be in heaven.

As a user, won't i

a) share my data with Apple (i.e. they get to know every time i sign in) and

b) makes me dependent on Apple (what happens to my account when i sell all my Apple devices?) ?

As a developer, it's our responsibility to provide users with at least 2 options. While Sign in with Apple is convenient and seems to be fairly popular, users should be in control of their data.

Some stats from my app where users have the option to either Sign in with Apple or use their phone number:

73% use Sign in with Apple and the rest using their phone number.

If it was a privacy issue, wouldn't people rather trust Apple than an indie developer?

I wish I could signup with just username and password (no email)... because gmail knows everything now (I don't mind having no password recovery option in many cases)

> a) share my data with Apple (i.e. they get to know every time i sign in)

They're only requiring this when there are other social login options available. It's not a bid to get access to your private information. It's designed to make it so you're not forced to share your information with Google/FB/Twitter. This existing is strictly better for users.

Ummm it's also strictly better for apple. They do get to know every time you sign in, instead of another company getting that. It's certainly not better for users than creating a separate account tied to a separate email for every service without a big company in between.

> It's certainly not better for users than creating a separate account tied to a separate email for every service without a big company in between.

Some apps don't offer this as an option and force social login. Apple's new rules require Sign In With Apple any time a developer has implemented another social login. So, strictly speaking, this always guarantees more options for users. And Sign In With Apple doesn't leak any other information about you to the app developer. This is a win for privacy, even if it's not the best possible scenario. The world is not perfect. Measures to make it slightly less imperfect are how we walk the path to a better future.

> what happens to my account when i sell all my Apple devices?

Apple ID doesn't depend on having Apple devices, and you can associate it with arbitrary email addresses.

I’ve only looked at the docs and not implemented it, but my impression was that if they leave the Apple ecosystem they lose access to your app.

I suppose this is similar to any other “Sign in with” option, but it just seems more likely people will ditch Apple before they ditch gmail or Facebook, since they can keep those around pretty easily without using them or paying for them.

For Apple you need to pay money and actively use it to stay in the ecosystem.

I mean if you sign into something with Google and then delete your google account you end up with the same result no?

Yes, but deletion of a Google account (for a lot of people, the core of their whole internet experience) has way different probability than getting a new, non-apple phone.

Yeah, but like I said, it doesn't cost much to keep a Google account around that you aren't using.

It costs a lot to maintain yourself in the Apple ecosystem.

Does anyone have any thoughts on the security (or other) implications of all your email for services in which you sign up using Apple SignIn now being relayed through Apple's mail servers?

It seems like a great way for Apple to hoover up a heap information they probably don't need.

I also wonder how they are going to combat bounces and send back a usable error message. While they can perhaps do useful things with say a mailbox full bounce they are probably going to have to hide or at least obfuscate some other kinds of bounces.

> It seems like a great way for Apple to hoover up a heap information they probably don't need.

This is not intended as a Platonic ideal of what authentication should be. Rather, it's intended as a better alternative to being forced to log in with Google/FB/Twitter, since those companies for sure aggregate and monetize your private information, whereas Apple probably does not.

App Devs probably want to soak up as much user info while they can. I don't think I would ever use it, seeing as I'm trying to slowly migrate out of the Apple ecosystem.

Not sure I follow your point. The whole point of “sign in with Apple” is to fight app devs getting more user info then they need.

How does sign in with apple work when switching to android? or using a windows PC?

Similar to other 3rd party signins, you get redirected to an apple signin form, and then redirected back.

Disclaimer: opinion/ venting my personal frustration ahead

Apple's implementation of the OAuth flow is incomplete (even compared to what their documentation says is possible) and buggy. We've found it very frustrating to work with. This may be one reason that widespread adoption of apple signin is taking a while.

Of course I expect the issues will be resolved with time

https://support.apple.com/en-us/HT210318

Sign in with your Apple account basically. It works nowhere near as well as on iOS or other Apple platforms, but I'm surprised they made it work.

You get a username + password dialog to write your Apple ID and password in.

Source: started integrating "Sign in with Apple" last week, I'm the developer and I'm using Ubuntu at work.

I've spent the last +18 months building a product that does this with even more privacy than Apple. It's called idvpn.ca and we assign a virtual ID (pseudonym) to you for each app/vendor you connect to.

This way if they're breached, you don't care and they don't care, yet we can meet any compliance requirements the app/vendor has such as age checking, sanction list checking, anti-money laundering, counter terrorist financing etc.

We're eagerly looking for vendors interested in beta testing our service, as we have a working product (using OIDC, and/or we easily integrate with Wordpress) and are looking for the MVP/business model now.

Sounds like you should have started your last step 18 months ago.

Getting it integrated on a scale large enough to warrant regular people using it and having it in more than one app they use will be the biggest challenge you'll face. Focus as much percentage of your resources as possible there.

I don’t understand how that is more private than what Apple offers? To my understanding, “Sign in with Apple” optionally also hides your true identity (ie. email address).

I've noticed it makes sign ups super easy which is great if you're building a new service and want to get users fast.

But what I wrestled with is the verification of the user on the server side after they've signed up (Apple suggests doing a daily verification of each user that uses Sign in with Apple) and also the annoyance of setting up trusted domains to be able to email your users.

Overall, it's great for users and for privacy but gosh it's a nightmare to setup for developers. Hopefully, Apple can somehow make it more seamless for developers in the future.

While I always prefer email/password sign-in when available, I've used Sign in with Apple exactly once. It's on a website that only offers "Sign in with <Google, Facebook, Yahoo, Microsoft, Apple>". Given that you don't need to log in to use 99% of this site's functionality, and this site serves a niche market with a small development team, I respect their decision to not try to roll their own authentication.

I'd rather they use oAuth than blunder their own implementation and risk a breach.

Sign in w/ Apple has been a great user experience. Something that always stuck in the back of my head when downloading and signing up for a new app was the stupid email confirmation.

Implementing this was a huge pain, had to turn off DKIM to get it to work. Almost no documentation and when your mails bounce there is no information whatsoever what went wrong.

From a user's perspective, I tried "Sign in with Apple" for the first time the other day on Dom Hoffman's new app Byte, and I'm really happy with it. Some benefits:

1. I don't need to remember a password to sign in

2. My real email is never shared with the service I'm signing up for

3. I had a new account in like 3 seconds without providing any personal information

If any Apple employees are reading this, you guys did a great job!

I wonder if this is due to brand/trust, that they only request an email, or the sign in flow is a popover as opposed to going to another app.

Social Sign-On has a low barrier to entry, you click a button and the necessary Authentication Context is transmitted by your Identity Provider (IdP) to the Service Provider (SP). An SP can't implicitly trust an email address and must ask for a corresponding password and also verify you control the email. In this case Social wins out for a lower barrier to entry.

Unfortunately the downside of Social is that the SP can request additional information about you from the IdP. And when the IdP is a SP, ask for permissions to interact on the IdP's platform on your behalf. Sometimes these requests are transparent to the user, often the user does not understand what's being asked and permits requests for access.

Social Login also allows the IdP to track your interactions across sites, and enables the SP to uniquely identify you across their own properties. An SP can also do the later via Email Authentication.

I think a lot of people are more privacy conscious today and/or have been burned by Social Sign-On. Sign in with Apple addresses those concerns and others that come with sharing your email address with an SP.

Apple forced some of the companies that rely on Apple’s platform iOS or MacOS to implement this feature, how is that not anti-trust?

Because A) this is good for consumers, and B) Apple doesn't have the market position to force consumers or other vendors to do anything. There is plenty of choice and competition in the smartphone market.

Apple forced nobody to implement this feature UNLESS they were already using another social media login option.

It is possibly an antitrust issue in an alternate universe in which our government still cares about antitrust issues, but since it's a net win for users, it might be a tough case to make.

Because no one has to use it. You can still use any other sign in option including good old email if you want.

Not true. If you use any other social media signing, you must also support Sign In With Apple. You can, however, continue to use good old email alone.

Developers have to implement it, But users don’t have to use it.

I use it absolutely in every app I can find. Plus the email obfuscation option of course.

No clue how popular it is but I quite like the idea.

It’s nice until you need to contact support when your apple account gets hacked and tell me your email is pdimitar at example dot com and I can’t verify that you’re a customer.

out of the 3 (google, fb , and apple) , having a fake FB profile is probably the best for my privacy. While FB may have tracked me they probably dont know my real name, while for apple it's mandatory, and most people probably have used their CC details with google at some point, plus these companies have my realtime location data as well. None of these systems are really private and it is a lie to tell our users that it is.

That said, SSO logins are replacements for passwords, not usernames. You should always ask users for their email afterwards if you don't want to be bound to the service's whims who may decide to block you from their service or impose weird terms in the future, like how FB requires various forms of verification / interrogation to continue using their platform.

> While FB may have tracked me they probably dont know my real name

It is highly likely they know exactly who you are via the huge amount of metadata you and those around you leak. I would be impressed if your "opsec" was good enough to evade Facebook.

Personally prefer it when I see it, but have only seen it twice so far. Much faster too since it’s native.

Disclaimer: I'm the founder of this service.

I wouldn't trust a closed-source solution to be the privacy-focused identity provider. And with "Apple Search Ads", Apple could also be considered as an advertising company.

I have actually started out to create a privacy-focused SSO solution named "Sign In with SimpleLogin" [1] before "Sign in with Apple" was announced. The solution is from the beginning meant to be open source and even self-hostable. It's superior than "Sign in with Apple" in several ways:

- The dev experiences is far better

- The random email part is customized

- Name, avatar could also be customized

If you visit the home page, you would notice that it's talking mainly about the email alias part as the SimpleLogin button is not implemented on popular websites yet, which hopefully will come soon.

[1]: https://simplelogin.io/developer

We have an on-going issue with Apple's protections going back almost a decade to when they started mucking about with 3rd Party Cookies. This isn't entirely their fault, blame also lies with the vendor we've chosen and our architecture for SSO.

That being said, there are valid use cases for tracking users across websites. I work for a nonprofit that does fundraising using every imaginable PaaS or SaaS platform as well as quite a few in-house developed tools. We offer an SSO experience across all of these various platforms and integration is a nightmare. OpenIDC, OAuth, SAML, ADFS, and lots of custom APIs.

It works for the most part everywhere except Safari where a few of our integrations just cannot and will not work due to their use of 3rd Party Cookies. Fortunately the way we've had to structure our solution, Sign in with Apple won't be much if any disruption to the status quo. It won't however help matters either.

That being said, there are valid use cases for tracking users across websites.

Strong disagree.

It works for the most part everywhere except Safari where a few of our integrations just cannot and will not work due to their use of 3rd Party Cookies.

It sucks to have sunk so much time and effort into a solution only to have external factors render it unworkable, and I feel for you. But it is entirely possible to implement SSO across multiple domains without relying on 3rd party cookies. I know because we use Apereo CAS, which is one such solution at my company.

https://www.apereo.org/projects/cas

> But it is entirely possible to implement SSO across multiple domains without relying on 3rd party cookies.

Yes it is, especially when you green field or have full control over the products. However there are times you do not have a lot of options when integrating with a vendor. Of course you can say "well choose another vendor" but that's not always up to you. Especially when you're dealing with legacy integrations.

Of course it's easy and we all have a fav sso projects but if you do not control the code it may not be possible

> That being said, there are valid use cases for tracking users across websites. I work for a nonprofit ...

Could you explain "valid use" more? I hope that you're not implying that we should allow all non-profits to track people across websites so they can do fundraising.

At WordPress.com, we have millions of sites. Having users be logged in so they can ‘like’ a post or comment or write new content is kinda important. That uses APIs and third party cookies (first party, but the API is a third-party from the perspective of the site they’re on). We are constantly dealing with Safari thinking it’s “tracking”. Disclaimer, we do track things, but only on admin pages, not users’ sites.

Well in our case we have multiple fundraising tools provided by a myriad of vendors (greater than 10). These tools vary in architecture (e.g. SaaS, PaaS, Turnkey, etc) and age. We also have a number of in-house developed products. We also have training resources that are exposed in different ways from Salesforce Communities to LMS based training systems.

Our fundraisers and constituents as a whole have access to these tools to interact with us. Some of the products are self service, others require authorization. All of them are branded and the users consider that they're interacting with us and not the underlying product.

So we have a situation where we need to Authenticate a user and possibly authorize them to access tools with varying roles and degrees of access.

If a user needs access to Tool A but can't until they've completed training in the LMS, we have a situation where we need to identify and track a user across disparate platforms.

It's not unlike having a Microsoft Account shared across Azure, DevOps, Office 365, and TechNet. Or a single Google Account to access Drive, Developer APIs, and Gmail.

They have three domains and want one sign-in on one domain to login to all three.

Normally they write a cookie the other domains can read.

I don't know about the plaforms you're working with, but I'm pretty sure 3rd party cookies shouldn't be necessary for OpenIDC. They certainly weren't for OpenID. If it's a problem, it's probably because of the specific platform intentionally did things in a way that was bad for user's privacy.

Unfortunately, non-profits I've seen tend to be really bad at privacy because they need to a) keep things cheap and b) have a significant presence on advertisement platforms.

I think you missed what I'm saying, we don't get a choice. We integrate with the best option we can from a given vendor at the time. And we don't always have the luxury to go back and refactor architectures. We have integrations we setup 10 years ago that are still functional today, and there's no valid business case to touch them until they break.

Some vendors use OpenIDC, others use SAML, others use OAuth, some even use WS-Trust, while quite a few use custom authentication based off something Google did in 2006. Many say they support OpenIDC, SAML, or OAuth when in reality they have something loosely resembling those protocols.

The landscape has changed a lot in the 15 years I've been mucking about in identity. Entire industries were born to deal with the fact that Google, Facebook, Microsoft, and Yahoo! couldn't keep their authentication APIs stable for more than 2 months at a time. 10 years ago you signed up with Gigya, JanRain or Ping so that you didn't need a team of developers to actively maintain your SSO integrations with 3rd parties.

Definitely a situation of non-nefarious uses getting nuked along with the nefarious ones. Not sure I would really blame Apple as much as all the horrible people who made it necessary for Apple to build this. They probably should allow more fine grained controls, something like "I know and trust these websites, don't nuke their cookies all the time" setting.

> Not sure I would really blame Apple

I don't. They have their users best interests at heart and their solutions have always left the functionality we needed there but that still doesn't mean they haven't been a thorn in my side by evolving their platforms.

unfortunately there are very few apps so far that allow signing in with apple even though i see them offer email, google and facebook options. i think out of all of the apps that i use only adobe lightroom allowed me to sign up with apple.

My understanding is that "Sign in With Apple" is still officially in beta; once it launches in full, all iOS apps that offer third-party sign ins (like the Google & Facebook options) will be mandated to also offer Apple's OAuth sign-in -- and must give it more prominent placement than third-party services.

>will be mandated to also offer Apple's OAuth sign-in -- and must give it more prominent placement than third-party services.

That seems like an abuse of monopoly power.

How so?

Welcome to iOS development.

Is Sign in with Apple compliant with OAuth2 / OpenID Conenct? If it's not I don't see how Apple can justify mandating the inclusion of something that isn't standards-based?

It's mostly compliant as of a few months ago [0]. That document is actually out of date, because Apple added a discovery endpoint since then [1]. They also haven't implemented the userinfo endpoint, but the only claims they expose are openid, name, and email, so it's not that big of a deal to just ask for those in the id_token. And the client_secret_post thing isn't much of a problem either, since their custom JWT is a perfectly valid client secret that's compliant with the underlying OAuth 2.0 standard and it's explained in their discovery document.

[0] https://bitbucket.org/openid/connect/src/default/How-Sign-in...

[1] https://appleid.apple.com/.well-known/openid-configuration

They don't call it OAuth/OpenID, but they're using the same terminology and API:

https://developer.okta.com/blog/2019/06/04/what-the-heck-is-...

If they provide a sufficiently good sdk, I'm not clear on what the issue is justification-wise, beyond the justification necessary for any mandatory inclusions they already have.

Why does a standard matter for justifying mandatory inclusion of ... anything? Most of their mandates probably lack any kind of standardization.

As I understand it Apple will make it mandatory for any app that offers social logins of any kind at some point.[0]

Shameless plug, I work for Skyscanner and we've had it since iOS 13 launch.

0: https://www.macrumors.com/guide/sign-in-with-apple/

Because those app devs also wants to know more about you

It will be mandatory to be on the app store at some point, so that won't be a valid excuse for app developers.

after March these apps will have to offer Apple sign-in or get booted from the app store...

Sure, it helps with privacy with regards to the services that you login. But all the emails are forwarded by Apple. So if you don't trust the big player (i.e. Apple) this is not privacy-friendly at all.

After the bad reputation from the "security" story recently now 3 Apple ads on front page. Back in business on HN! Good job.

it appears that Craigslist has implemented some version of this 'psuedo-random email in the middle' setup ?

Craigslist has used their psuedo-random email relay since at least early 2013.

https://web.archive.org/web/20121215193303/https://www.craig...

Yes, optionally, as a way to protect users from harassment. Like Apple, they can act as an intermediary to hide identities.

I just tried to register a new account at Wordpress but it's not working. Any other sites that you know?

I work at WordPress, what wasn’t working?

I click the "Use Apple" button and it takes me back at the same page with "you need a valid email account". This is on the ro.wordpress.com. Maybe it matters.

That doesn't sound right :( Did you use an "anonymous" email through Apple or your real email address?

"I kept waiting for the “confirm your email address” email to arrive but it never did"

really John? you expected a confirmation email to arrive? also, Google and Facebook don't require a confirmation email either

Reply on news.ycombinator.com