渐进式 Web 应用：PWA 何时胜过原生应用

渐进式 Web 应用开发，是英国买家在项目开始的头十分钟里排除掉、又在十八个月后重新发现的方案，那时第二套原生代码库已经悄悄吃光了预算。它之所以被排除，是因为关于它的文字几乎都落在两个阵营里：跳过 iOS 拒绝做的那部分的鼓吹，或者继承自 2019 年、当时平台确实做不到的怀疑。

两者现在都错了，而且错在会改变成本账的地方。自 iOS 16.4 起，Safari 已支持添加到主屏幕的 Web 应用发送推送通知。Chrome 取消了安装对 Service Worker 的要求。英国监管机构在 2025 年 10 月认定苹果和谷歌在移动浏览器与浏览器引擎上具有战略市场地位。与此同时，iOS 仍然拒绝后台执行，会按你无法控制的规则清除已存数据，并且永远不会把 Web 应用列进 App Store。

下面是我会交给正在一套代码库与三套之间做选择的客户的版本。文中每一条能力主张，都在 2026 年 9 月对照厂商自己的文档核对过，因为这个话题里的流行说法可靠地落后两年。

PWA 什么时候胜过原生应用？ 当你的用户在安卓和桌面上和在 iPhone 上一样多时，当应用是服务器而不是设备的前端时，以及当人们通过搜索而不是通过应用商店找到你时。如果你需要后台定位、主屏幕小组件、iPhone 上的蓝牙或者商店内购结算，PWA 就输了。省下的是一套代码库而不是三套，按英国的行情大约是 £40,000 到 £120,000 的建设费，以及此后每年明显更小的账单。

渐进式 Web 应用究竟是什么

这个术语被用得足够宽泛，以至于同一场会议里的两个人可能指的是不同的东西。技术定义很窄，值得守住。

MDN 把渐进式 Web 应用描述为用 Web 平台技术构建、能给用户带来类似平台专属应用体验的应用。它从一套代码库运行在多个平台上，可以被安装、离线运行，并与操作系统集成。

在实践中这意味着三件产物，缺少其中任何一件的站点，都只是有野心的网站，而不是 PWA。

Web 应用清单

清单是一个 JSON 文件，它告诉操作系统这个应用叫什么、用哪些图标、启动时打开哪个网址，以及是在浏览器框架里运行还是独立运行。没有它，浏览器就没有可安装的东西。它很小、是静态的，也是整件事里最便宜的部分。

Service Worker

Service Worker 是一段独立于页面运行的脚本，坐在应用与网络之间，能够用缓存回应请求。它让离线行为成为可能，也是接收推送消息的那一环。它同样是容易出错的一环，因为作用域划错的缓存会连续几周把过期代码送给用户。

HTTPS

Service Worker、推送、地理定位和摄像头访问都被限制在安全上下文中。在今天的托管环境里这是免费且自动的，所以它是一项约束，而不是一笔成本。

已安装这件事在各平台上的含义并不相同

买家以为安装是一种行为。它其实是三种，而其中的差别与生意直接相关。

安卓

安卓上的 Chrome 给出最接近对等的效果。应用得到一个主屏幕图标、在任务切换器里有自己的条目、有自己的存储空间，并且可以通过外壳包装列进 Play 商店。在浏览器触发相应事件之后，你可以从自己的界面发起安装提示，所以由你决定什么时候开口。

iOS 与 iPadOS

Safari 通过分享面板和其中的“添加到主屏幕”来安装。没有你能主动触发的页面内安装提示，没有苹果会替你展示的横幅，也没有可靠的方法检测用户是否已经这么做了。这一处交互上的空缺，是各平台之间最大的实际差别，而它是设计问题而非工程问题：你必须教会用户一个手势。

桌面

Chrome、Edge 和 macOS 上的 Safari 都会把 Web 应用装进程序坞或任务栏，并给它自己的窗口。桌面是 PWA 争议最少、也最被浪费的地方，尤其是在内部工具上，那里的替代方案是一套没人愿意维护的 Electron 构建。

Chrome 改了可安装规则，而多数指南没有注意到

多年来每篇文章都重复同一份清单：清单文件、图标、HTTPS，以及一个实现了 fetch 处理器的 Service Worker。最后这一条对从菜单安装的路径已经不再成立。

