Cloud Four Blog

Technical notes, War stories and anecdotes

Since the app store was released, people have been suspicious of Apple’s commitment to the open, mobile web. Why would Apple push the mobile web forward when web technology may compete with its native apps platform?

I’m not usually an Apple defender, but if you want to beat up on a company for their laggard mobile browser, look in Mountain View, not Cupertino.

Who knows if these will actually ship in the final version of iOS 5, but their inclusion wouldn’t be a surprise. Ever since the initial release of the iPhone, each new version of the operating system has included new browser features. Often these features, like geolocation, show up in Mobile Safari before they show up on the desktop.

This is what I call a mobile first browser. Borrowing from Luke Wroblewski’s mobile first thinking, browser makers need to develop their mobile browsers first.

We Need More Mobile First Browsers

Of the browser makers that have both mobile and desktop versions, which ones have shipped new features on mobile first?

We know Apple has. I suspect Opera has as well. The rest seem to be developing for desktop first.

What I found most interesting about Dave’s article is that mobile specific features are not mentioned in either his post nor in the comments. The Mozilla folks who defend their browser and its features talk exclusively about the desktop version.

Microsoft’s mobile browser also lags its desktop version. The mango update will bring Internet Explorer 9 to Windows Phone 7 later this year.

Mango will be a great improvement over Internet Explorer 7 which is currently being used, but while the Windows Phone team works on integrating IE9, Microsoft has already released two preview builds of Internet Explorer 10.

Google Needs to Step Up

If there was one company that we would expect to lead the charge for the open, mobile web, it would be Google. At Mobilize 2009, I watched Andy Rubin, SVP of Mobile, say that Google saw HTML5 eventually supplanting most native apps.

Given Google’s emphasis on web technology, a leading edge mobile browser seems like a natural fit. The reality is much different. The Android browser lags behind the iPhone in many ways.

At Google I/O 2010, Vic Gundotra demonstrated browser access to the camera, accelerometer, and the microphone. When Read/Write Web asked me about the demonstration, I responded, “Hell yeah, it’s about time”.

Unfortunately, none of these features shipped with Android’s Gingerbread release. Apple shipped browser access to the accelerometer before Google did. It is over a year later, and we have no idea when we will see them.

The contrast at Google I/O this year between a day dedicated to Android and a day dedicated to Chrome OS made the problems crystal clear.

For some time I’ve been hearing rumors of battles between the Chrome and Android teams. Seeing the two operating systems on stage made it clear that they are competing visions of the future. Should tablets use Chrome OS or Android?

It seems that the things that people accuse Apple of—slowing the pace of the browser in order to give their app platform an advantage—are actually happening at Google. Competition is generally a good thing, but when the competition is between the Android and Chrome teams, it is the users of the Android browser who lose.

Google needs to step up. Chrome is arguably the best desktop browser. There is no excuse for Android’s browser not leading as well.

This understates Opera’s mobile market position. Opera has a large installed base of users.

It assumes market percentages will stay the same. We know this won’t be true.

It assumes that all of the “other” smartphone OS browsers are not using Webkit currently.

Mobile Firefox is just getting started. It is unclear how that will change the landscape.

Just because it is Webkit, doesn’t mean that it is the latest version of Webkit.

Caveats aside, you would be hard pressed to find another smartphone development platform with any where close to Webkit’s market share.

More importantly, this means that HTML5 for mobile is looking great. If Blackberry joins the ranks of Webkit-based browsers, that will means Symbian, iPhone, Android, Palm and Blackberry will all be on the path to HTML5 support.

The only laggard will be Mobile Internet Explorer, and even for Windows Mobile there are options like Google Gears which adds some HTML5 support to IE or installing other browsers like Opera or Firefox.

After the release of the iPhone, RIM said that it understood the importance of having a rich browsing experience on Blackberry. It made vast improvements with the latest version of the browser. But even those improvements weren’t enough.

The reality is that RIM needed to change course when it came to its browser. It can’t carry the full burden of browser development and expect to keep up with Apple, Google and Nokia which base their browsers on open source software.

So the big news isn’t the purchase of Torch Mobile, but what it likely means for the Blackberry Browser in the future. Torch Mobile’s browser was built on webkit. This purchase would seem to suggest that Blackberry is going to stop developing its own browser rendering engine and start using webkit.

It’s going to take awhile for Blackberry to incorporate Torch Mobile and update its browser, but things appear to be headed in the right direction.

And when we say “raw data,” we mean it. We spent most of our time fine-tuning the test in order to make sure that it was as accurate as possible. We didn’t spend much time building our our own view into the data because we knew we would always have time to work with the information later.

Therefore, the data view isn’t very polished and will probably only be interesting to those who are looking for specific details.

There are three things you can see in the raw data:

An overview of all of the devices that have tested grouped by user agent and number of connections

For any given device, you can click on the user agent string to see all of the times that device has been tested and the http headers that were requested.

If the device was a mobile device, you can use the user agent string to query the WUFRL database to get more detailed information about the device characteristics

You’ll also get so see some of the anomalies that we’re investigating such as browsers that take too long to download the first image and thus are showing zero connections or the random instances where browsers request more concurrent images than they are supposed to be able to do.

We’re still planning on summarizing and publishing our findings. However, in the meantime, we hope you find the raw data interesting.