原副标题：倍受贾伯斯尊崇的 PWA，为何还没杀掉原生植物应用领域？
译者丨Kevin Basset
翻译者丨若非山
策画丨褚杏娟
PWA （Progressive Web App）的设想不是由 Google 或 Apple 提出的，而是 Steve Jobs 在 2007 年 iPhone 面世期间首度将这一基本概念展现在了世界眼前。当时，内部插件或许能协助提高该电子设备的畅销程度，Jobs 希望开发人员采用国际标准 Web 技术来构筑插件。
你能撰写绝妙的 Web 2.0 和 Ajax 插件，它的外形和犯罪行为与 iPhone 上的插件十分相似，而且这些插件能与 iPhone 服务项目轻松软件系统。你猜嘛?
你不须要任何 SDK！假如你知道如何采用最当代的 web 国际标准来为今天的 iPhone 撰写绝妙的插件，所以你就保有了所需的一切。
所以，开发人员们，我们为你们准备了两个非常清纯的故事情节。现在你就能开始构筑你的 iPhone 插件了。
——Steve Jobs，Apple。
理论上，PWA 是原生植物应用领域的轻松代替品——只须要管理两个标识符库、即刻预览、无须审查，无须为应用领域内买回缴付手续费。还有甚么理据不讨厌它呢？
但事实上，尽管自问世以来早已走了极短一段距离， PWA 还没达到能轻松代替原生植物应用领域的境地。所以，到了 2022 年，它还缺些甚么？为何它还没成为 App 的预设格式？
PWA 的身分辨识问题
关于这个热门话题，我早已写过很多，但 PWA 依然被指出是三流 App——或者更为严重，在这类情况下，甚至显然就不被指出是 App。
2022 年，人们依然必选在Google或苹果公司的应用领域零售店上找寻 App。有意思的是，直接从中文网站上加装 App 既快又方便快捷，但假如没专门针对的提示信息和推展原素，使用者会不生活习惯。
这个问题的核心是信任问题。从第三方下载 App 意味着第三方（Google或苹果公司）早已证明 App 是能安全下载的。
但问题是 PWA 不须要Google和苹果公司的审查，因为它的安全性从一开始就设计好了。PWA 不能读取手机联系人信息，不能代表你发送短信，也不能访问任何可能暴露私人信息的手机功能。
“应用领域零售店”的价值主张有两个方面——分发（将 App 加装到使用者的电子设备上）和推展（让更多人发现你的 App）。对于 PWA 来说，应用领域零售店在推展方面不再发挥很大的作用，而 PWA 的加装逻辑嵌入到了浏览器当中。
2022 年，应用领域零售店的模式是多余的。
iOS 推送通知
macOS Ventura 的 Safari 16 将带来 Web 推送功能。即使 Safari 被关闭，也会发送通知。它采用了与其他浏览器相同的 Web 技术，不须要苹果公司开发人员计划会员资格。它将于明年登陆 iOS 和 iPadOS 平台。
——苹果公司 Web 开发人员体验布道师 Jen Simmons
经过多年看似无望的等待，苹果公司终于宣布 Web 推送通知将于 2023 年登陆 iOS。这是个好消息。到目前为止，你能向 Android/Windows/macOS 使用者发送通知，但不能向 iOS 使用者发送。
对于许多开发人员来说，这意味着他们不可能完全依靠推送通知向使用者传递重要信息。Web 推送通知是两个很好的额外奖励，但不是产品工作流程的关键部分。
假如苹果公司能够正确（如遵循 W3 规范）地实现 Web 推送通知，这种情况将会改变。你将能够毫不费力地通知 Android 和 iOS 使用者，而且不须要将你的 App 上架到Google或苹果公司的应用领域零售店。
尽管如此，因为 Web 开发人员滥用 Web Push API（例如，新闻中文网站在你第一次访问中文网站时就请求获取通知权限），以至于人们越来越讨厌这些东西。因此，在这类情况下，Chrome（和其他浏览器）会自动阻止推送通知请求——这导致希望合法采用通知功能的开发人员更难请求访问该功能。
在我的个人愿望清单中，我希望 PWA 在加装后保有比普通中文网站更高的权限（但不像原生植物应用领域那样多）。人们加装你的 PWA 说明他们信任它——他们不是偶然才发现你的中文网站的。
以下是一些赋予较高权限的例子。
已加装的 PWA 能被自动授予对 Push API 的访问权限。 只对已加装的 PWA 开发 Push API 访问权限，一般的中文网站不能请求访问该权限。 将权限请求绑定到多个浏览器 API。例如，在加装好以后，PWA 能请求获得对 Push API、Geolocation API 或 Microphone API 的自动访问权限——使用者能通过切换来分别允许或禁止它。 或者更简单一点，在 PWA 请求权限时，不让 Chrome 自动阻止推送通知。iOS 上的加装提示信息
在 iOS 上加装 PWA 须要向使用者显示自定义指令
目前在 iOS 上加装 PWA 须要打开共享面板，然后点击“添加到主屏幕”按钮，这样基本上就能了，但依然不像加装原生植物 iOS 应用领域所以简单。
假如 Safari 支持 beforeInstallPrompt 事件，所以加装体验将会得到简化，或者苹果公司至少能改变“添加到主屏幕以加装插件”的措辞——安卓几年前就早已这么做了。
虽然目前的加装方式是两个不错的变通方案，但它确实有一些意想不到的、对使用者和开发人员体验都是有害的后果。
例如，开发人员无法区分实际的 Safari（有“添加到主屏幕”按钮）和 SFSafariViewController View（没这个按钮）。须要注意的是，许多应用领域内浏览器采用了 SFSafariViewController，如 Twitter 的 iOS 应用领域。
结果，开发人员别无选择，只能显示自定义指令。对于那些可能不了解这些技术背后的细节的使用者（也就是 99.99% 的使用者）来说，这有点令人困惑。
另外，我也期待着有一天，PWA 开发人员不再因为须要支持所有的 iPhone 和 iPad 而必须生成 25 个以上单独的启动画面文件。
更好的加装后 Manifest 预览
假如开发人员能够在加装 App 后预览 Manifest 的关键细节（图标、名称、启动画面等），所以 PWA 也会变得更具竞争力。
Google为此发布了一篇文章，但我想告诉你的是，你想要预览的属性事实上都不能被修改。因此，一旦加装了，你就无法预览 App 在使用者主屏幕上显示的样子。
至少直到最近都是这样。
幸运的是，在这方面早已有了一些有意思的进展。现在，桌面 Chrome 浏览器支持在加装后修改 App 的名称。它甚至还提供了两个漂亮的反网络钓鱼提示信息，使用者能选择批准变更或卸载 App。
使用者能选择“OK”，也能选择卸载
更好的域名管理
假如说 PWA 有甚么真正的亮点，那就是能程序化地创建 App。
我的两个客户是一家为摄影师开发商业化软件的公司。摄影师采用他们的软件为客户创建独特的婚礼相册。
每两个相册都是两个独特的 App，有自己的名字（新婚夫妇的名字）和图标（新婚夫妇的照片）。这样的画册有一万多个，所以不可能通过任何其他方式来管理它。
不过，它也不是没任何瓶颈或问题。
虽然用不同的子域名（例如 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 上，打开第三方 App 中的链接将打开已加装的 PWA。然而，在 iOS 上，它却打开了 Safari 浏览器。
桌面截图
旧的加装提示信息（左和中）与新的加装提示信息（右）
更丰富的加装界面无疑有助于弥合原生植物应用领域和 PWA 之间的差距。开发人员能将截图包含在加装提示信息中，更好地展现他们的 App——看起来像是国际标准的应用领域零售店界面。
在 Progressier，我更进一步，除了将工具软件系统到产品中之外，还提供了两个免费的工具来设计这些截图。因此，假如你是 Progressier 的客户，能在两个界面中设计、管理、编辑、本地化和上传截图，这有点像 Photoshop 遇见了 Google Play。
桌面 App 的 Manifest 中的 screenshots 属性目前没任何作用，不过早已有两个提案建议也在桌面 Chrome 上显示这些截图。你现在能用 –enable-features=DesktopPWAsDetailedInstallDialog 命令行标志来测试它。
原生植物特性
应该让 PWA 访问联系人、查看日历、发送 SMS/MMS、设置警报吗？我个人指出永远不应该。
PWA 之所以安全，是因为它的作用域受到了限制。绕过浏览器限制将会成为危险的先例，催生了对第三方审批者（如应用领域零售店）的需求，从而让整个基本概念无效。
当然，有些 App 确实须要访问原生植物特性。对于这些 App 来说，原生植物永远被希望是唯一的选择。
但是对于绝大多数不须要采用这些功能的 App 来说，PWA 不仅是很好的选择，它还正逐渐成为最好的选择。
当你看着越来越多的 App 是基于 Bubble、Softr 和其他无标识符平台开发出来的，你会发现这便是我们的前进方向。
我个人指出这对开发人员、使用者和整个 Web 生态系统来说都是好事。
译者介绍：
Kevin Basset，Progressier 的创始人。Progressier 是两个软件工具包，超过 5000 多款 App 用它摆脱了应用领域零售店的束缚。
原文链接：
https://kevinbasset.medium.com/why-havent-pwas-killed-native-apps-yet-29beca4425fa
那位用 Rust 重写数据库的创始人来复盘了：删除 27 万行 C++ 标识符，值吗？
Google翻译中国站点疑似关闭；字节跳动升级员工关怀计划：新增每年 10 天家庭关爱假；Istio 正式成为 CNCF 孵化项目｜Q 资讯
“产品杀手”Google关闭 Stadia，网友：负责人是把 Stadia 当职业跳板了吗？
“羊了个羊”背后的游戏引擎 Cocos：这绝不是团队最高光的时刻 返
