[bzbarsky]

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.

[eslaught]

But for example, could you ship Gecko with Apple's JS engine in a way that will satisfy Apple's requirements? Of course the answer is no, but it's worth taking a second to think about why that is.

I guess what's bothering me is that there is an unstated assumption underlying this entire discussion which people never bring up: for performance reasons, the rendering engine has to be tied closely to the JS implementation. Specifically, calling over some IPC interface at every entrypoint into the JS interpreter would be a performance nightmare. This is the reason why these can't be disentangled. The connection to the interpreter is really an indirect one.

[st3fan]

> You're not allowed to ship a interpreter that interprets code that doesn't come from insider your app.

That is not true. Many apps do this. Games have been doing this for a decade. It is not a problem to do this. Apple has never made a big deal of that. Only if you are trying to build a shadow app store.

[wvenable]

Games interpret code that's shipped with the app. You cannot create an app which downloads code off the Internet (for example) and executes it.

[st3fan]

Games and apps have been doing this for a decade.

Apple does not care. As long as you are operating in the spirit of their App Store.

You know when they care? When you start charging money for those downloads. Via an alternative payment channel. Or when you run an alternative app store from within your app.

If you download assets on demand, and some of those turn out to be executable* code, nobody cares.

* Where executable means 'interpreted' because you cannot run unsigned code. But for games that is fine, they have been doing this with JS, Lua and Python for a decade.

(You can downvote me - but this is based on a decade of experience)

[wvenable]

They do care; Apple has shut down (or restricted) several apps over the years that have tried this. But I ultimately agree with you, it's really more about how it's presented rather than how it works under the hood. This might have a lot to do with the review process.

The subject we're talking about here would not fly under their radar.

[bzbarsky]

What you're saying is that Apple is inconsistent in enforcing its officially stated policy. That may be true, but does not change what the official policy is and that they can enforce it any time they want to.

[solidr53]

not true, checkout codepush from microsoft which enables OTA updates for cordova, react native, etc.

[ec109685]

Yeah, because JavaScript is exempted from their rules.

[bzbarsky]

JavaScript in general, or JavaScript only if it's run via Apple's JavaScriptCore?

[wvenable]

JavaScript only if it's run via Apple's JavaScriptCore.

Pebble used this quite effectively to add phone-side apps to their product.

[tiles]

See Microsoft CodePush and React Native for a counterexample: you can certainly publish apps which download code as long as they don't dramatically alter the functionality of the app.

[madeofpalk]

Games are a specific exemption to this rule.