Apple Pay JavaScript Framework | Hacker News Reader

Apple Pay JavaScript Framework

developer.apple.com

88 pointscobralibre35 comments

These docs must've been published in a rush. There's even an obvious syntax error as demonstrated by the syntax highlighting on https://developer.apple.com/reference/applepayjs/applepayses... - missing a 'quote' character in front of 'mastercard'.

It's telling that Service Workers and Web App Manifest remain unimplemented by Apple but they are releasing a (proprietary) payments API, as though it's a bigger need.

Well a bigger gain on investment, probably

Web app manifests have been supported since Safari 4.

http://caniuse.com/#search=Appcache

I think he's referring to the newer manifest.json files: https://www.w3.org/TR/appmanifest/

Which is still an unstable draft, so I don't see the point in using it today.

Service workers are nice but nothing earth-shattering, there are more interesting features in development at the moment: https://webkit.org/status.

According to the list they are also considering implementing service workers so it is not all drama.

With your phrasing, I get the feeling you've mistaken your needs for the needs of an incredibly large corporation. It's pretty common on sites like this, and usually popular, but to what end?

Especially given that Apple's obligation is to their users not web site developers.

Service Workers from what I've seen would consume quite a significant amount of battery life and prevent Safari from sleeping under most conditions.

One could argue that it is a bigger need. A web app can work fine most of the time, even if it’s not offline-ready, but if payments aren’t seamless, you have a big problem.

So does this mean I can or cannot use it in my WebView-enabled hybrid app running on iOS?

You still have to comply with apple pay guidelines.

If you are selling physical goods then you can use apple pay. If you were already in the app store, you would have already been using credit cards (and probably apple pay) to process payments instead of in-app purchases.

If your hybrid app is currently using in-app purchases, then you should still be using in-app purchases.

Anyone know what the fees are?

It's Apple, so 30%?

Nope. The processing is handled by a processor like stripe. The fees are as normal.

has to be on safari? lol

That covers the vast majority of people browsing the web on their iPhones/iPads. Not sure what the browser share is on the Mac though.

shockingly low, if the 3 mac-using companies I've worked at are any indicator.

That covers everybody on an iDevice - the only browser on iOS is Mobile Safari. Chrome, Firefox, Opera are all skins on top of the Safari Webkit renderer.

Interestingly / Ironically / Whateverally, it doesn't cover a ton of other, non-iOS users. This may be a push to Desktop Safari usage, but I am really uninterested in supporting proprietary browser tech, especially when there are competing open standards, doubly-especially when (as the OP mentioned) Safari in particular doesn't seem interested in supporting other open, interesting APIs.

Since I never quite figured this out: Why are there no real other browsers on iOS? Is it policy or simply not feasible?

App Store policy requires any app rendering HTML/JS to use the safari/webkit-backed UI components.

See 2.5.6 here https://developer.apple.com/app-store/review/guidelines/

"2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript."

As for why this is, one can only speculate. There used to be an extremely strict "no interpreted code allowed", which was relaxed to "no interpreted downloaded code", which I think (with the addition of the JavaScriptCore framework and the lack of bans on bundling a LUA interpreter as many games do) has turned into a "no major functionality changes or additions in downloadable code". I guess their main concern was developers publishing app updates outside of the app store review team's oversight.

Allowing other browser engines would also mean there'd be a lot more room for vulnerabilities that Apple has no control over. That's not to say that Blink or Gecko or whatever aren't secure, but if either of these engines introduced any kind of severe holes the consequences could be disastrous (and worse, unpatchable for that segment of folks who disable auto update).

Besides that, both Firefox and Chrome on OS X are notorious for power usage issues. There's a very good likelyhood that'd be true under iOS as well and the last thing Apple wants is a bunch of users blaming their iDevices for poor battery performance when the issue is actually web engines that are bad at rationing energy.

Well, the horse's kinda already bolted out of the barn when they allow external scripts to be executed in game level updates or whatever. And any damage would be contained to the app in question... unless the iOS sandbox is a sieve... they do seem to have tightened it up fairly well recently though.

You're right about power usage though. Even if they did allow third party engines, they wouldn't allow third party JIT compilers (much bigger attack surface, W|X memory protection is gated behind an apple-only entitlement) so those browsers would be second class citizens battery- and performance-wise for sure.

Even more disappointingly, there is an open W3C standard in progress for payments. Ah well, such is Apple.

Does anyone use that standard? This is the first time I've heard that there was a standard.

Google announced web payments integration for Android Pay using the Web Payments API last month. Just like Apple Pay for the web, nobody is using it now, but it's on the Chrome roadmap.

So therefore it's a question of whether Google or Apple get to muscle their way to influencing the eventual W3C standard, by deploying a pre-standard implementation. Same difference in my view. Yet somehow Apple is smacked down for it?

Too bad this space is so heavy regulated. I'd like to see a free and open source implementation pushing the standard.

Both the Firefox and Chromium implementations of the payments api are free and open source.

If by same difference you mean "one is being developed in the open, with editors from Microsoft, Firefox, and Facebook and the other was developed in private and has the company's name in the API"... then yes, same difference.

It appears there isn't too much of a gap with the Web Payments API. Today, the Safari team posted their intent to rectify the differences: https://lists.w3.org/Archives/Public/public-payments-wg/2016...

If you have access to TouchID, you're going to be using Safari to browse the web.

And could probably hack it with redirects otherwise.

macOS Sierra will be capable of authenticating using TouchID (read from your iOS device)

Bye bye PayPal

Um, no. People will use this API via a Braintree or Stripe SDK.

Reply on news.ycombinator.com