PWAs on ChromeOS (launcher, shelf, file handling)

In one line: once installed on ChromeOS, a PWA shows up in the launcher alongside other installed apps, can be pinned to the shelf, and can opt into OS integration — a badged app icon, Web Share/Share Target, and File Handling — through the same web app manifest and capability APIs used on other desktop Chromium platforms.

Installing and appearing in the launcher

Per Google’s ChromeOS developer documentation, an installed PWA needs a web app manifest (to supply its name, icon, start URL, and display mode) and a service worker for offline support; once installed it “will show up in the launcher where the user can pin it to their shelf and quickly access it,” alongside natively installed apps.

Badging, sharing, and file handling once installed

Per chromeos.dev, an installed ChromeOS PWA can use several capability APIs to feel more like a native app:

• Badging. Per chromeos.dev, the Badge API puts a small circle on the app’s shelf icon as a visual cue.
• Web Share and Web Share Target. A PWA can share content out to other apps and register itself as a share target so other apps can share links, text, or files into it.
• File Handling. The File Handling API lets a PWA register file types so the OS can “Open with…” it.
• App shortcuts. A manifest’s shortcuts member adds entries to the icon’s right-click menu for quick access to specific in-app actions.

async function shareToApps(data) {
  if (!('share' in navigator)) {
    return false; // Web Share unsupported: show the app's own share dialog instead.
  }
  await navigator.share(data);
  return true;
}

Where it is supported

Per the ChromeOS developer documentation, individual PWA capabilities each roll out on their own timeline and “cross-platform support, even stable support in ChromeOS, can sometimes be a multi-year process” — so a capability shipping on Windows/macOS/Linux Chrome is not guaranteed to be available on ChromeOS at the same time.

Feature detection and fallback

Badging, sharing, and file handling are each independently-shipped capabilities, so detect each on its own rather than assuming “installed on ChromeOS” implies all of them. Per MDN, window.launchQueue is how an app receives the files a user opened it with:

async function setLauncherBadge(count) {
  if (!('setAppBadge' in navigator)) {
    return; // Badging unsupported here: no launcher/shelf indicator to update.
  }
  if (count > 0) {
    await navigator.setAppBadge(count);
  } else {
    await navigator.clearAppBadge();
  }
}

if ('launchQueue' in window) {
  window.launchQueue.setConsumer((launchParams) => {
    if (!launchParams.files.length) return;
    handleOpenedFiles(launchParams.files);
  });
} else {
  // File Handling unsupported: fall back to the app's normal in-app file picker/upload flow.
}

Practical checklist

• Ship a complete manifest (name, icons, start_url, display) — per Google’s ChromeOS docs, it drives how the app appears in the launcher and on the shelf.
• Feature-detect navigator.share, navigator.setAppBadge, and window.launchQueue independently; each capability rolls out and reaches ChromeOS on its own schedule.
• Provide a working fallback UI (in-app share dialog, no badge, normal file picker) for any capability the check finds missing, rather than leaving a dead code path.
• Declare manifest shortcuts for the actions users repeat most, since they surface directly on the icon’s right-click menu once installed.
• Verify installed behavior on a real ChromeOS device before shipping ChromeOS-specific claims, since per the ChromeOS developer documentation a capability’s availability can differ by platform.

Where to go next

• PWAs on Chrome and Android (WebAPK, TWA)
• File System Access API