More exactly, the kernel does provide a way for applications to mark memory pages as executable (which is exactly what Safari does, after all), but you need to have the right permissions to use the API, and App Store apps don't have those permissions...

Even more exactly, there are ways but if you use them there is no way to publish on the App Store, because private API.

There is no reason not to have JIT or WebGL in a WebView other then apple not wanting you to, even though this was the original vision of the platform.

I still have hopes that Apple cares enough and finds a way to whitelist the JSC lib somehow.

Not sure exactly how that would work, because permissions to allocate executable memory is given per process on iOS. But I guess they could inspect the call stack to see if the allocating call indeed comes from the built-in JSC lib?

They might be able to support JIT by moving webkit out of process. I believe they do this now with the Mail UI. For more info see:

   http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/

They could potentially do it with IPC, running the JS engine (or even the entire web view) in a separate process. The question then is whether the communication overhead can be minimized so that it doesn't cancel out the performance benefits of the JIT.

They're doing that for Quartz.

But I doubt what will drive Apple to improve JS performance. Because making people to use Objective-C is a lot beneficial to Apple.

Interesting. If they're doing it for Quartz, then that pretty much answers the overhead question. I suspect you are right that Apple feels very little motivation to improve support for languages and environments that don't lock you into their system. Or at least, they wouldn't have under Jobs.

But I don't think it is true that this strategy is actually more beneficial to Apple. Developers want to support multiple platforms, and the least expensive way to do that is often HTML5. That's why PhoneGap is popular, despite the poor JS performance. The extra cost of doing separate apps is ultimately paid not only by third party developers, but by Apple as well. To make a long story short, encouraging a cross platform environment would allow good developers to make higher quality apps.

Much as I dislike Apple these days, the difference between iOS and Android is such that I have trouble maintaining a straight face when I hear them compared. They don't need to compete on app availability.

Can't predict the future -- but I do not think they will ever do it after talking to @radian at JSConf.EU.