Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Popular Is “Sign in with Apple”?

daringfireball.net

Post reply on HN
Print view View original

131–140 of 340 posts

Re: How Popular Is “Sign in with Apple”?

#131

Post by dep_b »

judge2020 wrote: post #30
fetus8 wrote: post #14

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.

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.

Re: How Popular Is “Sign in with Apple”?

#132

Post by derefr »

taeric wrote: post #113
adamlett wrote: post #73

Earlier quoted context omitted.

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

Re: How Popular Is “Sign in with Apple”?

#133

Post by capableweb »

looperhacks wrote: post #126
clay_the_ripper wrote: post #117

Earlier quoted context omitted.

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.

Re: How Popular Is “Sign in with Apple”?

#134

Post by ljm »

ehsankia wrote: post #59
habosa wrote: post #41

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

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…

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.

Re: How Popular Is “Sign in with Apple”?

#135

Post by crooked-v »

taeric wrote: post #113
adamlett wrote: post #73

Earlier quoted context omitted.

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?

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

Re: How Popular Is “Sign in with Apple”?

#137

Post by jakobegger »

clay_the_ripper wrote: post #117
habosa wrote: post #41

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

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.

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

Re: How Popular Is “Sign in with Apple”?

#138

Post by tusharsoni »

Tepix wrote: post #118

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?

Re: How Popular Is “Sign in with Apple”?

#139

Post by K0SM0S »

freehunter wrote: post #89
pier25 wrote: post #72

Earlier quoted context omitted.

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.

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.

Re: How Popular Is “Sign in with Apple”?

#140

Post by saurik »

Uehreka wrote: post #98
favorited wrote: post #91

Earlier quoted context omitted.

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

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.

Post reply on HN