4

Both FF and Chrome have started supporting progressive web apps using app manifest and service workers.

So what are the key differences to keep in mind while writing a manifest (or the same manifest file can work on both).

And if it is a hosted webapp (not a packaged one), what differences are there in the process to make the user install it ?

Arnav Gupta
  • 916
  • 12
  • 14
  • @wOxxOm Thanks. Done the same :) – Arnav Gupta Nov 25 '15 at 19:09
  • 1
    Gotta be careful here. The term (and tag) Chrome App means [something different](https://developer.chrome.com/apps/about_apps). – Xan Nov 25 '15 at 20:04
  • Lol, way too many people concerned with the tags in the question, than actually answering it. – Arnav Gupta Nov 26 '15 at 01:30
  • 2
    Doesn't help that the whole area of apps/extensions is a minefield of closely named but different things that Mozilla and Google call differently. I bring my Chrome App knowledge to say "your question isn't about a Chrome app". – Xan Nov 26 '15 at 07:17

2 Answers2

6

There's a lot going on in this question. I'll try to sort it all out by providing some history and then answering several of the questions that the OP could be asking.

Background

Packaged Apps

Chrome, Firefox, Opera and many other platforms have at various times had "packaged" application platforms which run HTML/JS/CSS content but which are not on the web. These generally use some sort of manifest file combined with zip-like packaging and directory structure (and sometimes signing) to distribute applications. These applications generally have not participated in the Same Origin Policy or run with the same constraints and capabilities as web content; frequently these packages are served via proprietary stores and feature capabilities and APIs not yet available to "plain old web content".

The manifest formats for these applications -- at least in the case of Chrome Packaged Apps and Firefox Packaged Apps -- is a JSON file whose content and options are not standardized.

Hosted Apps

Some systems have fused the extra capabilities provided to their proprietary packaged application systems with "real" web-based hosting of applications to create "Hosted Applications". These come in many flavors, but the TL;DR is that they also tend to feature JSON-based proprietary manifest files. See, e.g., the documentation for Chrome Hosted Apps, Firefox Hosted Apps, and Windows 10 Hosted Apps.

Again, these systems are proprietary, non-standard, and non-interoperable despite the content in question coming from the "real web" (unlike their Packaged App cousins).

Progressive Web Apps

Progressive Web Apps are different from both Packaged Apps and Hosted Apps in that they are just "plain old web content" which also happens to point to a Manifest file based on the standards-track Web App Manifest format.

This format is what Chrome detects and uses to trigger the "Add-to-Homescreen" behavior and which Opera currently uses when you manually add something to your homescreen (and, in the future, when Opera prompts).

Mozilla has signaled support for this format their engineers have been heavily involved in the design and evolution of the standard. I'm optimistic that this will evolve into support for UI based on standard, not proprietary, manifests.

Mozilla is also on track to ship support for Service Workers in the coming months, which will set the stage for interoperable "install" behavior between Chrome, Opera, and FF. Exciting times.

Alex Russell
  • 221
  • 2
  • 3
  • Thank you so much for the detailed answer. This actually clears some other doubts I had, which I had not even asked in the question too :) Another question that comes to mind is, using the w3c standards-track progressive app manifest, what special features do I get for a desktop experience (I get that for mobiles, it is a huge thing, as it allows in a way "installing" a website to your home screen). – Arnav Gupta Nov 27 '15 at 08:10
  • 1
    You probably want to as that in a different question so people can elaborate there :). As a sneak peak, you get support for push notifications (so you can define the sender_id) and things like theme color and default orientation on the very few platforms (other than android) where it makes sense – Miguel Garcia Nov 27 '15 at 10:44
3

There are two things at play: Legacy and Future.

The Legacy part (for want of a better phrase) is the old style packaging systems (although they still all work). Both Mozilla and Chrome have their own packaging formats and JSON manifests that are roughly similar. I personally would stay away from both of these and focus on the future.

The Future facing system Web App Manifest which is supported by Chrome and is used in the Install experience on Android. It is also supported by Opera and Firefox OS. The manifest you write on both should work on all platforms. Obviously each implementation is at different stages for example:

  • Chrome has chrome_related_applications and prefer_related_applications for linking to the native app
  • Chrome supports background_color and theme_color to generate a splash screen
  • Firefox needs a splash_screens object to create a splash screen.
  • Firefox defines a scope that tells the browser the url paths that are considered part of the app. Chrome and Opera ignore this.

I will say that Web App Manifest now at least define a "consistent" vision for installable web apps.

Kinlan
  • 16,315
  • 5
  • 56
  • 88
  • Does Chrome document which fields are (currently) supported? I think, web devs would find a good support table quite useful. – Šime Vidas Nov 27 '15 at 07:11