Live data from Hacker News

Apple allows hot code push for JS downloaded and run by WebKit

meteor.com

71–74 of 74 posts

Re: Apple allows hot code push for JS downloaded and run by WebKit

#71

Earlier quoted context omitted.

Is this also true when using JavaScriptCore directly? Or do you only get JIT compilation in the context of a web view?

Only in a web view. The point is that the JITed code is in an isolated process with few permissions.

And vitally it can allocate executable memory, which nothing you write can.

Re: Apple allows hot code push for JS downloaded and run by WebKit

#73
post #16

Earlier quoted context omitted.

No, they catch that kind of stuff in app review. Lua code updates would be a small part of that. They're asset and IAP content, that is why it's multi-megabyte. It comes from experience.

Can they? For instance in love2d the mechanism for distributing a blob of assets after the fact is the same as the mechanism for distributing a blob of code after the fact. I'm not sure I can rewrite my app to be incapable of loading code from mounted archives, though I could rewrite it to not mount any archives until it's done loading code.

Well they detected it my company when we did it. We had little lua mini-games that you could download, and they rejected the app for it.

If you work really hard to hide it, then you could do it possibly. Like most private API calls are not detected by their tool if you execute it with a composed string based peformSelector: style action for example. And they can't really detect private view manipulation either.

But they can also use plain deduction in using your app. As in, 'this wouldn't be possible unless they are downloading code'. They also don't like finding out about hidden shit that is only revealed once the app is approved.

Re: Apple allows hot code push for JS downloaded and run by WebKit

#74
post #67

Unless I'm mistaken, two primary restrictions are: 1. script must be downloaded only within UIWebView. 2. script must be excuted only within UIWebView. Not sure why #1 is important to Apple but #2 makes perfect sense. I'm assuming Meteor is downloading scripts then passing them as 'data' to native-side to be cached somewhere until it needs to be injected back into UIWebView for execution.

Hmm, 1 at least isn't entirely enforced. (Chrome has its own network layer, and quite obviously supports scripting.)

Very good point.
Post reply on HN