v150 · in developer trial (behind a flag)

Sub apps

Sub apps let one Isolated Web App install several distinct apps — each with its own name, icons, shelf identity and OS integrations — under a single install and update process. Chrome 150 exposes window.subApps.add(), list() and remove() in developer trial; ChromeStatus (API, updated 2026-07-24) and the Chrome 152 milestone listing agree on Chrome 152 as the default-on target, with the feature's status text still “Proposed”. These demos call the real API and honestly report the Isolated-Web-App gate when it is not met.

concepts

  1. Capability & context gate

    Run the real four-part probe — secure context, Isolated-Web-App binding, the sub-apps permission policy and a live window.subApps.list() call — to see exactly which prerequisite is blocking the API in this browser.

  2. Install response map

    Build a batch of install paths, call the real window.subApps.add(), and map the returned installedApps / failedApps records path-by-path. Includes the per-app DOMException taxonomy.

  3. Manifest-id round trip

    Follow a sub app's stable identity: add() hands back a ManifestId, list() is keyed by it, and remove() consumes it. Call the real methods and watch the identity flow end to end.

why it shipped

A large Isolated Web App can be a whole suite — mail, docs, sheets — but users expect each of those to be a first-class app with its own icon, window and file-type associations, not one monolithic entry point. Sub apps let a single signed IWA bundle present those as separate installable apps while keeping one unified install, update and trust boundary. Three enterprise policies (DefaultSubAppsWithoutPromptsSetting, SubAppsWithoutPromptsAllowedForOrigins, SubAppsWithoutPromptsBlockedForOrigins) let admins control whether the install prompt is shown.

enabling it

The API only binds inside a secure Isolated Web App with the sub-apps permission policy, and Isolated Web Apps are currently available to end users only on ChromeOS (the API runs on other desktops but is not officially supported there). The documented developer-trial setup, per the official sample: in chrome://flags enable #enable-isolated-web-apps, #enable-isolated-web-app-dev-mode and #enable-sub-apps, then open chrome://web-app-internals and install the IWA (“Install IWA from Update Manifest”, or via Dev Mode Proxy). Implementation/debug note: the runtime-enabled feature is SubApps, so --enable-blink-features=SubApps also gates the binding — but the flags-and-chrome://web-app-internals flow is the documented setup. ChromeStatus (API, updated 2026-07-24) and the Chrome 152 milestone listing agree on Chrome 152 as the default-on target (status text “Proposed”). On an ordinary https:// origin like this one, window.subApps is undefined by design — the demos report that honestly rather than faking a result.

references

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