If that's the case, then why does UIWebView under-perform Mobile Safari? (I know Mobile Safari uses nitro, but I have no idea what UIWebView uses under the covers). Also, Apple's known for being a bit slow to contribute some things back to WebKit. I wouldn't be surprised to see them not contributing nitro back.

I think they're both using Nitro (depending on who you ask: http://ariya.ofilabs.com/2012/06/nitro-javascriptcore-and-ji...), but UIWebViews don't have JIT compilation turned on (no executable memory pages allowed in iOS apps), so they're slower.

JavaScriptCore (like other js engines) has an interpreter and a JIT. The JIT requires memory that's both writable and executable. iOS doesn't allow memory that's both writable and executable for security reasons, so normal apps can't use the JIT parts of jsc. Safari gets an exception from the "no writable and executable memory" rule.

(That's the technical reason; if you're wearing a tinfoil hat, you could argue that Apple wants to make sure native apps work a lot better than thin UIWebView shims, for lock-in and whatnot.)

Apple engineers contributed "Nitro" to the WebKit SVN repository before it even gained that name.

You're telling me Apple doesn't have their own Safari patches to compete in the speed war? Are they all contributed back to jscore?

The version of JavaScriptCore (and the rest of WebKit) available from svn.webkit.org is exactly what is shipped in Safari on OS X.