聚热点 juredian

为什么 PWA 还没有“干掉”原生应用?

摘要:PWA 即渐进式网页应用

,是 Web 应用的一种,具有安全、渐进式、响应式、无需网络、类应用程序、保持最新、可检测、可重新接入、可安装、可分享这 10 个要

素,但 PWA 至今仍没有成为应用的默认格式。

原文链接

:https://kevinbasset.medium.com/why-havent-pwas-killed-native-apps-yet-29beca4425fa

声明:本文为 CSDN 翻译,未经授权,禁止转载。

作者 | Kevin Basset

译者 | 弯月

出品 | CSDN(ID:CSDNnews)

从理论上讲,PWA 是原生应用的完美替代:只需管理一个代码库,即时更新无需审核,而且应用内的购买也不会被抽成。何乐而不为?

尽管PWA(Progressive Web App,渐进式Web应用)经历了漫长的发展,但时至今日仍然无法完全取代原生应用。

那么,到了2022年,PWA还缺什么?为什么它们还没有成为应用的默认格式?

人们对PWA的看法

很多人认为PWA只不过是二流的应用,还有人甚至认为PWA根本算不上应用。

现如今,我们习惯于通过苹果或Google的应用商店寻找应用。然而实际上,直接通过网站安装应用既快捷又方便。但是,如果没有专门的提示和推广元素,用户仍然不习惯这种方式。

问题的关键在于信任。通过第三方下载应用的前提是,第三方能够证明应用可以安全下载。

然而,PWA并不需要苹果和Google的批准,因为它们本身就是安全的。PWA 无法读取手机上的联系人、代表主人发送SMS消息,或访问任何可能暴露私人信息的功能。

应用商店有着双重的价值主张:分发(在用户设备上安装应用)和宣传(让更多人发现你的应用)。很多人认为,应用商店的宣传工作并不理想。而PWA的安装可以嵌入到浏览器内。

如今看来,整个应用商店范式都是多余的。

iOS 推送通知

在万众翘首以待多年之后,苹果终于宣布iOS将于2023年推出推送通知的功能。这是一个好消息。截止到目前为止,你只能向Android/Windows/macOS 用户发送通知,但不能向 iOS 用户发送通知。

对于许多开发人员来说,这意味着无法依赖推送通知向用户传递重要的信息。尽管Web推送通知是一个很好的额外功能,但它并不是产品工作流程的关键部分。

如果苹果以正确的方式(即遵循W3规范)实现Web推送通知,那么这种情况即将发生变化。你可以轻松地通知 Android 和 iOS 上的用户,而无需通过苹果或Google的应用商店发布你的应用。

话虽如此,Web 开发人员滥用Web推送API的现象很多(例如,新闻网站会在用户第一次访问时请求推送通知的授权),以至于人们越来越讨厌这类提示。结果导致,在某些情况下,Chrome(以及其他浏览器)会自动阻止推送通知请求,这也导致合理使用的开发人员也很难获得该功能的使用授权。

我个人最大的心愿之一便是 PWA 在安装后能被授予比普通网站更高的权限(但没有原生应用多)。人们安装你的PWA证明他们信任你的应用,而不只是在偶然的一次机会下发现了你的网站。

下面是一些需要更高权限的例子:

已安装的 PWA 可以自动被授予访问Push API的权限。

严格限制只有已安装的PWA可以访问Push API。不允许任何常规网站访问Push API。杜绝垃圾邮件。

将多个浏览器API的访问权限打包,显示在安装提示中。例如,在安装后,PWA 可以自动获得Push API、Geolocation API 或 Microphone API等的访问权,用户可以通过一个按钮来切换是允许还是禁止每个API的访问。

当PWA请求访问权限时,Chrome不应该简单地阻止推送通知。

iOS上的原生安装提示

目前,在iOS上安装PWA应用需要打开共享面板,并单击按钮“添加到主屏幕”。虽然安装本身没什么问题,但不如安装原生 iOS 应用那么直观。

如果Safari支持beforeInstallPrompt事件,那么整个体验就可以进一步精简。或者至少,苹果可以将按钮的文本修改成“添加到主屏幕以安装应用”,Android在几年前就做了改动。

尽管当前的安装流程也不错,但还是会产生一些影响用户和开发者体验的问题。

