3 ms·
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
by 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 agoIt'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 agoIs 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 agoOh, you're right, it's even simpler: Apps that browse the web must use the iOS WebKit framework and WebKit Javascript
- LeoNatan25 11y agoActually, 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.