谷歌取消了从菜单安装时必须有实现 fetch 的 Service Worker 的要求，移动端从版本 108 起，桌面端从 112 起，并且现在为没有自备离线页的站点提供一个默认离线页。安装提示的算法仍然希望看到 fetch 处理器，但可安装性本身已经不再依赖它。

连锁反应波及了工具链。Lighthouse 在 12.0.0 版中整个删掉了 PWA 类别，那是 2024 年 4 月发布的版本，因为那些审计存在的目的就是检查一批已经不适用的条件。如果你的构建流水线还会因为缺少 PWA 评分而失败，它检查的是谷歌已经废弃的东西。

务实的读法是：安装与离线能力已经解耦。你可以发布一个完全没有离线故事的可安装应用，这往往正是正确的首个版本，等你知道人们在没有信号时真正使用哪些页面之后，再补上缓存。

离线是一个带成本的设计决定

离线这个词掩盖了极大的范围跨度。一个显示上次已知数据的缓存外壳是一周的活。一个真正离线优先、会把写入排队、解决冲突并在重连时对账的应用，是另一个产品。

缓存策略

Service Worker 的缓存归结为四种模式，以及针对每类资源的一次判断。缓存优先直接返回已存副本而从不核对，适合字体和带哈希的构建产物。网络优先先试服务器再回退，适合必须保持最新的数据。stale while revalidate 立刻返回缓存并在后台刷新，是内容的常规选择。仅网络用于任何绝不能由过期副本作答的东西，比如支付。

把这里搞错，是我见过最常见的 PWA 失败。把缓存优先用在应用外壳上，会一直把上个月的 JavaScript 送给回访用户，直到有什么东西强制更新为止，而收到的缺陷报告描述的症状在你当前的代码里并不存在。

后台同步

在离线时把写入排队、在恢复连接时冲刷出去，正是 Background Synchronization API 的用途。MDN 将它列为有限可用并明确指出它不属于 Baseline，也就是说它在一些使用最广泛的浏览器里并不工作。

所以在 iOS 上你要自己写回退方案：把队列持久化到 IndexedDB，在应用下次被打开时冲刷。这样能用，用户也接受，而它大概是三到五天的工程量，而不是这个 API 本可以只花的一个下午。

推送通知决定的项目比任何别的因素都多

如果有一项能力能沉掉一份 PWA 提案，就是它，而且依据通常是 2022 年才成立的事实。

安卓与桌面

安卓 Chrome、桌面 Chrome、Edge 和 Firefox 上的 Web 推送，靠 Push API、Notifications API 和 Service Worker 协同工作已经多年。投递由浏览器厂商的推送服务负责，授权是一个标准提示，在服务器向已订阅用户发送消息这一常见场景下，与原生应用没有有意义的差距。

iOS 与 iPadOS

苹果在 iOS 与 iPadOS 16.4 中加入了 Web Push。附带的条件才是常被忽略的部分：WebKit 说明该 Web 应用必须已被添加到主屏幕，并且授权必须响应直接的用户交互来请求，比如点击一个订阅按钮。对停留在 Safari 标签页里的站点，Web 推送不工作。

清单必须把 display 设为 standalone 或 fullscreen，此后通知的表现就和任何其他应用一样：锁屏、通知中心、配对的 Apple Watch，以及设置里按应用的开关。徽标计数也可用。

苹果后来又加了一条更简单的路径。声明式 Web 推送随 Safari 18.4 到来，在 iOS 与 iPadOS 18.4 上对添加到主屏幕的 Web 应用可用，它无需 Service Worker 正在运行就能依据一段标准化的 JSON 载荷显示通知。它减少了工作量，但没有取消主屏幕这个条件。

精确地陈述 iOS 上的差距

差距是真实的，也比它的名声小。准确地把它说清楚，比抱怨它或者假装它已经消失都更有用。

存储被清除

WebKit 按最近最少使用的原则清除网站数据，其中最后一次使用是从最后一次用户交互或存储操作算起的。它的存储策略文档规定，浏览器类应用的单源配额最高为磁盘的 60%，其他应用最高为 15%，总配额分别为 80% 和 20%，并确认独立运行的主屏幕 Web 应用与浏览器享有相同配额。

由此得出两点。存储并不是人们想象中的那个限制，而清除是一种时机风险，不是容量风险。把设备当作缓存、把服务器当作真本，清除就不再是产品缺陷。

后台执行

iOS 上没有与原生后台任务等价的东西。没有周期性抓取，没有后台定位，应用关闭期间也没有静默处理。任何必须按计划发生的事都发生在你的服务器上，再通过一条用户看得见的推送消息抵达设备。

