2012-06-29

As you might have heard, Google Chrome is now available for the iPhone and iPad, but before you get too excited, you need to realize that it isn't Chrome at all. It's Apple's Safari with a 'chrome' interface. The actual browser, the rendering, and javascript engine is 100% Apple Safari.

As John Gruber puts it:

It's not the Chrome rendering or JavaScript engines - the App Store rules forbid that. It's the iOS system version of WebKit wrapped in Google's own browser UI.

Google Chrome for iOS is still interesting because you get Chrome synch and other Chrome goodies.



But there is a big problem with third party browser on iOS. Not only does Apple not allow other browsers. It also forces them to use an older version of Safari than the one Apple can use themselves.

Every iOS developer knows this. Seeing a website in Safari is much faster than seeing a website inside an app. This is true for Flipboard, the Facebook app, the Twitter app, and every other app - including the new Chrome for iOS.

The reason is simple. Apple wants control and force people to create native apps, and are thus limiting the performance of web apps in third party apps. There is no reason why the iPhone and iPad comes with two different rendering engines - one for Apple and one for everyone else. This is purely anti-competitor behavior that limits choice and forces people to create native apps.

The limitation is even put in place for native web apps, the ones you see inside Safari itself. As long as you see them in Safari they work great. But the second you save them as a web app to your home screen, they are suddenly forced to use the old Safari engine, and are thus much slower to use.

How big a difference is it? I ran a series of test on my iPad, and as you can see, Chrome on iOS is significantly slower, especially when it comes to the all important javascript rendering (the last two 'Sunspider' tests).



Remember, both Safari and Chrome are using Apple's Safari javascript and rendering engine. The is no difference (in theory) 'underneath', so it should also render at the same speeds.

Back in 2011, John Gruber posted a rather lame explanation of why Safari had to be faster for Apple and slower for everyone else. He claimed it was because of 'security concerns', but that is just bullshit.

There is absolutely no difference between a web app running in Safari and the same web app save to the home screen and then running *in Safari*. It's just a lame excuse because we all know that whenever somebody says "it's because of security", everyone is apparently required to stop thinking and just accept whatever insane explanation we are presented with.

There is no technical reason why a web app using Safari from within an app cannot use exactly the same security and memory protection as the same web app running in Safari. It's only different because Apple has made it different.

Also, every single app on the iOS platform runs inside its own isolated sandbox. There is no way that these apps can gain access to elements outside the box it is in. For that reason, there is also no reason why Apple cannot allow Google and Firefox to build their own browser engines into their apps. They are running as an isolated process.

If you can build immensive games using the Unreal gaming engine inside an iOS game, surely you can also run a few lines of javascript code using the Chrome engine without any problems.

This is yet another scam designed to force developers into creating native only apps, by giving their users (that's you!) a much slower experience every time they have to use the web.

Chrome, using Safari's engine should run exactly as fast as Safari itself. It is the same freaking browser with just a slightly different coat of paint.

It's just like how Apple use ePubs in iBooks is also a scam. It stops people from realizing that they are being seriously limited in what they can do with the web, and forces them into an Apple only world.

I wrote about this back in January in "Lies, Damned Lies, and Ebooks" and earlier today, Jani Patokallio explained it this way:

---

Last year, I bought a laptop in Singapore, and brought it with me to Australia. It worked fine for reading the Economist online and what passes for journalism in Singapore, but one day I searched for the Sydney Morning Herald, and there were no hits: it's as if it didn't exist. A little poking around revealed that to be able to view Australian sites, I had to register my browser to be in Australia, which also requires a credit card with a billing address there. What's more, switching countries like this would delete all my bookmarks, terminate my paid subscription to the Economist and stop me from being able to read even single issue of the Singaporean Straits Jacket. And needless to say, the laptop is locked to prevent me from installing another browser that would allow me to get around these limits.

Does this sound ridiculous, a perverse fantasy of some balkanized Web of the dystopian future? Nope: it's all true, except that my "laptop" is actually an iPad and my "browser" is iTunes/iBooks. Since my iTunes account has a Singaporean billing address, the Kindle application does not show up in my search results. If I switch countries, I will lose access to everything I've previously downloaded. And if I do bite the bullet and switch to Australia, a good chunk of apps, music and more on offer will no longer be available on iTunes, iBooks or Amazon, and I'll pay around 50% extra on what remains. But I chose not to, and thus didn't buy 3 or 4 books I wanted to, because their publishers would not sell them to me.

Read the rest of his excellent article explaining why the future of the ebooks is HTML5.

---

Apple is doing everything they can to stop the web. They are limiting web apps from becoming truly functional by making them three times slower in 3rd party apps or saved to the home screen. The same was as they are trying to stop the web with iBooks, the Newsstand and in every other area where the web could shine.

Show more