That issue is not as simple as you make it out to be. Just in time compilation of Javascript requires an app to have permission to execute code that is generated as data on the fly. Applications with this permission are vulnerable to exploits.
The standard UIWebView available to applications doesn't include just-in-time compilation because 3rd party applications don't have this permission. This is the biggest reason why its Javascript engine is slower than the one built into Safari.
Apple doesn't want you building apps that open up exploit vectors into iOS.
If it really is an engineering challenge it needs to be fixed. We're going on 2 years of Mobile Safari having JIT and UIWebView not having it. They can simply make an exception for UIWebViews without making an exception for the rest of the app. I don't know their codebase and it might be really really hard to fix, but I hope it isn't something they've given up on. It cannot continue in perpetuity, as the web cannot continue to evolve if the makers of one of the most popular browsers have given up on speed improvements.
No they can't: part of a process cannot create executable memory while another part cannot. They'd have to move WebKit completely out of process: a huge task as it already does most text drawing.
An interesting alternative would be to enhance the current 'Save to Home Page' feature beyond specifying a manifest of resources and a home page icon. If this was fattened up to allow developers to make something that looked even more like an app but was running Safari (not a UIWebkitView inside a native app), you might have something interesting.
No, but web pages (including apps that are installed to the home screen and run full screen) run inside the MobileSafari process, which is much more carefully audited than your typical iOS app.
Audited how? Unless MobileSafari is itself tightly sandboxed, I don't see how auditing the code inside it is useful. Once you get malicious executable code inside MobileSafari, it can do whatever MobileSafari can do.
I doubt they're trying to audit behaviour, you can always write an app in Lua with an interpreter and they would have a hard time "auditing" the app statically.
The propblem is that if you allow executable memory you open aup a lot of exploit vectors. Now, that's true of Mobile Safari as well, but they trust their own team more than they trust you, and they have one app to watch instead of 100,000, and if an exploit os found they can push out a fix immediately, whereas 3rd party apps have a tortuous process for pushing out bug fixes.
Remember, it's part of their value proposition that apps from the app store appear to be relatively safe in comparison to the clusterfuck that is downloading random desktop apps, especially on Windows.
Can you give an example of an exploit that would do harm from within a UIWebView but would not do harm from within Mobile Safari? Not questioning you, I'm genuinely interested.
Given the current architecture, if UIWebkitView within an application can execute data, then the entire application can execute data.
So you could have a buffer overrun anywhere in the app. For example, if they are silly, you could go to the preferences for Facebook and enter a very, very, very long user name, overrun the name buffer, and have executable code.
That's not an exploit of UIWebkitView, it's an exploit of giving the application the permission it needs to have UIWebkitView use a JIT compiler for JS.
The standard UIWebView available to applications doesn't include just-in-time compilation because 3rd party applications don't have this permission. This is the biggest reason why its Javascript engine is slower than the one built into Safari.
Apple doesn't want you building apps that open up exploit vectors into iOS.