无法出现在 App Store

PWA 不能被列进 App Store。如果你有相当比例的客户期待在应用商店里搜你的品牌并找到你，那不是你能在 Web 一侧解决的工程问题。

浏览器引擎、DMA 与 CMA

这一节里报道跑在了一手资料前面，所以值得只谈真正被写进文档的部分。

苹果现在允许替代浏览器引擎，而且明确说明这只适用于欧盟，在 iOS 17.4 或更高版本以及 iPadOS 18 或更高版本上，通过授予符合已公布的安全、隐私和测试套件标准的开发者的两项权限来实现。苹果要求通过 90% 的 Web Platform Tests 和 80% 的 Test262，要求在没有 JIT 的情况下运行，并要求多数漏洞在 30 天内解决。

对英国企业来说，这些今天不改变任何事。这些权限是按司法辖区给的，用英国运营商网络的英国用户，无论点开哪个浏览器图标，跑的都是 WebKit。

英国这边在单独推进。2025 年 10 月 22 日，CMA 认定苹果和谷歌在其移动平台上具有战略市场地位，覆盖操作系统、应用分发、浏览器和浏览器引擎，为期五年。认定是施加行为要求的权力，而不是要求本身。按平台今天的行为来做规划，把任何松动都当作额外收益。

硬件与设备 API，用核实代替假设

“Web 访问不了硬件”是我听得最多的反对意见，也是在具体场景里最常出错的那一条。

基本上到处都能用的能力

通过 getUserMedia 访问摄像头和麦克风在 MDN 上属于 Baseline，自 2017 年起就跨浏览器可用。地理定位、设备方向、包括移动端拍照在内的文件上传、剪贴板访问、移动端的 Web Share API，以及通过 WebAuthn 用面容 ID 或指纹作为认证器的通行密钥，在当前的移动浏览器里都能用。用摄像头视频流做条形码和二维码扫描也是家常便饭。

对绝大多数商业应用来说，这份清单就是全部的硬件需求。

只在 Chromium 上、移动端实际只在安卓上的能力

Web Bluetooth 被谷歌记录为在 ChromeOS、Chrome for Android 6.0、Chrome 56 起的 macOS 以及 Chrome 70 起的 Windows 10 上可用，没有列出 iOS 支持，MDN 也把它标为有限可用而非 Baseline。Web NFC 的范围更窄：谷歌记录为在安卓上随 Chrome 89 可用。

用于读写用户选定文件的 File System Access API 同样是 Chromium 的地盘，不过源私有文件系统在各浏览器上已经能覆盖应用内部存储的大部分需求。

应用商店分发是商业问题，不是技术问题

团队争论商店分发时，好像那是能力问题。它其实关乎四个商业变量，其中只有一个明确对商店有利。

发现是诚实的优势。消费者确实会按品牌和品类在 App Store 与 Play 上搜索，没有商店存在感的企业就放弃了那条渠道。对有辨识度名字的消费级产品，它极其重要；对一家公司里两百名员工使用的工具，它几乎无关紧要。

信任是真实存在的，并且因受众而不对称。年长和技术上不熟练的用户会把商店页面读作安全信号。年轻用户越来越不这样，同一个人会在同一部手机上心安理得地使用银行的网站。

与此相对，商店在你和用户之间加了一道审核队列、一份因规则变动而被拒的风险，以及你在应用内出售任何东西时的抽成。PWA 一样都没有。你决定什么时候发布，而关键修复会在用户下一次加载时抵达每个人，而不是等审核之后。

应用商店实际抽走多少

抽成数字变动得足够频繁，凭记忆报数并不明智。以下是厂商自己公布的条款，在 2026 年 9 月核对过。

苹果对数字商品和服务收取 30% 的标准佣金。App Store Small Business Program 把这一比例降到 15%，适用于上一自然年度收益不超过 1,000,000 美元的开发者，新开发者也符合条件，而一旦你在某一年内越过该门槛，之后的销售就恢复标准费率。

谷歌公布了分档的 Google Play 服务费：每年开发者收入的前 100 万美元为 15%，超出部分为 30%，自动续期订阅无论收入多少均为 15%。同一页面还列出了自 2026 年 6 月 30 日起在欧洲经济区、英国和美国生效的另一套结构，按安装是新增还是既有分别为 10% 或 20%，另加 5% 的账单处理费。

