为什么一个修复得更快
一个商店应用的更新，要经过编写、提交、审核、发布，然后由每个人各自安装。一个网页应用的更新，在页面加载时就完成了。这中间的差距，是几天对几秒，而它决定了一个漏洞会在你的设备上存活多久。
这是这两者之间被讨论得最少的一个差异，但放在一年的使用周期里看，很可能是影响最大的一个。
商店这条路径有5个步骤
构建、提交、审核、发布、安装。光是审核就要几个小时到几天，而安装与否还取决于用户是否开启了自动更新。一个修复可能周一就完成了，但要到周五才能触达一半的用户。
网页这条路径只有一个步骤
部署，然后下一次加载页面时，改动就已经生效了。不需要提交任何东西，也没有人审批。这就是为什么网页产品能持续不断地发布小修复，而商店产品要把它们打包成一次次发布。
打包发布改变了风险
当发布的成本很高时，改动就会累积成大版本发布，而大版本发布出问题的地方也更多。当发布的成本很低时，每次改动都很小，一个失误只会影响一件事。发布的节奏，跟着发布的成本走。
这对你意味着什么
在网页上，你用的始终是当前版本，包括一小时前刚引入的漏洞。在商店里，你用的是某人批准过的版本，包括三周前留下的漏洞。两者都算不上绝对更好，但网页版本会更快得到修复。
关于这款应用的常见问题
我能停留在旧版本的网页上吗？
不能，这就是这套模式的代价。没有版本可以锁定，所以一个你不喜欢的改动，无论你想不想要，它都会到来。
商店应用能更快获得紧急修复吗？
加急审核确实存在，需要几个小时而不是几分钟。它是留给严重问题的。
哪种模式的漏洞更少？
两者都不能说更可靠。网页上的小漏洞更多，但存在的时间更短；商店里的漏洞更少，但存在的时间更长。
刷新一下页面，你用的就已经是最新版本了。
先打开聊天