5 ms·
> You're not allowed to provide your own web render engine at all. Is that true? I understand the security argument against JITs, but I don't see why it would
by eslaught 10y ago
> You're not allowed to provide your own web render engine at all.
Is that true? I understand the security argument against JITs, but I don't see why it would be objectionable to run a copy of e.g. Gecko if you excluded the JS JIT component. (Of course you would never actually do that. But I'm trying to tease apart the separate arguments and see if they're actually connected.)
It seems to me that the root cause for this is all the JIT. If the JIT in iOS has to be exposed via IPC for security (as claimed in a sibling comment) it's simply not going to be a win to try to use it in combination with a separate rendering engine, if it's even possible at all.
- st3fan 10y ago> Is that true? It is. Mozilla has an iOS port of Gecko. It runs well, even without the JIT, but we are not allowed to use it.
- Ezhik 10y agoIs that OSS? I'm sure people would love to try it even if it involves sideloading and such.
- st3fan 10y agoPretty sure all the changes are in mozilla-central. https://hg.mozilla.org/mozilla-central/file/tip/embedding/ios https://hg.mozilla.org/mozilla-central/file/tip/embedding/io... Sorry I dont know where we keep the build instructions.
- bzbarsky 10y agoYou'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.
- st3fan 10y ago> 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 10y agoGames 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 10y agoGames 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 10y agoThey 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 10y agoWhat 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.
- deleted 10y ago[deleted]
- kalleboo 10y agohttps://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/ > 2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.