Jeff dePascale Blogging on and developing web and mobile technologies

29Jan . 102Reading post by @jeffdePascale: Why the iPad’s user agent string presents a problem

Tweet This

Why the iPad’s user agent string presents a problem

The initial impressions are just about done flowing in on Apple's new tablet device, the iPad. Developers in the iPhone dev program were granted access to the new development SDK immediately after launch, but one area that is still largely in the dark is web development for the iPad.

The iPad simulator included in the SDK does not include mobile Safari, however twitter user yassiryaha managed to figure out the browser's user agent string, probably by applying a UIWebView within a test app and tracing out the value. User agent strings, for those who don't know, are effectively an identification to the page being loaded to say what browser is loading it, it's security level, and other useful information for developers to serve up their content as best as possible for the content consumer's platform.

The user agent string for the iPad, and why it matters, is after the break.

NOTE: Edited after reader Andrew provided more accurate - and more consistent - information.

The iPad's user agent string:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9

Edited: Mozilla/5.0(iPad; U; CPU iPhone OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B314 Safari/531.21.10

I've left my argument below so as to not mislead my readers - I made a leap of faith and followed a random twitter users post on the topic without doing the due diligence to verify that data, and that was both dumb and wrong! The reality is that, assuming reader Andrew is correct, the iPad represents itself in line with how the iphone and iPod Touch differentiate themselves by specifying different device strings. This makes more sense - but the argument below is still somewhat relevant in that we do have a new class of devices to case for. On tomy somewhat now invalid argument!

remainder of original post:

This is intriguing and presents an interesting new issue for web developers. Why? Take a look at OSX's Safari user agent strings. The user agent string for the iPad represents itself exactly the same as the desktop version of Safari does. I can see why Apple would do this. The iPad is meant to be a full web experience device. But there's a problem with that argument. This isn't the desktop version of Safari. While they are both webkit based, it is inevitable that considerations will want to be made for the glorified Safari mobile browser in the iPad, and using the user agent string to identify that and case for it just wont be possible unless Apple modifies that string identifier before release.

It's not so much that this matters for development as much as that it sets a precedent for future slate browsers. Apple has said here that slate browsers, even if they are larger versions of existing mobile browsers, should identify as a desktop browser. What about plugins? Flash is the biggest issue to contend with there, but modern flash embed techniques all account for displaying default content when the plugin is unavailable, so proper implementation of graceful degradation techniques can overcome that issue. Interestingly enough, this is exactly how Apple recommends iPhone OS developers case for iPad vs. iPhone vs. iPod Touch hardware, via method availability, since Objective C returns graceful nils. So is that the precedent Apple is setting here for web development as well? Perhaps. And maybe this will all be null and void by the time the OS 4.0 SDK and the iPad land in March. As with all things Apple launch related, time will tell. One thing you can count on is that Apple put a lot of thought into this decision, and for right or wrong, if the iPad succeeds, the precedent will be set.