两家厂商都以美元公布。以 15% 通过商店销售一份每月 £9.99 的订阅，每位订阅者每年约合 £18，按 30% 则约合 £36。在断定商店是免费的之前，先乘上你的订阅人数。

你依然可以通过 Google Play 发布 PWA

安卓同时给你两个选项，这是平台比较中一处真实的不对称，而且很少被提到。

Trusted Web Activity 是一个安卓应用，它以全屏方式打开你自己的 PWA，不带浏览器界面，并通过 Digital Asset Links 验证它属于你。它需要安卓上的 Chrome 72 或更高版本，宿主应用无法访问网页内容的 Cookie 或存储。实际操作中它就是一层从你的清单生成的薄壳，像任何别的应用一样提交到 Play。

所以在安卓上，选择不是商店还是网页。你发布 PWA，把它包起来，用同一套代码库，花几天打包工作和一年的开发者账号费用，就同时拿到商店条目。

iOS 上没有对应物。苹果的审核指南长期认为，仅仅包装一个网站本身并不充分，所以走 iOS 商店这条路就意味着做真正原生的东西。比起任何 API 差距，正是这处不对称塑造了下面的成本表。

渐进式 Web 应用开发成本与两套原生代码库的对比

人们做的比较是建设成本，那是较小的一半。决定结果的比较是三年总成本，因为原生的开销是反复发生的。

请把这些读作中等复杂度商业应用的英国代理商价格带，而不是报价。这种形态的 PWA 通常是一支两到三名工程师的团队做三到五个月。两套原生代码库再加上网页存在感，就是三支团队、三条发布流程，以及每年三套平台升级。

第一行与第三行之间的差距，建设上大约 £75,000 到 £175,000，此后每年大约 £27,000 到 £60,000，就是你买原生时买到的东西。有时这笔钱花得很值。它应该是一个决定，而不是一个默认值。我们的网站开发与软件开发页面说明了我们如何为这两条路线做范围界定。

维护的钱究竟花到哪里去了

建设成本会被谈判。维护成本是被发现的，也正是多代码库项目安静而非响亮地失败的地方。

原生平台每年都强加工作给你。新的系统大版本弃用 API，签名与配置文件变更，最低 SDK 级别抬高，商店政策又添上隐私清单和数据安全声明之类的要求。这些都不交付任何功能。在两个平台上你要按别人定的日程付两遍。

然后是漂移。实现同一功能的两套代码库会分岔，而分岔会以只在一个平台上复现的支持工单形式浮现。每个产品决定都得做两遍再对齐，而这份协调成本不出现在任何一张发票上。

PWA 用浏览器的演进替掉了上面这一切，而浏览器演进是连续的、向后兼容的，几乎不会弄坏正在工作的代码。反复发生的工作是你自己的依赖更新、安全修补和托管，这与任何定制 Web 应用本来就需要的维护完全相同。

真正要紧的比较不是提案上的两个数字。它是一支团队对三支团队，年复一年，只要产品还活着。

PWA 的性能与 Core Web Vitals

已安装的应用会被拿去和原生比，所以性能门槛比网站更高而不是更低。好消息是这些指标是公开的，阈值是固定的。

Core Web Vitals 目前由三项指标组成，每一项都在页面加载的第 75 百分位上评估，并按移动端与桌面端分开。Largest Contentful Paint 在 2.5 秒及以内为良好，高于 4.0 秒为差。Interaction to Next Paint 在 2024 年稳定后取代了 First Input Delay，在 200 毫秒及以内为良好，高于 500 毫秒为差。Cumulative Layout Shift 在 0.1 及以内为良好，高于 0.25 为差。

PWA 在这里有一个结构性优势。Service Worker 从缓存提供外壳，会让重复访问接近瞬时，而这恰恰是已安装应用产生的模式，所以已安装 PWA 的真实用户数据，通常比同样的代码在浏览器里冷访问时更好看。

它也有一个结构性风险。单页框架把工作推给客户端，而 INP 正是惩罚这一点的指标。如果你已经在和这些数字较劲，我们关于通过 Core Web Vitals 的指南对诊断的展开比本文更深。

SEO 是没人计价的那项优势

这是我在多数商业场合会第一个摆出来的论点，而它几乎总是被整个漏掉。

PWA 就是网站。每个界面都有网址，每个网址都可以被抓取、被收录、被链接、被分享，每一个都能获得排名。原生应用一样都没有。应用商店条目只被浅层收录，在一座围墙花园里按完全不同的信号排名，而应用内部的内容对搜索不可见。

