Reputation: 986
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 ?
Upvotes: 4
Views: 819
Reputation: 221
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.
Upvotes: 6
Reputation: 16605
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_related_applications
and prefer_related_applications
for linking to the native appbackground_color
and theme_color
to generate a splash screensplash_screens
object to create a splash screen.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.
Upvotes: 3