例如,真实的 Safari(包含按钮“添加到主屏幕”)和 SFSafariViewController 视图(没有这个按钮)之间没有任何区别。现在的状况是,许多应用内浏览器都使用了后者,例如推特 iOS 应用。

因此,你别无选择,只能显示自定义的说明,即便有时连自定义说明都无法显示。绝大多数的用户都对背后的技术没兴趣,因此他们会觉得有点困惑。

同样,我希望有一天,PWA开发人员不再需要生成 25 多个单独的初始屏幕图像文件来支持每部 iPhone 和 iPad。

安装完毕后更新清单文件

为了提高PWA应用的竞争力,我们应该允许开发人员能够在安装后更新清单文件(图标、名称、启动屏幕等)。

关于这个话题,Google曾出过一篇文章(https://web.dev/manifest-updates/),一句话总结:你想要修改的属性统统无法修改。因此,一旦安装完毕,你就无法更新用户主屏幕上的显示效果。

至少,直到最近都是如此。

幸运的是,该领域出现了一些有趣的发展。如今,桌面版Chrome 支持在安装后更改应用的名称。它甚至还会显示一个反网络钓鱼提示(虽然有点迷惑),以方便用户选择允许修改清单文件或卸载应用。

范围管理

PWA真正的亮点在于,创建程序化的应用。

我有一位客户做了一款商业化的摄影师软件。摄影师可以利用该软件为自己的客户创建独特的婚礼相册。

每个相册一个单独的应用,有自己的名字(新婚夫妇的名字)和图标(这对夫妇的照片)。这样的相册应用数量高达1万多个,任何其他方式根本无法管理。

然而,该软件也有一些瓶颈和缺陷。

虽然我们希望将每个PWA托管到自己的子域上(例如 pwa1.example.com 和 pwa2.example.com),但这通常是不可能的。在这个例子中,退而求其次的解决方案是将每个PWA托管到自己的目录中(例如 example.com/pwa1/ 和 example.com/pwa2/)。

由于末尾斜杠的问题,范围的管理有时是非常违反直觉的。简而言之,example.com/pwa1/ 是一个有效的范围,而example.com/pwa1(请注意末尾少一个斜杠)则不是。

如果你使用后者,则浏览器会认为范围是example.com/(根域),而且关键在于浏览器不会显示错误消息或警告。

我希望浏览器能更加智能一点,自动处理scope字段中的斜杠,即将 example.com/pwa1 自动更正为 example.com/pwa1/。根据我的经验,如果开发人员实际的意图是采用后者,那么使用前者(没有末尾斜杠)的访问就一定会导致错误。

iOS上的范围也应该改进。打开某个来自Android第三方应用PWA范围内的链接,就会安装该PWA。但是,在 iOS 上,它会打开 Safari。

桌面截图

毫无疑问,更丰富的安装 UI 有助于弥补原生应用与 PWA 之间的差距。为了展示应用,开发人员可以在安装提示中显示一个截图,这样从外观和感觉上就像一个标准的应用商店界面。

我们的应用除了将工具集成到产品本身之外,还提供了一个免费的设计这些屏幕截图的工具。因此,客户可以通过一个界面设计、管理、编辑、本地化和上传屏幕截图。

目前在桌面版中,应用清单的 screenshots 属性没有任何作用,但有一个提议是在桌面版的Chrome上显示这些屏幕截图。你可以通过--enable-features=DesktopPWAsDetailedInstallDialog进行测试。

原生功能

PWA是否应该访问你的联系人?查看你的日历?发送短信/彩信?设置闹钟?我个人的看法是:无论到什么时候都不应该!

PWA的范围很有限,这恰恰证明了它们很安全。绕过浏览器的限制会增添一些危险,结果必然是通过第三方(即应用商店)来审核应用,这是人为创造的需求,根本没有必要。

当然,有些应用确实需要访问这些功能。那么,对于这些人来说,也许原生是唯一的出路。

但是,对于绝大多数不需要访问这些功能的应用程序来说,PWA 不仅可以成为一个很好的选择,而且有可能成为最佳选择。

我们努力的方向是利用 Bubble、Softr 和其他无代码平台构建更多应用。在我看来,这对开发人员、用户和整个网络世界来说,都是一个好消息。

搜索建议: