You're not allowed to ship a interpreter that interprets code that doesn't come from insider your app.
So you can maybe ship Gecko + SpiderMonkey, as long as you only run JS that's part of your app. But if you want to run JS from a website (or indeed any code from anywhere), you're not allowed to do that on iOS.
I haven't checked whether it would be OK to ship a browser engine that doesn't support JS at all, but that's a fairly academic question anyway.
No, Apple's iOS developer agreements do not allow browsers with their own JavaScript engines:
"Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework."
Technically I think you are free to build have other browser engines on iOS. However, JIT or other dynamically compiled code is not allowed because that's a security risk. You can't have a browser in 2019 with interpreted javascript.
- compile Gecko to JavaScript and run it in Safari.
If you serve the compiled Gecko from a web server I don’t see them stopping you from doing the second, but of course, it would just be Gecko, not FireFox, and performance ‘might’ be somewhat subpar.
iOS definitely allows you to implement your own browser engine. The only caveat is that Apple doesn’t let third-party apps to mmap executable memory, so you won’t be able to create a JITting JS engine.
iOS apps can use whatever rendering engine they want. The restriction is on JIT -- Apple doesn't allow apps to compile native code on the fly, which modern JavaScript engines like V8 do. The exception is Apple's own JavaScriptCore, which works with WebKit.
In theory you could have Firefox Quantum as a tenderer with JavaScriptCore as the JS engine, but that might be more work than it's worth.
Will Apple allow this to be used in apps distributed through the App Store? As far as I know, they explicitly disallow any web browsers from using rendering/JS engines other than WebKit. I think this is for security reasons.
Are the JavaScript pseudo-native apps exempt? Can they use a custom JavaScript engine?
In addition to the "no code interpreting code" limitation, I'm pretty sure that there's a more specific "any web browser in-app must be the safari browser" rule. Technically, Mozilla could attempt to release an iOS app that used the Safari rendering engine (and framing it around the FF look and feel, bookmark sync, etc.) but I'm sure that would never happen.
Browsers are totally allowed -- there are alternative browsers in the iOS App Store right now (I use Atomic).
What is not allowed is to download code and execute it, which makes it impossible to write your own JavaScript interpreter, and forces you to use UIWebView to render HTML. You can't even just use webkit on your own -- you have to use the one on the device (by using UIWebView).
FireFox would also not be able to have plugins for similar reasons.
Atomic is better than Safari because it allows User-agent switching, view source and some other nice features, all of which doesn't require them to interpret JavaScript with their own code.
Third-party browsers cannot do core things like implement their own JavaScript engine (which is why you're not going to see Firefox or Chrome for iOS unless Apple changes the rules).
Gecko already runs on iOS, I just don't know what the exact build process is. The trouble is, a browser is much more than an engine, and why would people sink effort into an unreleasable product.
Pretty sure they don't allow you to download and execute code even if not using a JIT, unless it is an educational app. There are multiple policy reasons browser engines can't be on iOS.
I think this is possible right now. The restriction in the license agreement only applies to executing code, not HTML rendering or network transfers. Since iOS 8 (I think), you can use JavaScriptCore separately from WebKit. So it should be possible to ship a browser app that uses its own renderer, as long as you replace the JavaScript engine with Apple's, but I don't know if that's worth the bother. Also, it will also run slower, because only the Safari app is permitted to do JIT compilation.
No. Apple currently don’t allow any browser engines apart from their standardised WebKit on iOS. This is why you can’t currently get Opera or Firefox on iOS (leaving aside Opera Mini which skirts the rules by running the engine on a proxy server).
Efficient javascript needs to be JIT'ed, but that means your app needs to be granted API access to map writeable memory as executable, which is a security risk they are not willing to grant third party developers. So a third party browser/js engine will likely be quite slow. I guess this would give users of a bad impression of iOS perfomance as a whole then, if other browser engines were allowed and became popular?
Given Apple's well-known antipathy to the idea of browser engines other than WebKit and scripting languages other than JavaScript on iOS (yes, yes, I know you can find Python/Lua/Lisp/whatever apps on iOS; I mean as a general rule and for inter-app automation), could this be a prelude to allowing some sort of sandboxed-app automation interface on iOS? That is, allow a JavaScript implementation running on iOS to "drive" apps via this object model?
(Genuine question here. I have no idea whether I'm blowing smoke or whether this is a plausible long-term direction for Apple to take iOS.)
It’s not going to happen; even if you could run your own browser engine on iOS this requires deep hooks into system calls and Mach messages which isn’t really something that I would see Apple letting you do.
So you can maybe ship Gecko + SpiderMonkey, as long as you only run JS that's part of your app. But if you want to run JS from a website (or indeed any code from anywhere), you're not allowed to do that on iOS.
I haven't checked whether it would be OK to ship a browser engine that doesn't support JS at all, but that's a fairly academic question anyway.
reply