Installing web apps natively

By -

Web apps have been around for a while, but the ability to install them as if they were native apps is relatively new. This blog post takes a look at what’s currently possible.




Delivering and publishing installable web apps

Web apps are called installable if they can be installed natively. Such apps are currently delivered in either one of two formats:



  • Hosted: the app is delivered as a collection of assets (HTML, CSS, JavaScript, etc.), hosted individually on a web server. Two associated files provide important meta-data:

    • App manifest: specifies information such as: the app’s name; links to icons; the path of the HTML file that is the entry into the app; etc.

    • Cache manifest: enumerates the assets of an app, enabling engines to download all of them and run the app offline.



  • Packaged: the app is delivered as an archive that contains all of its assets. The archive still contains an app manifest, but doesn’t need a cache manifest.


In order to publish a web app, to put it online, two options are common:



  • App store (sometimes also called “app marketplace”): You submit your hosted or packaged app to a central authority which makes the app available to the public. This service may be contingent on the app passing a review process.

  • Self-publishing: you publish the app yourself, via a server that you have access to.


Signing packaged apps

The main reason for the existence of packaged apps is that it is easy to sign them via public-key cryptography: Each app developer gets a public and a private encryption key. Their signature is a hash of the package contents, encrypted via the private key. The signature proves who created the package and is validated by decrypting it with the public key and checking that the resulting hash is correct. The hash also ensures that no one has tampered with the archive.


The kind of signing that I have just described tracks developers, not apps. As a benefit, developers can sign and publish their apps themselves; there is no need to submit them to an app store. But this approach still enables several security measures:



  • If an app does something evil, browsers can blacklist and prevent the execution of all of its developer’s apps. That is, developers can be held accountable for their creations.

  • Signed apps are more trusted and get access to some security-critical APIs that unsigned apps are not allowed to use.

  • A web app’s data on a server can be encrypted via a developer’s private key, meaning that it doesn’t exist in the clear and is a bit safer from attackers.


Obviously, for maximum security and less technically savvy users, this approach can still be complemented by a curated app store where each app has been reviewed.


The state of the art

Apache Cordova (on which PhoneGap is based) is the classic solution for turning web apps into native apps. Alas, it requires intermediate steps: building the native app and – often – submitting it to a proprietary app store. On the other hand, you do get comprehensive access to native APIs.


The platforms supported by Cordova are: Amazon Fire OS, Android, Firefox OS, iOS, Ubuntu, Windows Phone, Windows, and others.


The following subsections cover additional solutions, which often do not require intermediate steps to go from web app to native installation.


Windows, OS X, Linux


  • Firefox: can create native apps from running web apps.



    • Both hosted and packaged apps can be either self-published or submitted to the Firefox Marketplace. It is also possible to run one’s own marketplace.

    • More information: “Quickstart – App Center” by Mozilla.

    • Trying it out: run the quickstart’s demo app in Firefox and push its install button to create and install a native app.

    • Current limitations: First, there can be at most one app per origin (domain plus port). Fixing this is in progress. Second, the only way to install an app is by running installation code from it (e.g. after a button has been clicked). In other words, there is no way to declaratively associate a manifest via a <link> element and let Firefox trigger the installation. Third, on OS X, you must use the context menu to open a native app for the first time (i.e., it is not natively signed and Gatekeeper initially prevents it from running).

    • Bonus feature: Firefox for Android can generate native Android apps.

    • Under consideration: there is an open ticket for supporting Safari-style meta-tags.



  • Chrome: So-called “Chrome Apps” can be hosted or packaged, but they can only be installed via the Chrome Web Store. Thus, self-publishing is not possible on Chrome.



    • Bonus feature: There are tools for turning a Chrome App into a native iOS or Android app.



  • Windows 8: allows you to write native apps in JavaScript, but many of the non-UI APIs are proprietary.



    • Bonus feature: web apps can customize their tiles.



  • Ubuntu: lets you write native apps in HTML5.


Other operating systems


  • iOS: Users can add web pages as icons to the Home screen. In the app switcher, they appear as separate apps with custom icons.

  • Android: Starting with Android 4.0, Chrome contributes a powerful “Add to Homescreen” to the platform. It lets you install web apps so that they look and feel like native apps. (The corresponding feature of the stock Android browser is much less powerful and more like bookmarking.)

  • Windows Phone: You can add web apps to your collection or pin them to your start screen. But they appear as Internet Explorer during app switching and offline operation doesn’t always seem to work reliably.

    • Limitation: Configuration similarly cumbersome to Safari on iOS (but incompatible with it).



  • Firefox OS: Firefox-style web apps are the native apps.

  • Chrome OS: Chrome apps are the native apps. Again: apps can only be installed if they are in the Chrome Web Store.


A standard manifest format for web apps

