(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).
Ha
