The subject of UIWebView not using JIT-enabled JavaScript engine becomes popular again, mainly due to the fresh release of Google Chrome for iOS. Unlike Chrome on other platform, Chrome on iOS is just an alternative user-interface on top of the UIWebView component hence making Chrome slightly inferior to Safari in pure JavaScript performance. This is usually not a problem since general web browsing does not involve heavy computation done in JavaScript. Update: Chrome under the hood packs some network awesomeness (SPDY, prefetching, etc).

A term which often shows up when discussing UIWebView is Nitro. What is exactly Nitro? First, let’s go back to the early moment when Apple mentioned Nitro. The press release Apple Announces Safari 4 says:

Safari 4 is built on the world’s most advanced browser technologies including the new Nitro JavaScript engine that executes JavaScript up to 30 times faster than IE 7 and more than three times faster than Firefox 3.

This was from February 2009. Later on, during WWDC in June, Safari 4 hit the final release. From the marketing material, there is hardly any mention of JIT, presumably because it is too technical for the general audience. However, if we look at the WebKit history, clearly this engine has that advanced JIT support. This is evidenced from the blog post Introducing SquirrelFish Extreme back in late 2008.

Note that technically speaking the JavaScript engine in WebKit is called JavaScriptCore. Its source code directory is called Source/JavaScriptCore. When it is installed in the system, the library JavaScriptCore.Framework is also using that name. If you are old enough to remember, JavaScriptCore was originally derived from KJS, KDE’s JavaScript engine. In fact, this was way before Safari time.

These days, there are apparently two schools of thoughts about what Nitro is.

Nitro = Booster via JIT

After Safari 4, a lot of people associate Nitro with JIT. This is emphasized again when iOS got updated to get JIT-powered Mobile Safari. When UIWebView did not get the JIT version of the engine, there was a lot of buzz, even Gruber wrote something like:

The Nitro JavaScript engine is only available within Mobile Safari.

In this interpretation, Nitro is identical to the some sort extra injection (Nitrous oxide) to boost the performance. This leaves a room for question: is there a name of the non-Nitro situation?

Update: For this camp, referring to the UIWebView situation would be:

  • Mobile Safari uses Nitro
  • UIWebView still uses who-can-remember-that-JavaScript-engine-without-JIT

Nitro = JavaScriptCore

Another group of people argue that Nitro is nothing but a marketing term for JavaScriptCore. It is the same thing, nothing more and nothing less. Two names for the same code. Apple’s press release did not insist that Nitro is JIT-only engine. The statement reads like "This fast engine is named JavaScriptCore by our engineers, but you can just call it Nitro".

Whether it has JIT support or not, the name shall not change. It’s rather easy to refer both situations:

  • Mobile Safari uses Nitro with JIT support
  • UIWebView still uses Nitro without JIT support

To further reduce the ambiguity, we might even drop Nitro completely and stick with JavaScriptCore. Hence, Gruber should have written:

JavaScriptCore, the JavaScript engine, only supports JIT within Mobile Safari.

I believe calling it JIT vs no-JIT gives a clear meaning. It’s less confusing than Nitro vs whatever-engine-which-does-not-have-JIT. Why are we confusing ourselves?

Which school of thought are you subscribed to?

  • Slightly orthogonal to your discussion here, and not to be too pedantic, but Chrome on iOS is definitely more than “just an alternative user-interface on top of the UIWebView”. For one, the networking stack, with all the prefetch, prerender, SPDY support, and other network optimizations, is all directly from Chrome.

    • Thanks for the additional info, I’ve added an update on that front.

    • mac

      Wow, iOS Chrome has its own network stack?! Care to explain a little bit how this is possible at all? Are you setting up a proxy or something to intercept all traffic from WebView? or use something like ASIWebPageRequest? Really curious to know!

  • MR

    Would you also touch upon why Chrome couldn’t use its own WebView & was forced to use UiWebView to be able to run on iOS. AFAIK, Chrome initially was trying to use its own rendering engine but then later was forced by Apple to use UIWebView? Is this also related to JIT on vs. off?

    • That’s not special to Chrome, nor it does apply only to web browsers. It’s one of iOS security restrictions: no application can run dynamic code generated on-the-fly If you create an innocent word-processor and it has a macro support with a JIT-compiled virtual machine, no chance it will come to the App Store.