This is part of what people mean when they talk about code signing on iOS. Safari has a special exception allowing it to bypass this for the JavaScript JIT compiler and Safari is the only permitted browser engine. Apps are allowed to ship powerful interpreters and blur the lines.
Conversation
How does Firefox on iOS work? Is it just a fake Firefox that's reskinned Safari widget with some Firefox features on top, or do they just use interp-only? (The latter would be *extremely* preferable no matter how slow it is.)
1
Chrome and Firefox on Android are skins over top of a Safari widget. Apple's policies forbid shipping any alternative web engine implementation. An interpreter-only approach would work at a technical level but isn't permitted by their App Store policies. This is common for them.
2
1
I guess you mean on iOS; it's definitely real on Android. Why isn't interpreter permitted by policies if the interpreter does not expose any access to system facilities?
2
iOS has an explicit rule against implementing another web engine. Also, many uses of interpreters and even fancy forms or reflection are bending their rules. They don't want developers running code that's not shipped via the App Store. It depends on the usage and is nuanced.
2
1
So for example, if you ship a Python interpreter and use it to run Python code that's shipped with your app via the App Store, you're not breaking the rules. If you dynamically download code that's fed into the interpreter, you're almost certainly breaking the rules. Since this
2
1
This rule makes sense for Python which has external world bindings but not for e.g. Lua unless you bind it in ways that could be abused.
1
Google's policy is worded to permit meaningfully sandboxed code. However, there are a massive number of apps in clear violation of it. They don't really enforce the rules. Apple enforces it a lot more, but not so much for major apps where it'd cause a big fuss. It's arbitrary.
1
1
Can't link Apple's policies because viewing it seems to require a developer account. This is the Play Store policy:
support.google.com/googleplay/and
> An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism.
1
> Likewise, an app may not download executable code (e.g. dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs (such as JavaScript in a webview or browser).
1
1
A huge portion of apps on the Play Store are in violation of this rule. Termux is switching to using apk-based packages so that it's no longer in violation of the rule. It's really not enforced much. Apple rules are worded in a way that's it's hard to say if they are more or
less restrictive. They intentionally worded it in a way that's very unclear and open to interpretion. They enforce the rules far more though, unlike Google's almost non-existent enforcement especially of this rule. Otherwise, apps like Termux would be long gone from Play Store.
2
Also, Termux is only really moving away from it because of technical enforcement in recent Android releases where executing native code from app data is being gradually phased out and prevented like iOS. Complying with a policy Google doesn't really enforce is a secondary reason.