Currently, the manifest files used by Mozilla and Google are different. However, both companies recently agreed on a common standard. The following are two examples from the specification.


Example 1: a typical manifest.



    {
      "name": "Super Racer 2000",
      "icons": [{
            "src": "icon/lowres",
            "sizes": "64x64",
            "type": "image/webp"
          }, {
            "src": "icon/hd_small",
            "sizes": "64x64"
          }, {
            "src": "icon/hd_hi",
            "sizes": "128x128",
            "density": "2"
          }],
      "start_url": "/start.html",
      "display": "fullscreen",
      "orientation": "landscape"
    }

Example 2: linking to the manifest.



    <!doctype>
    <html>
    <title>Store finder - search</title>
    
    <!-- Startup configuration -->
    <link rel="manifest" href="manifest.json">
    
    <!-- Fallback application metadata for legacy browsers -->
    <meta name="application-name" content="Store Finder">
    <link rel="icon" sizes="16x16 32x32 48x48" href="lo_def.ico">
    <link rel="icon" sizes="512x512" href="hi_def.png">

The future of packaged apps

Apart from signing apps, packages could serve two more use cases:



  • They speed up downloading, because you need less HTTP round-trips to download the contents (as opposed to downloading files individually). A package format could replace current improvised techniques. Longer-term, SPDY and HTTP/2 will solve this problem, too.

  • They would also be useful for bundling content. HTML content usually comprises multiple files, which impairs portability. For example, to email such content, people often ZIP it and send it. Then the recipient has to unpack the ZIP file in order to access the content.


Alas, packaged apps as supported by Mozilla and Google currently have two problems:



  • There is no standard format for them.

  • You can’t access their content without unpacking them. Ideally, web browsers would handle them as if they were unpacked directories.


To fix these problems, Mozilla’s Jonas Sicking recently proposed four measures:



  1. Standardizing a package format that supports streaming and per-file meta-data.

  2. Introducing a Content Security Policy mechanism similar to “self”, but meaning “in the same package” instead of “from the same origin”.

  3. Enabling URL syntax for referring to files inside a package. This could look as follows: http://example.com/myapp.package!//img/logo.jpg (!// would separate the path of the package from the path inside the package).

  4. Standardizing the signing of packages.


Source of this section: “Future of packaged apps” by Jonas Sicking.



Reviewers of this blog post:




Comments

Post a Comment

Popular posts from this blog

Steve Lopez and the Importance of Newspapers

By -
Image
It has been one year since I cancelled my subscriptions to The New York Times and the Los Angeles Times . In that time, I continued to read both publications online. My assessment of this experiment is that reading newspapers and journalism online is vastly inferior to the hard copy thrown on my porch each morning. So I restarted my subscription to the Los Angeles Times and I have made it a point to buy The New York Times as often as I pass one of those coin boxes or my local news stand. The catalyst for this re-evaluation resulted from catching the film, The Soloist on cable last week. I liked the movie, although the scenes I found most interesting were the ones that showed columnist Steve Lopez at work. I realized the book was sitting in my “to-read” stack, so I pulled it and began reading. The book, as I expected, is better than the film. Lopez clearly addresses the revolution occurring in journalism, and worries about his future with the paper even as he researches and writes...
Keep reading

Ideas for fixing unconnected computing

By -
I traveled quite a bit recently and got exposed to a negative aspect of current technology: Things work well if you have a solid internet connection with no traffic limits and are plugged into a power outlet. Otherwise, things do not work well at all. This blog post describes the problems that arise and suggests solutions. Managing data traffic Cell phones are quite good at conserving traffic, laptops much less so. This becomes a problem when your laptop has a mobile connection (e.g., via tethering or in a hotel with data caps). I once accidentally started iTunes in such a situation and immediately used up my daily allowance of traffic. Similarly, mobile email is frugal with traffic (only the current folder is updated, attachments are only downloaded on demand, etc.), desktop email is usually not. How can this be handled better? I’d like to see three traffic modes for all operating systems: “full”, “restricted”, “minimal”: In full traffic mode , all data transfers are allowed and happe...
Keep reading

Omar to kill me

By -
Image
  The sentence “ Omar m’a tuer ” is unintelligible French, as if it had been written by an illiterate person. At first sight, Mme Ghislaine Marchal —the author of those words in blood—seems to be saying that she had been killed by Omar in her villa at Mougins (Alpes-Maritimes). But why would that dying French lady have used such poor grammar? On that flimsy evidence, in 1991, the Moroccan gardener Omar Raddad was condemned and jailed. But he persisted non-stop upon his innocence. In 1998, he was liberated, and now lives in Morocco. A recent analysis of DNA specimens from the scene of the crime provides new facts. Four males, none of whom was Omar Raddad, have left traces of their presence. Will the real murderer be identified at last?
Keep reading