后果会复利。投在原生应用上的营销开支买来的是安装量，开支停下的那天它也停下。同样的开支投在 PWA 的内容与技术质量上，买来的是一个持续获得排名的页面。放到三年看，这个差额常常超过两条路线中任何一条的全部建设成本。

只有实现是可抓取的，它才会兑现，而这正是客户端渲染的应用出问题的地方：把一切都用 JavaScript 渲染、只有一个网址、没有服务端生成的 HTML，就等于完全放弃了这项优势。对需要被收录的路由做服务端渲染或预渲染是解法，而上线前的一次技术 SEO 审计，远比半年后才发现什么都没被收录便宜得多。

会一票否决的需求

把这个决定写成否决清单，比写成收益清单更容易，因为否决项是客观的。

如果下列任何一项是真实需求而不是愿望，你就需要原生。应用关闭时的后台位置追踪。主屏幕小组件、手表应用，或者 CarPlay 与 Android Auto 集成。iPhone 上的蓝牙或 NFC。HealthKit、应用内 Apple Pay，或任何苹果尚未向 Web 开放的深度系统集成。商店政策要求时的数字商品商店结算。持续的重计算，比如实时视频处理或以原生帧率做 3D 渲染。作为你的业务真正依赖的营销条件的 App Store 存在感。

如果上面一条都不适用，PWA 很可能就是正确答案，举证责任落在想要三套代码库的那一方。

还有两点考虑会进一步推动结论。如果你的用户主要在桌面或安卓上，iOS 上的空缺只影响你受众中的少数。而如果应用是你自己服务器的前端而不是设备的前端，这描述的正是大多数商业软件，那么设备能力几乎无关紧要。

场景一，一家设施承包商的现场服务

两百名工程师、工单、完工照片、签名采集，以及机房与地下室里时断时续的信号。这是人们以为需要原生的场景，也是 PWA 赢得最清楚的场景。

每一项需求都被覆盖。摄像头通过 getUserMedia 工作。签名是一个 canvas 元素。工单数据缓存在 IndexedDB 里，写入队列在重连时冲刷，因为 Background Sync 跨浏览器并不可靠，所以这部分手写。派工提醒以 Web 推送发出，在安卓上可用，在 iOS 上对已把应用添加到主屏幕的工程师可用，而安装是入职培训里五分钟的一项，不是用户获取问题。

没有商店发现的需求，因为用户就是员工。没有结算，所以抽成无关。设备是安卓与 iOS 混用，而这恰恰是最狠地惩罚两套原生代码库的情况。

用 £45,000 到 £70,000 建一个 PWA，而不是用 £120,000 到 £200,000 做两个原生应用，当天下午就能发布修复而不必等审核，再把差额花在真正决定这东西好不好用的派工后端上。

场景二，一家想要预约与提醒的美发连锁

十四家门店、面向消费者、预约排期、提醒、积分方案，付款在收银台而不是应用内完成。本能反应是做个原生应用，因为竞争对手有一个。

需求清单平平无奇：预约表单、日历、提醒、账户页。只有提醒有点意思，而在这个市场里短信和邮件比推送更合适，因为一年预约两次的顾客不会安装任何东西。

决定性因素是发现，而它压倒性地偏向 Web。人们通过搜索和地图找美发店，不是靠翻应用商店，所以介绍服务并接受预约的页面需要获得排名。原生应用在那里完全不可见。网站本身的成本才是真正的预算项，应用这一层是以可安装性的形式加在上面的。

把预约站点认真做好，让它可安装，好让常客把它留在主屏幕上，再为愿意开启的少数人加上 Web 推送。这里做原生要花 £80,000 以上，触达的顾客却比网站已经触达的更少。

场景三，一款订阅制健身产品

带教练的训练、视频内容、可穿戴设备集成、每月 £12.99、直接面向消费者、靠付费获客增长。这个场景的结论走向相反，值得展示原因。

商店发现在这里是有效的，因为健身是一个人们会浏览的品类，商店条目是一条真实的获客渠道。可穿戴集成意味着 HealthKit，Web 够不着。训练过程中的后台音频与屏幕常亮行为在原生上更好。大规模的离线视频下载在 Web 上可行，但并不舒服。

有意思的是结算。每月 £12.99 的商店抽成，按 15% 算每位订阅者每年约 £23，按 30% 算约 £47，在 20,000 名订阅者的规模上就是每年 £460,000 到 £940,000。这是一个有力的论据，支持在 Web 上收款、把应用当作客户端，好几家大型订阅产品现在正是这么做的。

