[Manifest] Study on installable web apps

(bcc'ing SysApps and WebApps)

Hi,  
Over the last week, the WebMob IG did a somewhat large study of installable web apps based on iOS.  

In the hope that the findings help with standardization of the manifest, I'd like to share the findings and some recommendations with the WGs. 

If you would like to read the whole study, including methods, limitations, and data, see [1]. You can also file bugs there. 

Despite the issues outlined below, we must acknowledge that Apple has done exceptional work in pioneering the concept of "installable web apps" (and continue to make this stuff better and better with each release of iOS). This is not intended to be a criticism of iOS - just a reflection of how the technology is being used in the wild. 

## Key findings
The number of sites claiming to run as standalone is insignificant: of all sites we had access to, they represent 1.4% of the dataset (i.e., 1097 out of 78,155 claim to be "`apple-mobile-web-app-capable`"). So, despite this capability being available since 2009, and irrespective of iOS being the dominant mobile platform, few developers bother to create standalone web apps.

Despite these 1097 sites claiming they can be used as standalone, what we found was that the majority of web apps (90%, or 324 out of 360) **can not be used as standalone**. Only a tiny fraction (10%, or 36 out of 360) are able to run as standalone - and 28% of those had significant limitations (described below). There is, in fact, a greater percentage (12%) of desktop sites masquerading as installable web apps than there are actual standalone applications. 

Another significant problem is that 85% (307 out of 360) of apps rely on a user's ability to follow hyperlinks. iOS standalone apps don't support following hyperlinks: unless a developer intervenes via JavaScript, the default action is to open links in Safari. The data effectively busts the myth of "single page apps": we found that almost no developers build single page apps in practice for this class of application.  

Of those 36 apps that were true standalone web apps (i.e., has an icon, is usable on a mobile device, can be navigated), 10 (28%) of those had issues where they either left the user stranded without being able to "go back" - or worst, suddenly navigated to the desktop version of the site. The only option for a user is to drop back to the home screen and open the application again. This causes iOS to load the page that was originally bookmarked. This itself has problems, in that if the user leaves a web app, its state is effectively lost - meaning the application can lose data. 

In other cases, a web application mostly worked but then it was not possible to perform some critical task within the application (e.g., a purchase). In such cases, the application returned the user back into Safari. Others, like [nest.com](http://nest.com), make a best effort at working as standalone, but throw the user back to the default web browser at random points.  

On the up-side, the majority of web apps (76%) where designed to work on a mobile phone, even if only 13% of those could actually be navigated.

Icon usage, overall, was also fairly healthy - 56% of the web apps we tested included an icon. However, we discovered that at least some web apps included dummy icons from pre-purchased templates - meaning more than one web app included an icon that had nothing to do with the application itself and had the same icon as another site.

Oddly, many web apps (5%, or 19) incorrectly claim that they can run as standalone - but contain a markup error in their HTML that prevents the application from actually doing so! Of those, 12 out of 19 (63%) even go as far as to include an icon. These icons are still useful when the app is added to the home screen or bookmarked - just the web apps won't run as standalone.

For more details, see the "Other observations" and the "All questions" section in [1].

## Recommendations to implementers/W3C
>From our findings, this is what we would recommend implementers and the W3C consider when standardizing this technology. 

* It has to be possible for users to follow hyperlinks in standalone applications. Even though iOS doesn't support this functionality, the data clearly shows developers rely on this core capability of the Web.

* It needs to be possible to open some links in the system default browser: it doesn't make sense to open some links, like ads, within the application.

* It has to be possible to open a browser window within the application: this is to allow OAuth style authentication (which are blocked from working in iframes).   

* It needs to be possible for the user to navigate "back". A significant number of a apps, unfortunately, leave users stranded without a way to "go back" in their browsing history. This is sometimes outside the developers control (e.g., an authentication screen at a different domain doesn't support going back). Having some ability to always go back seems critical to make this class of web application usable by the general public.  

* Do not expect, or encourage, developers to create single page applications. Some will, but they will likely do it wrong. Most everyone won't: it's too hard, unnecessary, and evidently error prone.

* Don't expect applications will have good metadata or icons. 

* Automatically generated metadata and template engines will likely be an issue. A lot of sites don't seem to test (or might not even know) that their websites supports running as standalone. 

* To avoid the issue of UA-specific pop-up banners, a standard way to "install" an application is needed: either through and API and/or some declarative means.

* It needs to be possible to be able to jump between web apps and native apps without requiring the developers to constantly save state. That is, leaving a standalone web application should work the same as jumping from one browser tab to another in a desktop browser. 

HTH,
Marcos 

[1] https://github.com/w3c-webmob/installable-webapps/blob/gh-pages/ios_standalone/README.md  

-- 
Marcos Caceres

Received on Friday, 21 February 2014 18:33:48 UTC