The new vector is that, in Safari's case, Apple audited the code that calls the JIT.
If UIWebView could JIT, somebody would write an app that dumps the JITs code (I assume that ARM does not have the ability to mark pages as 'executable, but not readable') and run it on a development system. From there, (s)he would figure out what the JIT does to make data executable. That knowledge could be used in an app that can execute code that Apple hasn't seen.
Of course, that app would need to pass the app store approval process to be useful, but that should not be hard.
A way around this is to move the JIT to the kernel or to a different process. I would guess that that would hinder performance so much that, in typical usage, JIT-ting becomes too expensive to speed up things. Alternatively, Apple could not have spent the time to do so (yet).
A way around this is to move the JIT to the kernel or to a different process. I would guess that that would hinder performance so much that, in typical usage, JIT-ting becomes too expensive to speed up things
Having the hosted browser in a different process shouldn't be too expensive. That's what Chrome and IE do. When you open up a UIWebView and process gets spun up that hosts the JIT (amongst the other plubming for the browser) and the host just has a window where the rendering takes place. This also fixes a whole host of other security problems hosting a browser in process.
Chrome and IE run on systems with faster processors and Gigabytes of RAM. RAM, especially is tight on iOS devices.
I also guess that some iOS apps will want to overlay stuff on their web views, postprocess the data, register callbacks, etc. Supporting such use might be a bit of work that Apple hasn't done yet.
If UIWebView could JIT, somebody would write an app that dumps the JITs code (I assume that ARM does not have the ability to mark pages as 'executable, but not readable') and run it on a development system. From there, (s)he would figure out what the JIT does to make data executable. That knowledge could be used in an app that can execute code that Apple hasn't seen.
Of course, that app would need to pass the app store approval process to be useful, but that should not be hard.
A way around this is to move the JIT to the kernel or to a different process. I would guess that that would hinder performance so much that, in typical usage, JIT-ting becomes too expensive to speed up things. Alternatively, Apple could not have spent the time to do so (yet).