Monthly Archives: July 2012

Did you fall for the Google Chrome iOS smoke and mirrors?

Ok, I admit that I messed up! Late last week, I excitedly wrote about my first impression of Chrome iOS. I thought it was unbelievable: Google released an alternative browser for iOS and Apple approved it. I guess that I wasn’t the only one *cough* Washington Post that thought you should know.

Well after the excitement wore off, I realized that Google didn’t really build a browser. Instead, they created a UIWebView — that’s the equivalent wrapping Google Search in an iFrame shell and telling everyone that you just built a search engine. That’s hardly unbelievable.

So why should I care if Google didn’t build an iOS browser?

Engineers certainly get upset over this kind of behavior. In fact, my former mobile engineer, Richard Guy, used to get extremely frustrated whenever I questioned the need to build a native mobile application. He would bellyache over the slowness of web-based mobile applications and while it was hard to show the difference in a live application he was right.

Guy Podjarny, Chief Product Architect at Akamai, recently published iOS 5 Javascript performance tests. The tests measure duration, so lower numbers are better. According to these test, there’s a 200% performance loss for UIWebView vs. Mobile Safari:

The practice of using the UIWebView is already too commonplace. Facebook’s current iOS application uses UIWebView. Fortunately, engineers at Facebook have hinted at a faster, native application coming later this month. I’d image that the effort was driven by the findings in the 2011 survey on mobile web sites conducted by Gomez, a application performance and monitoring company. According to the survey, 71% of mobile web users said that they expected a websites to load as fast on their desktop as it would on their smartphone. Additionally, 57% of mobile users stated that they would not recommend a mobile site that’s too slow and 43% would not return to the mobile site. Consumers clearly expect mobile applications and sites to be snappy.

In all fairness, Google mentioned in their FAQ’s that “Chrome does not have access to Safari’s Nitro engine, [and] Chrome may have slower javascript performance.”

While this statement is very well crafted, it is blatantly false. Google.com relies on Javascript and based on the performance tests one would expect the site to be slow. It is odd that Google would release an app with inferior performance, especially when considering that Google uses site speed to influence Page Rank.

So if responsiveness is important to you, do what I did and delete the Chrome for iOS! Google.com is much faster on plain ol’ Mobile Safari.

Sorry Google but Steve is still getting the last laugh!