答案是：产品本身用原生应用，注册、计费和内容营销用 PWA 或普通 Web 应用。两者都存在，而这种拆分是刻意的，不是偶然的。

如何在一个下午做出决定

这个决定不需要一个调研阶段。它需要四个写下来的答案。

第一，列出你真正需要的设备能力，然后逐条对照厂商自己的文档核实，而不是对照某份摘要。多数清单在这一步会急剧变短。第二，弄清你的用户从哪里来：如果答案是搜索，Web 已经占优；如果是在商店里闲逛，那就不占优。

第三，按三年而不是一年给三条路线都定价，把上面的维护数字算进去，也把你打算销售的东西的商店抽成算进去。第四，对自己的团队诚实一点。三名工程师维护一套代码库交付的东西，每一次都比三名工程师维护三套代码库更多。

如果这样之后答案仍然含糊，先做 PWA。它是更便宜的那个可逆选项。以后从 PWA 走向原生，意味着针对一套已经存在并被验证过的 API 去写原生客户端，反过来则意味着从头再来。这处不对称，比上面绝大多数功能对比都更值钱。

这把你带到哪里

渐进式 Web 应用开发不是给买不起原生的人的将就，也不是万能答案。它是一大类可界定产品的正确架构：商业软件、内部工具、预约与账户系统、内容产品，以及任何客户经由搜索而来的东西。

iOS 上的空缺是真实的、具体的，而且多半可以绕过而不是致命的。只要用户安装了，推送就能用。存储很充裕但会被清除。后台执行不存在，而它本来就属于你的服务器。蓝牙和 NFC 在 iPhone 上不工作，多少工程投入也改变不了这一点。

Mecanik 两条路线都做，并且会在答案是原生时直说。如果你想让这场比较跑在你真实的需求上而不是一份通用清单上，我们的网站开发与软件开发页面描述了我们如何做范围界定，而我们关于在 2026 年构建 Web 应用的指南，讲的是随后而来的技术栈决策。

常见问题

什么是渐进式 Web 应用？ 渐进式 Web 应用是用 Web 技术构建、行为上像平台专属应用的应用。技术上它是一个通过 HTTPS 提供的 Web 应用，配有描述名称、图标和启动行为的 Web 应用清单，以及一个能用缓存回应请求并接收推送消息的 Service Worker。MDN 把它定义为从一套代码库运行在多个平台上、同时保持可安装并能够离线运行的软件。

PWA 能在 iPhone 上发送推送通知吗？ 能，但有一个条件。苹果在 iOS 与 iPadOS 16.4 中加入了 Web Push，但 WebKit 要求该 Web 应用必须先被添加到主屏幕，并且授权必须响应直接的用户交互来请求，比如点击一个订阅按钮。对运行在 Safari 标签页里的站点，推送不工作。iOS 与 iPadOS 18.4 中加入的声明式 Web 推送简化了实现，但保留了同样的主屏幕条件。

在英国做渐进式 Web 应用开发要花多少钱？ 对于中等复杂度的商业应用，建设单一 PWA 代码库预计 £35,000 到 £75,000，每年维护 £8,000 到 £20,000。与之相当的原生路线，即分别做 iOS 与安卓应用再加一个营销站点，建设为 £110,000 到 £250,000，此后每年 £35,000 到 £80,000。这些是英国代理商的价格带而不是报价，而反复发生的差额通常比建设差额更要紧。

可以把 PWA 放进 App Store 或 Google Play 吗？ Google Play 可以，App Store 不行。在安卓上，Trusted Web Activity 用一层薄薄的原生外壳包住你的 PWA，并通过 Digital Asset Links 验证，于是同一套代码库只需几天打包工作就能拿到 Play 条目。苹果没有对应物，其审核指南认为仅仅包装一个网站并不充分，所以 App Store 存在感意味着做真正原生的东西。

什么时候应该选原生应用而不是 PWA？ 当你需要应用关闭时的后台定位、主屏幕小组件、手表或车机集成、iPhone 上的蓝牙或 NFC、HealthKit 或应用内 Apple Pay、实时视频处理这类持续的重计算，或者把 App Store 存在感当作一条真实获客渠道时，就选原生。如果这些都不适用，PWA 很可能是正确的，举证责任落在想维护三套代码库的那一方。