Don't get me wrong, I would love Chrome on my iPhone and iPad. But Chrome for iOS isn't really Chrome — it's a much slower version of Mobile Safari.
Facebook revealed yesterday that it is finally making a real, fully native iOS app. Until now, Facebook's app has been based on web tech — it's a browser and a mobile site inside of a blue-colored wrapper, basically. So why the sudden change of course? Because in-app browsers are required to suck in iOS. And barring some kind of special exemption, it's virtually guaranteed the Chrome for iOS will have to use the same slower browser engine that Facebook has been suffering with.
Mobile Safari, the default browser in iOS, uses a Javascript engine called Nitro, which in turn uses a technology called "just-in-time" compilation, or JIT, to execute scripts more quickly. The technical details aren't too important here — John Gruber has a good explanation here, if you want it — but the effects are. JIT makes Nitro faster, and Nitro makes Mobile Safari faster. This is great, if you're using Mobile Safari.
But other apps that want to include a browser function, be they Facebook or an actual alternative browser like Chrome, don't get Nitro. And developers can't use their own engines, either. For security reasons, the browser developers get to use in their apps is a variant of an older, pre-Nitro version, called UIWebView. Here's how Apple describes it:
You use the UIWebView class to embed web content in your application. To do so, you simply create a UIWebView object, attach it to a window, and send it a request to load web content.
It's fine — it renders pages with the same fidelity as Mobile Safari. But this is what all alternative browsers in iOS are forced to use. And it's slower. Noticeably slower. Here's how Mobile Safari and the Facebook app compare in a Javascript benchmark:
