Open Radar

 
iOS has the feature to bookmark webapps onto the homescreen. If the webapp has <meta name="apple-mobile-web-app-capable" content="yes" />, then such a bookmarked webapp will be launched without safari's chrome. It is expected that such a webapp will act more like a native iOS app if not at least like the webapp is being run within Mobile Safari but with the UI hidden.

Steps to Reproduce:
1. Visit http://read.amazon.com/ in Mobile Safari on a supported device (iPad)
2. Follow the instructions to add the app to your homescreen.
  a. If you have already installed this app, first remove it from Safari's cache. The app has already been installed if visiting http://read.amazon.com/ does not result in being asked to "Sign In or Create New Account".
    i. Go to Settings.
    ii. Go to the Safari section of Settings.
    iii. Tap Advanced =>.
    iv. Tap Website Data =>.
    v. Swipe left over the "read.amazon.com" entry.
    vi. Tap Delete.
    vii. Double-tap the home button to open the backgrounded tasks manager.
    viii. Tap and hold on Safari.
    ix. Return to step 1.
  b. Sign in using your Amazon account.
  c. Follow the instructions for allowing the webapp extra space.
  d. Follow the instructions for adding the app to your home screen.
3. Launch Cloud Reader from your home screen.
4. Double tap the home button to open the backgrounded tasks manager.
5. Tap on Safari and observe that the webpage open there is restored in its current state as expected and instantaneously.
6. Double tap the home button to open the backgrounded tasks manager.
7. Tap on Cloud Reader.
  a. Observe that the app is restarted and note that switching takes up to 6 seconds before the webapp is usable, especially if a book had been opened.

Expected Results:

The switch in step 7 should have completed instantaneously and without re-cold-starting the webapp. The switch in step 7 should have behaved more like the switch in step 5. The webapp should not be returned to its original URI when it is resumed. The webapp should retain session-state items, such as session cookies, when backgrounded.

Actual Results:

The switch in step 7 cold-started the webapp, took 4+ seconds to perform, etc.

Regression:

Any app running in the full-fledged Mobile Safari does not have this problem. Enabling <meta name="apple-mobile-web-app-capable" content="yes" /> enables features such as fullscreen mode and uncluttering the webapp with Mobile Safari's UI, yet adding this tag to a webapp causes it to lose backgroundability when launched from the home screen. These features of backgroundability and fullscreen usage should not be mutually exclusive. Having both of these features concurrently is more essential on the iPod Touch because 1. webapp loading time is longer due to the lower hardware specs 2. there is less screen space on the iPod Touch, so any gains in screen size such as that available through the apple-mobile-web-app-capable meta tag are invaluable.

Notes:

This bug also applies to the iPod Touch and is more problematic on the iPod Touch because webapps take longer to load on the smaller-profile devices and the iPod Touch has a smaller screen (making fullscreen mode desirable).

The user would expect the webapp to be instantly resumed when backgrounded and reselected from the backgrounded tasks manager (which can be seen by double clicking the home button). However, instead, when restoring the webapp the old state of the webapp is discarded and the webapp reloads itself. During this reload process, all session state, such as session cookies, is dropped. Also, during the reload the user must wait at least four seconds for the webapp to reload -- even when the webapp is cached using http://www.w3.org/TR/html5/offline.html#offline .

Fixing this bug would not exempt webapps from the responsibility of storing and restoring state. The user may manually terminate the webapp, or iOS may be restarted, or the webapp may be stopped for memory reclamation. Even native apps are expected to be able to retain and restore some amount of state during a cold start. However, there is the app's "micro-state" (session-level state) which is expected to be resumed. An example of micro-state can be found in iOS itself. For example, opening a specific person's contact in the Contacts app causes that same contact to be viewed when the user backgrounds Contacts and then resumes it shortly thereafter. However, restarting iOS or manually terminating Contacts causes this micro-state to be forgotten and for the app to show the listing of all Contacts. It doesn't make sense to save the currently displayed contact because that is part of the micro-state, information that the user will only find relevant for a short amount of time -- while the user may switch back to review the same contact multiple times in a short time period.

However, I recognize that fixing this bug would be a change which could potentially affect how people would write web apps for iOS devices. The main issue I imagine is that the webapp developer may provide no way to restore the webapp to its initial state and users might be used to just relaunching the bookmark to restore the webapp to its initial state. For example, a bookmarked webapp may direct the user to an external website unrelated to that webapp and leave the user "stranded" and unable to return to the webapp without terminating it through the backgrounded tasks manager. Thus, I suggest that a new meta tag be defined, such as <meta name="apple-mobile-web-app-backgroundable" content="yes" />, to allow webapps to request this behavior.