(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



Reply via email to