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.
"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.
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?
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.
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.
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.
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?
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.
37 comments
[ 2.7 ms ] story [ 120 ms ] threadInterestingly / 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.
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.
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.
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.
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.
http://caniuse.com/#search=Appcache
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.
Service Workers from what I've seen would consume quite a significant amount of battery life and prevent Safari from sleeping under most conditions.