├── LICENSE ├── README.md └── explainer.md /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "{}" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright {yyyy} {name of copyright owner} 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | 203 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # App Install Enhancement Proposals 2 | 3 | This repository is home to a [set of proposals](explainer.md) for improving the state of web and native app installability from browsers. 4 | 5 | 6 | -------------------------------------------------------------------------------- /explainer.md: -------------------------------------------------------------------------------- 1 |

App Install Extensions Explained

2 | 3 | ## What's All This About? 4 | 5 | Modern web applications can engage users as deeply as native/desktop apps. The W3C Manifest Specification provides a route for enabling UAs to offer "installation" of web content. Despite the promise of Manifests and Service Workers, many aspects of appyness are currently missing from the web platform's de-facto OS integrations. 6 | 7 | In particular, web content that is treated by as a top-level app by an OS is still missing: 8 | 9 | - The ability for apps to understand that they've been installed 10 | - API surface area in Service Workers to direct navigation requests to applications and detect that some `Client` instances are launched in "app mode" 11 | - Control from Service Workers regarding requests that should be launched in "regular" tabs (e.g., how does an App decide which navigations are "outside" the app?) 12 | - Agreement between UAs about what combination of URL scopes, Service Worker registrations, and manifest locations constitute "an app" 13 | - Metadata about how to offer associated "native" apps to users 14 | 15 | This document explores each of those challenges, proposes sketches for solutions, and explores challenges. 16 | 17 | This is presented in a single repository to avoid peppering the various existing efforts (Manifests, Service Workers, DOM Events) with seemingly unrelated proposals, although we expect that the outcome will be changes to each of those specs and not a new spec/effort. 18 | 19 | ### Offering Related Applications 20 | 21 | Some platforms support non-web-applications; e.g. 22 | 23 | - [Windows Apps](https://dev.windows.com/en-us) 24 | - [Android Apps](http://developer.android.com/index.html) 25 | - [iOS Apps](https://developer.apple.com/library/ios/referencelibrary/GettingStarted/RoadMapiOS/) 26 | - [Chrome Apps](https://developer.chrome.com/apps/first_app) 27 | - [Firefox OS Packaged Apps](https://developer.mozilla.org/en-US/Marketplace/Options/Packaged_apps) 28 | 29 | We observe that many developers rely on converting users to these "native" app platforms (for reasons that are contested). _That_ it happens pervasively is enough reason for some vendors to [invent](https://msdn.microsoft.com/en-us/library/ie/hh781489(v=vs.85).aspx) [one-off meta-tag-based solutions](https://developer.apple.com/library/ios/documentation/AppleApplications/Reference/SafariWebContent/PromotingAppswithAppBanners/PromotingAppswithAppBanners.html). 30 | 31 | These system-provided banners are beneficial to the overall web ecosystem as they can potentially reduce the amount of "slam door" interstitial prompting that websites do to users. 32 | 33 | Downsides to this proliferation of meta-tag based solutions include: 34 | 35 | - Placement in the `` of documents, which is incredibly sensitive from a page performance standpoint 36 | - Repetition per-native platform. This exacerbates the issues related to precious first-packet bytes in much the same way that the sea-of-icon-tags problem did. 37 | 38 | The [solution](https://developer.chrome.com/multidevice/android/installtohomescreen) for icons has been a [uniform manifest](https://w3c.github.io/manifest/). 39 | 40 | We propose unifying the manifest to support native app install banners. Given a page: 41 | 42 | ```html 43 | 44 | 45 | 46 | 47 | 48 | 55 | 56 | ... 57 | 58 | ``` 59 | 60 | We propose manifest extensions which enable the UA to decide which application to offer: 61 | 62 | ```json 63 | { 64 | "name": "Google I/O 2015", 65 | "short_name": "I/O 2015", 66 | "start_url": "index.html", 67 | "related_applications": [ 68 | { 69 | "platform": "android", 70 | "location": "", 71 | }, 72 | { 73 | "platform": "ios", 74 | "location": "", 75 | }, 76 | { 77 | "platform": "web" 78 | }, 79 | { 80 | "location": "...", 81 | "platform": "..." 82 | }, 83 | ], 84 | "icons": [ { 85 | "src": "images/icon-144x144.png", 86 | "sizes": "144x144", 87 | "type": "image/png", 88 | "density": "3.0" 89 | }], 90 | "display": "standalone" 91 | } 92 | ``` 93 | 94 | If no `"related_applications"` list is provided and the site meets the installability criteria (see below), the web version can be assumed to be the preference. No `location` is required for `"web"` entry as the manifest itself can be considered to describe the web app and the `"start_url"` entry describes the Apps primary entrypoint. 95 | 96 | In some instances, the web version might not be installable (e.g. because of system restrictions on the UA in creating the necessary UI and control surface area). Further, it's obvious that there will be instances where an iOS or Android application won't be available. To accommodate all of these situations, the list is ordered based on developer preference. If and `"android"` or `"iOS"` entry occurs before the `"web"` (or default `"web"`) entry and is appropriate for the UA to offer, an "install banner" might be shown, using the information provided in the manifest to bootstrap the offer process. 97 | 98 | If a `"web"` version is not explicitly provided, it is assumed to be the last (lowest priority, default) entry. 99 | 100 | This system could scale better, be less intrusive, and be less confusing for developers dealing with multiple application than the current hodge-podge of app install hints and expensive header entries. 101 | 102 | ### Controlling Installation 103 | 104 | The [Manifest format](https://w3c.github.io/manifest/) doesn't provide mechanisms for detecting (and responding to) the app installation process or for understanding, once launched, that an app is in "app mode". 105 | 106 | Understanding what (if any) API to provide related to prompting is complicated. For instance, Chrome 42 is going to show Web App install prompts when a conforming app is visited multiple times in the space of a few weeks and _never_ on the first visit to a site. Such criteria make explicit requesting API untennable. 107 | 108 | Having weighed the concerns about spammyness of APIs that would implicitly or explicitly force a prompt to appear for users, it seems the _most_ reasonable way for a site to know if it (or a related application) is being installed is for the system to inform it that such a prompt is being offered. An event in a document may be a reasonable way to model this: 109 | 110 | ```js 111 | window.addEventListener("beforeinstallprompt", function(e) { 112 | // log the platforms provided as options in an install prompt 113 | console.log(e.platforms); // e.g., ["web", "android", "windows"] 114 | e.userChoice.then(function(platform, outcome) { 115 | console.log(platform); // the platform of the app the user took an action on 116 | console.log(outcome); // either "installed", "dismissed", etc. 117 | }, handleError); 118 | }); 119 | ``` 120 | 121 | The rejection handler is used to communicate exceptions (out of disk, etc.). 122 | 123 | A user choosing to dismiss the prompt without installing is provided to the success handler via the outcome value. This can be one of: 124 | 125 | - `"installed"`: indicates that the installation process was successfully started 126 | - `"dismissed"`: indicates that the user dismissed the prompt, rejecting installation 127 | 128 | We further hope that such an API can evolve to handle _delaying_ display of a prompt -- for instance to avoid interrupting users at an inopportune point in a workflow. Such an "install later" capability can be modeled using the same event: 129 | 130 | ```js 131 | var isTooSoon = true; 132 | window.addEventListener("beforeinstallprompt", function(e) { 133 | if (isTooSoon) { 134 | e.preventDefault(); // Prevents prompt display 135 | // Prompt later instead: 136 | setTimeout(function() { 137 | isTooSoon = false; 138 | e.prompt(); // Throws if called more than once or default not prevented 139 | }, 10000); 140 | } 141 | 142 | // The event was re-dispatched in response to our request 143 | // ... 144 | }); 145 | ``` 146 | 147 | ### App Extent & Service Worker Interaction 148 | 149 | Many application platforms provide for [intercepting a subset of URL navigations](https://developer.chrome.com/apps/manifest/url_handlers) or [system actions that lead to navigations](http://developer.android.com/guide/components/intents-filters.html). This has some overlap with [registering protocol handlers](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler), but we can safely consider `http://` and `https://` to be unique. 150 | 151 | Web applications do not, today, contain a single view of what set of URLs specify them as an "app". One obvious option is to consider the set of URLs which a [Service Worker](http://www.html5rocks.com/en/tutorials/service-worker/introduction/) is responsible for handling to be "the app", but applications may want ways to suggest that they don't "own" the navigation and that it should be handled in the default way (e.g., loading a document in a tab instead of navigating inside an application window). Integration of Service Workers into Manifests is an un-yet [unresolved issue](https://github.com/w3c/manifest/issues/161), meaning the easiest answer ("just use whatever the registration in the manifest indicates") isn't sufficient either. 152 | 153 | We propose API to allow an app to dispose of inbound navigations in whatever way it sees fit: 154 | 155 | ```js 156 | // https://example.com/sw.js 157 | onfetch = function(e) { 158 | // Check to see if it's a request for end-user documentation 159 | var requestUrl = new URL(request.url); 160 | if (requestUrl.pathname.indexOf("/docs") == 0) { 161 | // Send to a regular tab 162 | e.default({ target: "_new" }); 163 | } 164 | e.waitUntil(clients.matchAll({ type: "window" }).then( 165 | function(windows) { 166 | // Check to see if we've already got an open app window: 167 | var window; 168 | windows.forEach(function(w) { 169 | if (w.url == e.request.url) { 170 | window = w; 171 | } 172 | }); 173 | if (w) { 174 | return w.focus(); 175 | } else { 176 | // Straw-man syntax for setting a preferred display type 177 | e.default({ display: "standalone" }); 178 | } 179 | } 180 | )); 181 | }; 182 | ``` 183 | 184 | No affordance is provided for _outbound_ link mediation as, in general, this is the fast-path to creating violated user expectations and poor experiences (e.g., "in app browsers" that totally balls up TLS, etc.). 185 | 186 | ### Strawman: Non-App Control Surfaces 187 | 188 | We note that many "native" app platforms provide alternative UI front-ends; e.g. [Android Widgets](http://developer.android.com/design/patterns/widgets.html), [Windows Live Tiles](https://msdn.microsoft.com/en-us/library/windows/apps/hh202948%28v=vs.105%29.aspx), and [iOS App Extensions](https://developer.apple.com/library/mac/documentation/General/Conceptual/ExtensibilityPG/NotificationCenter.html). Each of these system creates alternative entry points into application functionality displayed in non-primary App UI contexts (it can be argued that Notifications are similar, but for now we ignore them). 189 | 190 | The question arises: what if those UI surfaces could be populated by web applications? Some systems allow developers to provide multiple widgets/tiles per application and allow users to select their placement. To accomodate this, we explore a parallel to `"start_url"` which indicates URLs for multiple alternative entry points: 191 | 192 | ```json 193 | { 194 | "name": "Google I/O 2015", 195 | "short_name": "I/O 2015", 196 | "start_url": "index.html", 197 | "widgets": [ 198 | { 199 | "location": "tile.html", 200 | "type": "tile" 201 | }, 202 | { 203 | "location": "widget.html", 204 | "type": "widget" 205 | }, 206 | { 207 | "location": "lock_screen_control.html", 208 | "type": "lockscreen" 209 | }, 210 | ], 211 | "icons": [ { 212 | "src": "images/icon-144x144.png", 213 | "sizes": "144x144", 214 | "type": "image/png", 215 | "density": "3.0" 216 | }], 217 | "display": "standalone" 218 | } 219 | ``` 220 | 221 | To be surfaced to users, the URLs in question must (of course) match the Service Worker scope for the application. 222 | 223 | ### Brand Colors and Launch Icons 224 | 225 | Many application platforms provide the ability for an app to show some sort of startup screen. Web apps tend to be launched in tabs today -- either as new sub-processes which can be cheaply cloned or in-process -- in an environment where initial rendering can safely considered to be "cheap". 226 | 227 | Web apps that launch from the homescreen or start menu may not have such advantages. They may, perhaps, require startup of a browser and renderer process, initialization of GPU contexts, script context creation and application parsing, etc. 228 | 229 | Web applications that must pay the perceptual price for browser startup when the user taps on their icon are therefore at a UX disadvantage to their "native" counterparts because they cannot control what first gets painted in those initial milliseconds -- even if the content from which they will eventually render is entirely local (e.g., via Service Worker). 230 | 231 | Certain native platforms provide hooks for presenting [images](https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/LaunchImages.html) or otherwise provide very-early launch control over paint. iOS has even extended the "launch image" concept [to the web](https://developer.apple.com/library/mac/documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html). 232 | 233 | It is jarring to present a white (or default-color) screen on tap only to have the application draw a different full-screen `background-color` half a second later. To prevent this, we think it useful to allow the Manifest to declare optional colors and images to use at launch. 234 | 235 | There is precedent. Configuration is possible of the status-bar area of mobile OSes. iOS provides this capability to the web using the [`apple-mobile-web-app-status-bar-style`](https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html). In addition, the shipping [`theme-color`](https://github.com/whatwg/meta-theme-color), [`brand-color`](https://groups.google.com/a/chromium.org/d/msg/blink-dev/nzRY-h_-_ig/KR3XWn73tDoJ) and [`msapplication-navbutton-color`](https://msdn.microsoft.com/en-us/library/ie/gg491732%28v=vs.85%29.aspx) meta tags indicate significant interest among vendors in providing at some configurability. Indeed, there is a [related issue open on the Manifest spec today](https://github.com/w3c/manifest/issues/225). 236 | 237 | We propose `"theme_color"` and `"start_image"` extensions: 238 | 239 | ```json 240 | { 241 | "name": "Google I/O 2015", 242 | "short_name": "I/O 2015", 243 | "start_url": "index.html", 244 | "icons": [ { 245 | "src": "images/icon-144x144.png", 246 | "sizes": "144x144", 247 | "type": "image/png", 248 | "density": "3.0" 249 | }], 250 | "display": "standalone", 251 | "theme_color": "#db5945", 252 | "start_image": "images/start-image.png" 253 | } 254 | ``` 255 | 256 | This proposal assumes that the `"theme_color"` entry will be used to both configure initial full-bleed painting for the app as well as configure icon tray color. It is not yet clear to us if there is a desire to configure them independently. If there is, we might imagine a separate `"start_background_color"` property, although the name `"theme_color"` seems to alleviate this concern somewhat. 257 | 258 | ### Strawman: App Install Criteria 259 | 260 | The Chrome team has identified a list of criteria that we equate with "appiness". As runtimes begin to allow and offer [installability for web applications](http://updates.html5rocks.com/2014/11/Support-for-installable-web-apps-with-webapp-manifest-in-chrome-38-for-Android), we have an interest in ensuring that users do not experience poor-quality sites in their "apps" list. Quality is subjective, but we're interested in a subset of quality criteria that can be automated and broadly communicated but which also correlate to maintained and modern, appy content. 261 | 262 | The following straw-man criteria seem to fit that bill: 263 | 264 | - Served at a Secure Origin 265 | - Functionally this means requiring TLS 266 | - Registration of a Service Worker which 267 | - Does not contain parse errors 268 | - Controls at least the current document and the `start_url` of the manifest (see below) 269 | - Registers a non-empty onfetch event handler 270 | - The presence of a Web Manifest which includes at least the following fields 271 | - `short_name` and `name`: 272 | - The descriptive names to use for display, e.g. under a homescreen icon and hover text 273 | - `icons`: 274 | - A non-empty list with at least one icon in with enough density to look good on modern displays. For now that's at least one icon in PNG format that is at least 144x144px. 275 | - `start_url`: 276 | - The location to launch the app at if it isn't navigated to some other way. In essence, a "homescreen" location. 277 | - The `start_url` must be within the registration scope of the Service Worker for the application. 278 | - `service_worker`: 279 | - Optional if the installing site already has a Service Worker that matches both the installing page and `start_url`. A property bag that lists the location and scope of the Service Worker to use for the application. 280 | - Responsive breakpoints & viewport meta tags 281 | - The viewport declaration must be appropriate for mobile design, e.g.: 282 | `````` 283 | - Responsive CSS breakpoints are the most at-risk criteria as it might not be appropriate, e.g., for games 284 | 285 | Runtimes may add additional criteria when deciding if and when to offer appy features (including offers of installation). For instance, Chrome will not prompt users to "keep" applications unless the user has visited multiple times in the past few weeks. 286 | 287 | Similarly, we can envision improving the quality of "app" detection by implementing a server or client-side analysis of Service Workers to determine to what extent applications will respond meaningfully offline, above and beyond the simple presences of an `onfetch` handler. 288 | 289 | #### The Rubric 290 | 291 | ##### Secure Origins 292 | 293 | Good apps don't give your data to third parties without your knowledge. Our ability to trust your behavior as a full-screen application hinges on us already having some confidence that the removal of security indicators won't egregiously degrade the user experience. 294 | 295 | Chrome reserves the right to show URL-bar + security indicators should the security posture of the app degrade; e.g. through the use of Mixed Content on a site that was previously served over entirely secure connections. 296 | 297 | ##### Service Workers 298 | 299 | It isn't an app if it doesn't start when you tap. 300 | 301 | That means all the time, which requires that the app at least boot up to an "offline" screen that's provided by the app and not the browser. Service Workers are the preferred way of providing offline functionality and are therefore required. 302 | 303 | ##### Web Manifests 304 | 305 | We require enough metadata to ensure that we can provide meaningful UI to users who choose to install or "keep" the application in their top-level launcher UI surfaces. 306 | 307 | ##### Responsive Breakpoints & Viewport 308 | 309 | The site must be making some effort to work well on mobile. Apps aren't good citizens unless they do the work to adapt to the viewport. 310 | 311 | Browsers bend over backwards to adapt to legacy content, but for content we wish to offer to users as "first class", there shouldn't be any tap-to-zoom required. The app should simply work well. 312 | --------------------------------------------------------------------------------