Update: Sadly, while Web.app got Nitro so Home screen web apps enjoy the faster JavaScript rendering, UIWebView did not. That means web pages contained in apps are still using the slower version. (Likely for security reasons.)

According to a poster Hacker News, the Nitro JavaScript engine brought to iOS 4.3's Safari browser, is now available to embedded UIWebViews and home screen WebClips in iOS 5. Apple originally claimed the Nitro engine, ported from desktop Safari, would make iOS Safari 2x faster, but due to restrictions on code interpretation (Nitro uses JIT, or Just-in-Time compilation), it was only available in the Safari sandbox. This effectively made web pages embed in apps and saved to the home screen feel twice as slow. No longer, according to this thread:

Q: Did they fix the bug from 4.3 where home screen web apps don't use Nitro?

A: This is probably breaking my NDA to say this, but yes, they did. Web.app now has the "dynamic-codesigning" entitlement, which enables Nitro.

In other words, embed webpages and home screen web apps just became first class citizens, and should have the speed to prove it.

[Hacker News via CNET]

As we posted the other day, while Safari in iOS 4.3 got a huge speed boost thanks to the Nitro JavaScript engine, asynchronous mode, and HTML 5 caching, bookmarking a site to the Home Screen (Web Clips) that launch in full-screen mode, or browsing inside an app (UIWebView) didn't. That meant, while web apps on the home screen and web pages embedded in apps were as fast as they were in iOS 4.2, they weren't as fast as Safari in iOS 4.3.

The technical reason for this is because Nitro is using Just-in-Time (JIT) compilation. Daring Fireball says:

A JIT requires the ability to mark memory pages in RAM as executable, but, iOS, as a security measure, does not allow pages in memory to be marked as executable. This is a significant and serious security policy. Most modern operating systems do allow pages in memory to be marked as executable — including Mac OS X, Windows, and (I believe) Android1. iOS 4.3 makes an exception to this policy, but the exception is specifically limited to Mobile Safari.

It’s a trade-off. Most OSes allow marking memory pages as executable for performance reasons. iOS disallows it for security reasons. If you allow for pages of memory to be escalated from writable to executable (even if you require the page be made permanently read-only first), then you are enabling the execution of unsigned native code. It breaks the chain of trust. Allowing remote code to execute locally turns every locally exploitable security flaw into a remotely exploitable one.

So if you load a page in Safari or have a Home Screen bookmark that launches into Safari, you get Nitro because Apple trusts Safari (which given how big an attack target Safari has is... interesting.) If, however, you load a page in an app using UIWebView you get the old JavaScript engine because Apple doesn't trust that app. If you launch a Home Screen bookmark that includes specific code for full screen mode, Safari doesn't pick it up but it opens in Web.app and -- for some reason -- Apple doesn't trust that either (yet?).

WebKit2 -- which iOS 4.3 doesn't seem to be using -- could address this because it uses split processes built into the frameworks but there's no word on when or if Apple will implement it in iOS. (It's reportedly implemented in Mac OS X Lion beta.)

So no conspiracies, just the usual trade offs between security and convenience and the limits of Apple's resources to get everything done all at once. (We won't put the pitchforks and torches away altogether, however, and Web.app gets Nitro, and everything gets WebKit2.)

[Daring Fireball]

While iOS 4.3's Safari is roughly twice as fast as previous versions thanks to the newly ported Nitro JavaScript engine, asynchronous mode, and HTML 5 application cache, it looks like Web Clips (web pages saved to the home screen as icon bookmarks) and WebViews (web browsers embedded in apps) are still using the significantly slower iOS 4.2 tech.

The Register suggests a conspiracy -- that Apple is deliberately throttling Web Clip and WebView performance so web apps can't compete with the App Store and cut into Apple's 30% share of revenues. Of course, many web apps are free and Apple's 30% share of similarly free App Store apps is exactly zero. Likewise, lack of WebView support hurts the performance of App Store apps, not web apps. (iTunes and App Store on iOS are native wrappers around a WebKit UI, after all.)

So, while such theories are dramatic and link baity, like with the just-improved AirPlay and still not-fixed AirPrint, sometimes Apple can only implement so much of a new feature in the first release cycle. Therefore, it's probably safer to assume it's a bug unless and until it remains unfixed in a subsequent update. At which point even TiPb will start sharpening the pitchforks and lighting up the torches, b'okay?

UPDATE: Looks like the reason is security.

[The Register]

