
Apple Pay JavaScript Framework - cobralibre
https://developer.apple.com/reference/applepayjs
======
0x0
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...](https://developer.apple.com/reference/applepayjs/applepaysession)
\- missing a 'quote' character in front of 'mastercard'.

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

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

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

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

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

------
LAMike
Anyone know what the fees are?

~~~
dreamsofdragons
It's Apple, so 30%?

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

------
nickruby
has to be on safari? lol

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

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

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

~~~
0x0
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/](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.

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

~~~
0x0
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.

------
trungonnews
Bye bye PayPal

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

