Desktop Progressive Web Apps(PWAs) are a great cross-platform, cross-browser way to build apps with a security model that centers user safety and privacy and get built-in sharing with the web’s inherent linkability. Build new or enhance your existing web app with modern APIs to give them desktop-app like capabilities, reliability, and installability. PWAs are the best way to deliver your web app for Chrome OS.
On Chrome OS, the power of the web platform is front and center; web apps are a core platform feature. Installed PWAs show up in the Chrome OS launcher, can be pinned to the shelf, and integrate deeply with the rest of the OS.
Get started by reviewing the PWA Checklistand making sure your web app passes the core PWA checklist. You can use PWABuilderto help you provide a custom offline page and make your app installable. Then, use these recommendations to make your PWA shine on Chrome OS.
One of the great advantages of PWAs over regular web apps is the ability for them to be installed, just like traditional desktop apps. The Progressive Web App path on web.dev has a section dedicated to making your PWA installable; use that to get started. In order for a PWA to be identified as installable on Chrome OS, the following criteria must be met, which can be checked using Lighthouse’s installable audit:
- It must have a valid web app manifest
- It must meet Chrome’s install criteria
- For PWAs on Chrome OS, an install prompt will show in the omnibar without a user engagement heuristic threshold being met.
Icons are an important part of your PWA’s identity, so make sure they are interesting and unique; they can even include transparency! As PWAs have one codebase that’s shared across all platforms, you should ensure you have a maskable iconavailable. Ensure you also include normal icons, too, for operating systems that don’t support maskable icons.
With your PWA installable, it’ll now show up across Chrome OS, from the launcher to the shelf. Having your PWA installed also opens up some additional capabilities to make your app really shine.
There are plenty of discoverability, usability, and capability advantages simply by making your app installable. Making your PWA installable does not mean your whole experience must work offline. In order for an installed web app to feel like a traditional app, though, it should have some form of offline functionality. A basic custom offline page is enough to get started; users expect that installed apps don’t crash when connection status changes. Just as a traditional app never shows a blank page when it is offline, PWAs should never show the browser default offline page. Custom offline pages can range from a message letting the user know they need a connection to a game to let them pass the time until they’re connected again. Providing this custom offline experience for uncached pages or features that require a connection helps to bridge the user experience app gap.
You can create a simple offline page during a service worker’s
install event by precaching the desired page for later use and responding with it if a user is offline. You can follow our custom offline page sampleto see an example of this in action and learn how to implement it yourself.
If you want to provide a more robust experience, in addition to the Cache Storage API, you can use features like IndexedDBfor in-browser NoSQL storage and background syncto allow users to take actions while offline and defer server communication until the user has a stable connection again. You can also implement patterns like safe, long-lived sessionsto keep users authenticated and skeleton screensto quickly let users know you’re loading content that can fall back to cached content or an offline indicator if needed.
Almost all Chrome OS devices support touch and many support styluses, too, so you need to ensure that your app works seamlessly with both inputs in addition to the normal keyboard and mouse. The pointer events APIis designed specifically to handle this! Some fundamental pointer-related events you likely won’t have to change, like
click events. Other events, like
touchstart, should be migrated over to their pointer events counterparts to make them seamlessly work across any kind of pointer. You can even manage different input typesseparately if you’d like. For apps and games that rely heavily on tactile user input, moving to the pointer events API will make a world of difference on Chrome OS devices.
If you’re building an app that has users drawing with their fingers or styluses, keeping latency between their input and your output fast enough to feel fluid has historically been difficult. When building these kinds of Canvas APIpowered apps for Chrome OS, we recommend using the
desynchronized hint for
canvas.getContext() to provide low-latency rendering. To use the
desynchronized hint for a canvas, do the following:
It is important to take touch and stylus support into consideration when designing your web apps. Interactions that you may take for granted, like hover, don’t work well, if at all, for other input methods. Here are some best practices to keep in mind when designing touch and stylus friendly interfaces:
- Don’t make input assumptions based on screen size. Instead, use feature detection, ideally at input time, to determine how to respond. Remember, on Chrome OS, users can and do seamlessly swap between mouse, touch, and stylus all within one session.
- Ensure that elements you expect a user to touch have a minimum target sizelarge enough so surrounding elements aren’t accidentally hit instead.
- Treat hover as progressive enhancementand ensure the interaction can be accomplished through other means for touch and stylus (a long press or a tap, for example).
- Touch users expect to be able to directly interact with on-screen elements, for instance pinch-to-zoom on maps instead of using zoom in/out buttons. Adding common touch gestures, where appropriate, can go a long way to making your app feel natural.
While some PWA capabilities are commonly known, like the Notifications APIthat lets a web app receive and publish platform notifications, there are a number of new and upcoming features that are coming to the web to superpower your apps. The Chromium Web Capabilities project, also known as Project Fugu 🐡, is an effort to enable new, powerful web standards preserving what makes the web unique: it’s user-centric security, low-friction, and cross-platform compatibility.
Most of these capabilities are built around bridging the gap between traditional desktop apps and web apps, with the first major capabilities to ship allowing web apps to access the platform’s contact pickersand share capabilities, and installed PWAs to register as a platform share targetand show icon badges, to name a few.
Each capability goes through an extensive standardization processto solicit community feedback to help shape the API and ensure the final design is secure, private, and trustworthy. New capabilities are tracked in an open trackerand can divided into one of five categories:
- Available for use in the latest stable version of Chrome. Can be reliably used provided its use is properly feature detected.
- In Origin Trial
- Available as a Chrome origin trial(OT), allowing experimental features and APIs to be validated by the Chrome team in real-world usage and allowing you to provide feedback on API usability and effectiveness. OTs are opt-in and allow you to beta test this functionality with your users without requiring them toggle any special flags in their browser. APIs may change after an OT, and OTs are guaranteed to not be available for a period of time before launch, so they shouldn’t be treated as an early launch mechanism for new APIs.
- In Developer Trials
- Available behind a flag in Chrome. These APIs are experimental and still under active development. They are not ready for production use, with a good chance that there are bugs and that the APIs will change. It is highly recommended not to encourage users to change flags to enable features. Developers can use this time to experiment with experimental features on their own.
- Development has started, but no usable API currently exists.
- Under Consideration
- APIs that users have expressed interest in, but implementation hasn’t started yet. If an API hasn’t been started yet, please star it or add your use cases to its issue to help the Chromium team prioritize it.
With so many new capabilities coming up, it is hard to narrow down a list of what’s going to have the most impact to building web apps on Chrome OS. These are a few key APIs that will expand what kinds of apps can be built on the web and, in turn, for Chrome OS.
- Screen Enumeration and Window Placement
- The Screen Enumeration APIand the Window Placement APIare two complimentary APIs that, when used together, allow web apps to understand what displays are available and open and position windows programmatically across those screens. With these APIs, web apps like presentations with speaker notes, multi-window dashboards, or canvases with toolbars.
- File Handling
- The File Handling APIallows installed PWAs to register their ability to handle (read, stream, edit) files with given MIME types and/or file extensions. This API allows installed PWAs to show up in a platform’s file system’s “open with…” dialogs when opening a file, and allow users to set the PWA as the default application for supported file types.
- Tabbed Application Mode
- Tabbed application modeallows developers to specify that their PWA should divide its window into tabs, similar to a tabbed web browser, except that all of the tabs belong to the app (and don’t have a URL bar).