Some Impressions and Benchmarks from Chrome on iOS
by Brian Klug on June 28, 2012 4:13 PM EST- Posted in
- Smartphones
- Mobile
- Chrome
- iOS
- Tablets
- Trade Shows
- I/O 2012
Earlier today, Google announced Chrome for iOS (iPhone and iPad), and thanks to Richard Gaywood finding a direct link to the App Store, I got the chance to play around with it in-between a busy schedule of sessions and meetings at I/O 2012. Chrome on iOS weighs in at 12.8 MB and is version 19.0.1084.60.
Earlier I had a glimmer of hope that Apple had relaxed the App Store rules to allow Chrome as a real native application on iOS, complete with its V8 JavaScript engine and newer version of WebKit (535.19). Unfortunately, as suspected, Chrome on iOS uses iOS' UIWebView, which means the same rendering engine as mobilesafari. On my iPhone 4S running iOS 6 B2, you can see the same user agent string (with the Chrome OS version tacked in between some other things) shared between mobilesafari and Chrome.
| iOS MobileSafari | |||||||
| Location | WebKit Version | HTML5test.com Score | CSS3test.com Score | Sunspider 0.9.1 | |||
| iOS 5.1.1 | 534.46 | 324 + 9 | 52% | 2226.1 | |||
| iOS 6.0 B1 | 534.46 | 360 + 9 | 57% | 1842.9 | |||
| Chrome for iOS (on iOS6 B2) | 534.46 | 360 + 9 | 57% | 6839.4 | |||
In addition, like other apps leveraging UIWebView, there's no access to mobilesafari's Nitro JavaScript engine which has JIT and other optimizations that make it run much faster. That means JavaScript execution is significantly slower inside Chrome on iOS than it is in mobilesafari.
On the positive side, the Chrome interface is pretty much exactly how it appears on Android, including the nice tabbed card switcher complete with the ability to close and switch tabs by swiping off the edge of the screen. Scrolling around inside webpages is also nice and speedy on Chrome for iOS, which isn't a surprise since, again, it's using UIWebView. The real feature in Chrome for iOS sadly isn't a superior browsing engine, but rather the ability to sync your tabs, pages, and back history across the desktop and more mobile platforms.
Update: As NobleKain points out in the comments, there's a discrepancy between WebKit versions between iOS 6 B1 and B2. B2 is now running 536.13, but WebView remains 534.46. Either way for users running iOS 5.1.1, these should be the same, I just unfortunately only have a device on me running the beta, hence the discrepancy.
Facebook
Twitter
RSS
52 Comments
View All Comments
JMS3072 - Thursday, June 28, 2012 - link
I don't understand- Apple allowed Opera to release their browser with a custom rendering engine. Why isn't this the case any more?Guspaz - Thursday, June 28, 2012 - link
Apple does not restrict rendering engines, they restrict javascript engines. You can't execute arbitrary code in an app.Opera got around this by running the javascript server-side and pre-processing the page before sending the text data down to the phone. There are obviously side effects to this.
SkyFire got around this by running the entire browser server-side and just streaming images of the web pages to the phone.
LauRoman - Thursday, June 28, 2012 - link
Opera Mini is basically just a glorified pdf viewer.UpSpin - Friday, June 29, 2012 - link
iOS only has Opera Mini, not Opera Mobile, Android has both.Opera Mini uses Opera Servers to pre-render the website, so no HTML/JS/.. code gets interpreted on the iPhone. Opera Mobile on the other hand is a 'real' browser, which Apple doesn't allow on iOS
toyotabedzrock - Friday, June 29, 2012 - link
Because it is not an actual browser, it prerenders the page and compresses it up to +90% then sends it.Plus it helps Apple expand in areas where bandwidth is a concern.
MrSpadge - Thursday, June 28, 2012 - link
... imagine Microsoft would have done something like this 10 years ago!B3an - Thursday, June 28, 2012 - link
Apple are just assholes. It's totally unacceptable to have these severe restrictions on something as important as a browser.xype - Friday, June 29, 2012 - link
Why?Steelbom - Friday, June 29, 2012 - link
I believe it's for security reasons, since Apple's Nitro JS Engine requires that unsigned code be run, and Safari takes steps to prevent that from being used maliciously. Allowing third party apps to do the same could open some holes in security.Striderevil - Sunday, July 1, 2012 - link
Isn't that why they have a stringent screening process? Charge more and give the appearance of quality when in reality restricting other app functionality in the name of security is just BS for your on iOS use our products only. They have always been a closed system hether its hardware or software.I'm yet to see any exploits on the android version of these apps which are from well known developers like Opera or Dolphine.