配了五年桌面应用，今天才发现 PWA 的多窗口从来就不是为「多 app」场景设计的——Chrome 152 今天把这件事用 Sub apps 从根上原生化了

你做了一个办公套件：邮件、日历、文档三个模块。以前桌面端只有两个选择：让用户装三个独立的 PWA，或者打包成一个巨大的单块应用让 dock 上一片混乱。Sub apps 这次把它彻底变了。

以前靠什么凑合

2018 年 Chrome App 还有 chrome.app.window.create，能做多窗口，还有自定义标题栏。但 2022 年 Chrome App 彻底死了，这个能力就没了。后来大家只能靠 Electron 或者 Tauri 自己造。

Sub apps 怎么把它原生化了

Chrome 152 的 Sub apps API 让一个 Isolated Web App（IWA）可以暴露多个子应用。每个子 app 有自己的名字、图标、OS 集成，可以独立出现在桌面 shelf 或者任务栏上，有自己独立的文件类型关联和协议处理，但底层是同一个安装包、同一个更新流程。

// 注册子 app
async function addMailApp() {
  const { SubApps } = await import("isolated-web-apps/subapps");

  await SubApps.add([
    {
      // 独立 app 的身份
      manifest_url: "/sub-apps/mail/manifest.webmanifest",
      // 安装时显示的名字和图标走子 app 自己的
    }
  ]);
}

安装后，邮件、日历、文档会作为三个独立图标出现在桌面 shell 上，对用户来说和三个原生应用完全一样。但开发者只需要维护一个代码库、一次更新推送。

安全模型：同源，但不乱授权

Sub apps 共享父 app 的 origin，所有 localStorage、IndexedDB、Cookie 都在同一个存储分区里——权限也是双向共享的，给一个子 app 授权，父 app 也有。但也正因为同源，标准的安全边界在，XSS 拿到的也是子 app 的权限。W3C Web App 社区组专门标注了 identity spoofing 和 launcher hijacking 的风险，Chrome 通过限制 API 只在 isolated context 下暴露来缓解。

一个真实场景

你做了一个设计工具包，里面有图标库、颜色提取、渐变生成器三个工具。以前要么让用户分别装三个 PWA（三个安装流程，三次更新提醒），要么塞进一个工具栏里（臃肿）。现在一个 IWA + Sub apps，一个安装包，三个独立图标，更新只推一次，用户体验和原生应用一样干净。

怎么跑起来

Sub apps API 需要 Isolated Web App 环境，必须通过 chrome://web-app-internals 或者企业策略部署。开发者文档在 GitHub WICG/sub-apps 有完整的 explainer 和示例代码。如果你在用 Electron/Tauri 做桌面应用，先看看这个 API 能不能让你把包袱卸下来——省去的不只是一个窗口，是整个分发和更新体系。

Chrome 152 Stable 已经在路上。如果你的用户需要「一个套件多个工具」，Sub apps 这次把分发这条最难的路给修好了。