The reason native apps use a different flavour of WebKit to Safari is because the latter operates in a privileged security mode, whereas the former are all sandboxed. Mobile Safari uses a JIT compiler, but this introduces the possibility for remote code execution.

It's not that Apple 'doesn't want you building web apps they can't monetize' - it's that JIT compilation of JavaScript doesn't sit well with the current iOS security model.

People seem to easily forget that Mobile Web was originally the only way to get apps onto the iPhone. A number of Apple's own apps (the App Store, for example) are HTML based rather than ObjC based.

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.

This doesn't even make sense. You have it backwards.

If you run a web app in Safari, or save it as a web app in the home screen, it's going to run full-speed. If you wrap it in a UIWebView and sell it in the App Store (hello monetization) it's going to be slower.

This is equivalent to being hired by a bank to re-write an entire enterprise timesheet app and then I decide on using Websockets and WebGL. Of course I will blame the fact that the app doesn't work on any of the internal bank computers because "they run crappy IE8 and nobody should be running it anyway". Nevermind that 50% of the bank's computers have those constraints.

Sometimes, you have to face reality and write the best application that you can considering the current constraints that you presently have.

Others have addressed the JS point but Apple originally wanted developers to only build web apps and it took a lot of convincing to get them to change their mind. Also Apple has a lot of free apps. So this idea that Apple is somehow obsessed with monetizing apps is simply not true.