PWA 出海网备受史蒂夫・乔布斯赞誉的渐进式网页应用（PWA），理应在应用领域引发巨大震动，但时至今日，PWA 为何没有颠覆原生应用呢？
有人声称，PWA 的理念并非由谷歌或苹果提出，早在 2007 年 iPhone 推出之时，乔布斯就首度向世界展示了这一观念。那时，外部应用程序似乎有望提升该设备的受欢迎程度，乔布斯期望开发者借助标准网络技术构建应用程序。
“你能够编写令人惊叹的 Web 2.0 和 Ajax 应用程序，其外观和行为与 iPhone 上的应用程序毫无差别，并且这些应用程序能够与 iPhone 服务完美融合。你猜怎么样？你无需任何 SDK！倘若你知道如何运用最现代的网络标准为现今的 iPhone 编写出色的应用程序，那么你便拥有了所需的一切。开发者们，我们为你们准备了一个极为诱人的机遇。现在你们就可以着手构建自己的 iPhone 应用程序了。”—— 乔布斯。
理论上，PWA 堪称原生应用的绝佳替代者 —— 只需管理一个代码库，即可实现即时更新，无需经过审核，也无需为应用内购买支付佣金。如此看来，似乎没有理由不喜爱它们。但实际情况是，尽管 PWA 自诞生以来已经取得了显著进步，却仍未达到能够完美替代原生应用的水平。那么它们究竟还缺少什么呢？为何它们尚未成为应用程序的默认形式呢？
PWA 的身份识别困境
关于这个话题，已有不少人谈及，但 PWA 依旧被视作次等应用 —— 在某些情况下，甚至根本不被当作应用程序看待。
如今人们依然倾向于在谷歌或苹果的应用商店中寻觅应用程序。有趣的是，直接从网站安装应用程序既迅速又便捷，然而若没有专门的提示和推广要素，用户往往难以习惯这种方式。
问题的关键在于信任问题。从第三方下载应用程序意味着谷歌或苹果已经证实该应用程序是安全可下载的。但问题在于，PWA 无需谷歌和苹果的审核，因为其安全性从一开始就经过精心设计。PWA 无法读取手机联系人信息，不能代表用户发送短信，也不能访问任何可能泄露私人信息的手机功能。
“应用商店” 的价值主张体现在两个方面 —— 分发（将应用程序安装到用户设备上）和推广（让更多人发现你的应用程序）。对于 PWA 而言，应用商店在推广方面的作用已不再突出，而 PWA 的安装逻辑已嵌入到浏览器当中。在 2022 年，应用商店的模式显得有些多余。
iOS 推送通知难题
“macOS Ventura 的 Safari 16 将引入 Web 推送功能。即使 Safari 被关闭，也能发送通知。它采用了与其他浏览器相同的网络技术，无需苹果开发者计划会员资格。该功能将于明年登陆 iOS 和 iPadOS 平台。”—— 苹果 Web 开发者体验布道师珍・西蒙斯。
经过多年看似毫无希望的等待，苹果终于宣布 Web 推送通知将于 2023 年在 iOS 上线。这无疑是个好消息。在此之前，你可以向 Android/Windows/macOS 用户发送通知，但无法向 iOS 用户发送。
对于许多开发者来说，这意味着他们无法完全依赖推送通知向用户传递重要信息。Web 推送通知虽然是一个不错的额外福利，但并非产品工作流程的关键部分。
倘若苹果能够正确（遵循 W3 规范）实现 Web 推送通知，这种情况将会发生改变。届时，你将能够轻松地向 Android 和 iOS 用户发送通知，且无需将应用程序上架到谷歌或苹果的应用商店。
尽管如此，由于 Web 开发者滥用 Web Push API（例如，新闻网站在用户首次访问时就请求获取通知权限），导致人们对这些通知越来越厌烦。因此，在某些情况下，Chrome（以及其他浏览器）会自动阻止推送通知请求 —— 这使得那些希望合法使用通知功能的开发者更难获得该功能的访问权限。
有人期望 PWA 在安装后能够拥有比普通网站更高的权限（但不像原生应用那么多）。人们安装 PWA 表明他们信任它 —— 他们并非偶然间发现你的网站。
以下是一些赋予较高权限的例子：已安装的 PWA 可以自动获得对 Push API 的访问权限；只对已安装的 PWA 开放 Push API 访问权限，普通网站不能请求该权限；将权限请求与多个浏览器 API 绑定。例如，安装后，PWA 可以请求自动获得对 Push API、Geolocation API 或 Microphone API 的访问权限 —— 用户可以通过切换开关分别允许或禁止它们。或者更简单一点，在 PWA 请求权限时，不让 Chrome 自动阻止推送通知。
iOS 上安装 PWA 的不便之处
目前在 iOS 上安装 PWA 需要打开共享面板，然后点击 “添加到主屏幕” 按钮，这样基本就能完成安装，但仍不像安装原生 iOS 应用那样简便。
如果 Safari 支持 beforeInstallPrompt 事件，那么安装体验将会得到简化，或者苹果至少可以更改 “添加到主屏幕以安装应用程序” 的措辞 —— 安卓在几年前就已经这样做了。
虽然目前的安装方式是一个不错的临时办法，但它确实存在一些意想不到的后果，对用户和开发者的体验都有不良影响。
例如，开发者无法区分实际的 Safari（有 “添加到主屏幕” 按钮）和 SFSafariViewController View（没有这个按钮）。需要注意的是，许多应用内浏览器，如 Twitter 的 iOS 应用，都使用了 SFSafariViewController。
也有人期待有一天，PWA 开发者不再因为需要支持所有的 iPhone 和 iPad 而必须生成 25 个以上单独的启动画面文件。
更好的安装后 Manifest 更新
如果开发者能够在安装应用程序后更新 Manifest 的关键细节（图标、名称、启动画面等），那么 PWA 将更具竞争力。
谷歌为此发布了一篇文章，但实际上，你想要更新的属性大多无法被修改，因此一旦安装完成，你就无法更新应用程序在用户主屏幕上的显示效果。
至少在最近一段时间都是如此。
幸运的是，在这方面已经有了一些有趣的进展。现在，桌面 Chrome 浏览器支持在安装后修改应用程序的名称。它甚至还提供了一个漂亮的反网络钓鱼提示，用户可以选择批准变更或卸载应用程序。
更好的域名管理
如果说 PWA 有什么真正的亮点，那就是可以通过编程方式创建应用程序。不过，它也并非没有瓶颈或问题。
虽然使用不同的子域名（例如 pwa1.example.com 和 pwa2.example.com）来托管每个 PWA 是个不错的想法，但这通常是不可行的。因此，最好的方法是将它们分别托管在自己的目录中（例如 example.com/pwa1/ 和 example.com/pwa2/）。
管理作用域非常不直观，有人将这个问题称为尾部斜杠问题。简单来说，example.com/pwa1/ 是一个有效的域名，而 example.com/pwa1（注意后面缺少斜杠）不是。
如果使用了后者，浏览器会认为是 example.com/（根域名）—— 问题是它不会出现错误消息或警告，只是悄然失败。
有人希望浏览器能够更加聪明，能够自动处理域名中的尾部斜杠，例如将 example.com/pwa1 自动更正为 example.com/pwa1/。
iOS 上的域名处理也应该得到改进。在 Android 上，打开第三方应用程序中的链接将打开已安装的 PWA。然而，在 iOS 上，它却会打开 Safari 浏览器。
原生特性的思考
有人认为 PWA 不应该访问联系人、查看日历、发送 SMS/MMS、设置警报等。
PWA 之所以安全，是因为它们的作用域受到了限制。绕过浏览器限制将会成为危险的先例，催生对第三方审批者（如应用商店）的需求，从而使整个概念失去意义。
当然有些应用程序确实需要访问原生特性，对于这些应用程序来说，原生永远是唯一的选择。
但对于绝大多数不需要使用这些功能的应用程序来说，PWA 不仅是一个很好的选择，而且正逐渐成为最佳选择。
当看到越来越多的应用程序是基于 Bubble、Softr 和其他无代码平台开发出来的，会发现这就是我们的发展方向。这对开发者、用户和整个网络生态系统来说也是好事。
以上就是关于PWA 为何没有颠覆原生应用内容了，尽管 PWA 目前在某些方面还存在不足，但它的发展潜力不可小觑，相信 PWA 在未来会逐渐克服现有的问题。也许在不久的将来，PWA 能够真正实现与原生应用相媲美，甚至超越原生应用，为开发者和用户带来更加便捷、高效的应用体验。
未经允许不得转载：PWA 出海网 » PWA 为何没有颠覆原生应用？
