HTTP Headers, Web Apps and Mobile Safari

Date Arrow  October 30, 2009

I found today that Mobile Safari, the browser bundled with the iPhone, has a very strange and annoying behaviour when it comes to web apps. In fact, when you “install” web applications with the <meta name="apple-mobile-web-app-capable" content="yes" /> tag in the “Home Screen”, the USER_AGENT header sent to the server is different to the one sent when you access the same app manually using Safari..

Here’s a test that proves this assertion:

  1. Create a server-side web app with your preferred language, and print all the request headers; for example, in PHP:
  2. Launch MobileSafari.app in either the iPhone Simulator or in your iPhone or iPod touch, and access the server-side script you created previously:
    safari1
  3. Add the application to your home screen, tapping the “+” button on the toolbar:
    safari2
  4. Now launch the application from your home screen, and this is what you see:
    safari3
  5. Compare the outputs (above, those from the latest iPhone Simulator, and below, those from my iPhone 3G with iPhone OS 3.1.2):
    Safari: HTTP_USER_AGENT = Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_1_2 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7D11 Safari/528.16
    Home Screen App: HTTP_USER_AGENT = Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_1_2 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Mobile/7D11

    The texts in italic show the differences between the two outputs.

This difference (in italic above) is only visible when the HTML generated by the server-side script contains the <meta name="apple-mobile-web-app-capable" content="yes" /> tag, which triggers this change of behaviour. Otherwise, the outputs are exactly the same. Most annoyingly, this behavior is not documented (at least not that I am aware of). This problem has already been spotted elsewhere (scroll down until you see the comment by DVO published on Jul 3, 2009 at 7:34 AM; thanks to my friend Bertrand for the link!).

This is not only weird, but it also might break libraries used to generate iPhone-ready websites out of existing web apps (by redirecting the browser using the information in the USER_AGENT header; for example, this is what happens with the current version of the Rails iUI plugin (which is why I found this behaviour :)

The lesson of all of this mess is this: if you have to test for Safari on the iPhone, do not use the word “Safari”, but rather use “AppleWebKit” and “Mobile”, to be sure of catching also the users who installed your application in their home screen.

Update, 2009-10-30: In particular, the line of the Rails iUI plugin that causes problem with this particular behavior is this one.

Similar Posts:

Tagged   How to? · iPhone

2 Comments

  • #1.   Andrew Deal
    11.02.2009

    well, yeah.. use applewebkit in your detection scripting anyway, because the real value of these apps are that they should work in G1’s, Palm Pre’s and the new Droid coming later this month.

    If anyone has the USER_AGENT signature for the Droid, please pass it on.

    Thanks

  • #2.   RichR
    12.18.2009

    I find it useful to distinguish between my pages displaying in Safari as opposed to as a web app. For example I change href links on the page to form submits if it is a web app, otherwise the user gets switched from the web app look to Safari.

Commenting

←
→