3 ms·

The problem is that Apple doesn't provide access to lower level APIs that would allow other browser engines to compete on performance and increased functionalit

by doorty 11y ago

The problem is that Apple doesn't provide access to lower level APIs that would allow other browser engines to compete on performance and increased functionality. They can only compete on UI. This lack of competition is holding back the potential of the mobile web.

MagicWishMonkey 11y ago
Chrome worked wonderfully on my iPhone 5, up until the point where I installed IOS8. It was unusable after that, so I had no choice but to switch back to safari. Did they remove some low level API's in 8 that were available in prior versions?
- pistoriusp 11y ago
  No. There never were any low level API's. You're always using the webkit component; albeit one that's slightly slower than native safari.
  - matthewmacleod 11y ago
    Has Chrome not yet switched to using WKWebView? I know there was some talk about missing features.
    - LeoNatan25 11y ago
      The features are still missing as of iOS 9 SDK.
- manojlds 11y ago
  Ironically, it is with iOS 8 that other browsers got access to Nitro JS engine that Safari used so that they could potentially be on par with Safari.
  - rockdoe 11y ago
    If they're willing to be broken in other ways.
matthewmacleod 11y ago
This isn't quite accurate – the limitation isn't on API access, which AFAIK would be sufficient to implement a browser. Rather it's an app store policy decision to reject apps that download and run executable code. Since any web browser would have to do this in order to run Javascript, it's explicitly rejected. I'm not condoning that (or otherwise), but I don't think it's down to API limitations.
- toyg 11y ago
  It's nothing as technical as that. They just invoke the core-functionality duplication clause -- there's a webview class, if you reimplement it you're falling foul of the clause. Of course they control what functionality is considered "core", so they can decide at any point what is acceptable and what is not, which is exactly what they want.
- AshleysBrain 11y ago
  Is that really the limiting policy? Shouldn't that rule out any app using a web view (including Chrome on iOS) since they download and run Javascript? I thought the policy was literally "no other browser engines are allowed".
  - matthewmacleod 11y ago
    Oh, you're right, it's even simpler: Apps that browse the web must use the iOS WebKit framework and WebKit Javascript
- LeoNatan25 11y ago
  Actually, you cannot compile a modern JavaScript engine for iOS without a special entitlement, which is not normally available to developers. Modern JS engines compile JS code on the run and need to mark specific memory regions as executable. Unless your binary is signed with a specific entitlement, iOS kernel prevents you from marking memory regions as executable. Safari and WebContent are signed with a "dynamic-codesigning" entitlement, making them non-equals among binaries.

by doorty 11y ago

MagicWishMonkey 11y ago

Chrome worked wonderfully on my iPhone 5, up until the point where I installed IOS8. It was unusable after that, so I had no choice but to switch back to safari. Did they remove some low level API's in 8 that were available in prior versions?

pistoriusp 11y ago
No. There never were any low level API's. You're always using the webkit component; albeit one that's slightly slower than native safari.
- matthewmacleod 11y ago
  Has Chrome not yet switched to using WKWebView? I know there was some talk about missing features.
  - LeoNatan25 11y ago
    The features are still missing as of iOS 9 SDK.
manojlds 11y ago
Ironically, it is with iOS 8 that other browsers got access to Nitro JS engine that Safari used so that they could potentially be on par with Safari.
- rockdoe 11y ago
  If they're willing to be broken in other ways.

matthewmacleod 11y ago

This isn't quite accurate – the limitation isn't on API access, which AFAIK would be sufficient to implement a browser. Rather it's an app store policy decision to reject apps that download and run executable code. Since any web browser would have to do this in order to run Javascript, it's explicitly rejected. I'm not condoning that (or otherwise), but I don't think it's down to API limitations.

toyg 11y ago
It's nothing as technical as that. They just invoke the core-functionality duplication clause -- there's a webview class, if you reimplement it you're falling foul of the clause. Of course they control what functionality is considered "core", so they can decide at any point what is acceptable and what is not, which is exactly what they want.
AshleysBrain 11y ago
Is that really the limiting policy? Shouldn't that rule out any app using a web view (including Chrome on iOS) since they download and run Javascript? I thought the policy was literally "no other browser engines are allowed".
- matthewmacleod 11y ago
  Oh, you're right, it's even simpler: Apps that browse the web must use the iOS WebKit framework and WebKit Javascript
LeoNatan25 11y ago
Actually, you cannot compile a modern JavaScript engine for iOS without a special entitlement, which is not normally available to developers. Modern JS engines compile JS code on the run and need to mark specific memory regions as executable. Unless your binary is signed with a specific entitlement, iOS kernel prevents you from marking memory regions as executable. Safari and WebContent are signed with a "dynamic-codesigning" entitlement, making them non-equals among binaries.