CNET UK was able to take the iPad 2 running iOS 4.3 out for a test drive and the results are hypercar impressive -- 2097ms. iOS 4.3 and its new Safari Nitro engine gets a lot of the credit -- it blows iPhone 4 and the original iPad past the likes of the Nexus S and Galaxy Tab as well (they've been unable to test a Xoom as of yet), but that Apple A5 is enough to power iPad 2 to very top.

Why does this matter? Increasingly popular sites like Facebook are using more and more JavaScript to provide more and more functionality. Parsing and presenting that as fast as possible is key to having a good web experience. Who wants to wait to see their wall?

Certainly Android will get an even better version of Chrome in the future, and iOS 5 might just bring us WebKit2 like Mac OS X Lion is currently providing in beta form. For pure web performance junkies, 2011 is looking to be a very good year.

[CNET, thanks Jason!]

Which has the fastest browser, Apple's iOS 4 or Google's Android 2.2? We're used to browser battles here on TiPb, but how about a browser battle battle? See, both Ars Technica and Engadget ran some tests, pitting iPhone 4 on iOS 4 against the Nexus One running Android 2.2 Froyo and the results... varied dramatically to say the least.

Ars SunSpider and V8 benchmarks showed the Nexus One blowing iPhone 4 out of the water with almost double the JavaScript performance. Engadget's real-world test loading real-world webpages, however, had iPhone 4 with a slight lead when Flash was enabled on the Nexus One, and slightly behind when Flash was disabled.

Both iOS and Android use WebKit-based browsers, with Apple running the Nitro JavaScript Engine and Google running their V8. Likewise iPhone 4 has Apple's own A4 processor while Nexus One boasts a 1Ghz Snapdragon.

Some might not think iterative increases in rendering speeds matter, but as we race towards the agile future of web apps, every little bit becomes important. Just like on the desktop, we expect every new release from either party (and others) to keep pushing the envelop. We should get iOS 4.1 in September and Android 3.0 later this year as well, both likely faster than what we have today.

So kudos to Google. Hopefully Apple responds in like fashion and the browser battles (and browser battle battles) continue!

[Ars Technica, Engagdget, Android Central]

Apple has just released desktop Safari for Mac and Windows to 4.0.4, which improves full history search performance, has the mandatory stability improvements, and security fixes, but the big news as far as we're concerned is the number one item on the list -- Improved JavaScript performance

Desktop Safari is the big brother of the iPhone's Mobile OS X Safari, and they share a rendering engine (WebKit), and a JavaScript engine (Nitro), and improvements in desktop Safari and Nitro have traditionally filtered down to Mobile Safari with the subsequent iPhone OS update. That's right, we're looking at you iPhone 3.2 (where ever you are!)

Since the current iPhone 3.1 Safari is still outperforming even brand-new devices like the Droid, that may seem a little greedy, but we know Google's Android and Palm's webOS aren't sitting still in the rendering race, and have updates of their own in the pipeline, so once again, competition benefits the end users. Bring. It..

We mentioned yesterday that iPhone OS 3.0's Mobile Safari Browser was being reported as faster than the current iPhone OS 2.2.1 version. Now Ars Technica has run the numbers and the results are pretty impressive. Check out their full report for all the details, but this sums it up nicely:

According to our sources, the 3.0 beta still has some stability and speed issues, so that makes these results that much more impressive. While the overall average gives the iPhone 3.0 beta a 300 percent speed advantage, some of the individual tests show 6x, 8x, or even 11x improvements—the bitwise "AND" function even runs 16x faster than in the current version of Mobile Safari.

Should make the release version of the new, Nitro-powered Mobile Safari 3.0 fairly impressive, come summer! Bring on them multi-app Facebook pages, the iPhone will be ready! (Joking... a bit.)

We so fondly remember Palm's Roger McNamee stating the Pre would be a million times faster on the web than the iPhone (now retracted), and even our sister-site PreCentral.net jumped on that band wagon, saying the Pre looked to be 4x faster than the iPhone.

Of course, we mentioned that on Sprint, lacking simultaneous voice and data, even a million times zero is still zero. Less flippantly, however, when Safari 4 Beta shipped for the desktop with its new ultra-fast Nitro (formerly SquirrelFish) rendering engine, we figured it would only be a matter of time before that scaled down to the iPhone's version of Safari (based on the same WebKit foundations as desktop Safari, as is the Palm Pre browser and Android Chrome Lite).

Now Daring Fireball and Wayne Pan posit that turbo boost might have already happened in iPhone OS 3.0:

Wayne Pan has braved the NDA waters and published JavaScript benchmarks for iPhone OS 3.0, and they are impressive — with results ranging between 3× and 10× faster than iPhone OS 2.2. And I’ll confirm that MobileSafari on iPhone OS 3.0 passes my simple “could be Nitro” recursion depth test.

From what we've seen of 3.0, it seems that way to us as well. Along with HTML5, CSS, 2D and 3D animation, anti-phishing, AutoFill, etc., it will be interesting to see what Apple and the WebKit team can pull of by the time iPhone 3.0 launches this summer...