原文链接：nielsleenheer.com/articles/20…
在的苹果手机的应用商店，有很多浏览器可供选择。在最新的 iOS 系统甚至可以把这些浏览器设置为默认浏览器。那么为什么一些人抱怨iOS 上的浏览器选择呢？
你可能没有意识到 iOS 上的所有浏览器都需要使用与 Safari 相同的渲染引擎。在其他平台上，情况并非如此。
在安卓系统、视窗系统甚至 macOS 上，他们都在使用 Chromium 渲染引擎。但在 iOS，它使用的是 WebKit。或者看看火狐，它在所有平台上都使用 Gecko 渲染引擎。除了 iOS，它使用 WebKit。
###为什么每个人都使用 WebKit？
并不是因为这些渲染引擎不能在 iOS 上运行。把渲染引擎移植到 iOS 可能需要一些工作，但是据我所知，一些浏览器希望投入这项工作，但是很遗憾他们不被允许这么做。
事实上，App Store 中的应用需要经过苹果的审核和批准，满足应用商店审查指南:
2.5.6 浏览网页的应用程序必须使用适当的 WebKit 框架和 WebKit Javascript 引擎。
这是最后的决定。苹果要求浏览器使用 WebKit。事实上, 应用必须使用系统提供的 WebKit 框架。即使 WebKit 是开源的，也不能在应用程序中使用修改或者改进的任一版本。决不允许
@mtomweb创建的说明图片
伟大的均衡器：系统WebView
但是你如何使用授权版本的 WebKit呢？有一个框架可以解决这个问题。苹果提供了一个WebView，允许在你的应用程序中做少量工作就可以嵌入WebKit。需要为框架提供一个配置对象，并处理它发送的一些事件。 WebKit 处理所有实际的加载、解析和渲染。你的应用根本不需要关系任何细节。你需要做的仅仅是提供一个友好的用户界面，也许还要与你的生态系统集成。例如：与桌面版本的浏览器共享书签。
这正是其他浏览器厂商为这个烂摊子烦恼的首要原因。他们不关心在iOS上完成一个伟大的浏览器，而是更关心让他们现有的用户在iOS上进入他们当前的生态系统。
你在Windows上使用Edge吗？没问题，你可以在iOS上下载Edge，你所有的密码、书签和标签都在那里。生态系统集成，完美！
虽然这听起来很棒，但它也将浏览器简化为不同的用户界面。
为什么这很重要？
浏览器最重要的是渲染引擎。用户界面需要在浏览器里才能展示，但浏览器不能从中碍事。
即使苹果也认为用户界面渲染应该尽可能的快。苹果在 iOS 15 测试版中对 Safari 进行的早期实验并符合这个理念，导致一些苹果专家例如Marco Arment, Frederico Viticci 和 John Gruber 提出了一些非常直言不讳的批评。尽管如此，苹果是对的，因为用户想浏览网页，只能使用浏览器。
而这正是 iOS 上其他浏览器无法创新的地方，他们必须使用与平台上其他浏览器相同的渲染引擎。
所以如果你想使用新的 WEB 标准？需要等到苹果在WebKit中实现它。如果有 bug 引发了问题？等到苹果修复它并发布新版本的iOS。
这就是问题所在。
标准支持和推动 WEB 平台发展
即使我创建了一个HTML5test网站，我也不会拿出分数来说明Safari比其他浏览器得分更低。但愿如此，因为事实不是这样。这个网站已经 5 年没有更新了，Safari 支持几乎所有5年前的 WEB 标准。
问题要复杂得多。苹果对 WEB 的看法和其他浏览器存在根本区别。
很容易回想到类似的之前谷歌不认真对待隐私的问题，因为他们也是一家广告公司。 苹果只卖硬件。 不，不是这样。
这同样适用于苹果希望从 App Store 中获得约 30% 至 15% 的收入，让 WEB 变得更糟，迫使用户改用APP，并从中获得利益。 我一点也不相信。
Safari 和 Chrome 团队都希望让 WEB 更安全，并努力改进 WEB 但是他们对 WEB 应该是什么样的是有不同的看法的。
谷歌专注于通过 提高 WEB 的能力来改善 WEB 扩展 WEB 的能力，超越今天的可能性。 这也意味着允许它与本地应用程序竞争，安卓团队肯定并不总是同意这一点。
Safari 似乎专注于 改进 WEB让它更安全、更快、更漂亮。如果你想要更多，你可以使用一个应用程序。
我并不是说苹果的做法是错误的。苹果正在做的事情也很重要，我赞扬苹果在改善 WEB 隐私方面所做的工作。
但这不可能是唯一的优先事项。想象一下，如果20年前每个浏览器都采取这种方法，WEB 会是什么样子。
事实上，不要想象这一切。回想一下Internet Explorer 6；这就是20年前的 WEB 。我不是说 Internet Explorer 6 是一个糟糕的浏览器。它在2001年是一个伟大的浏览器。但是就像Internet Explorer 6 一样，如果你停止创新，你就落后了。这导致了Internet Explorer的衰落。其他浏览器确实通过创新变得更好，而Internet Explorer变得无关紧要。尽管微软多年来一直试图赶上甚至后面尝试使用Edge来追赶，最终还是失败了，Edge现在使用 Chromium 作为渲染引擎
在过去的20年里，我们花了大量的努力和创新才变成今天的样子：新的应用编程接口、新的标准、新的功能。具有讽刺意味的是，一个更强大的 WEB 的推动最初来自Safari和WebKit渲染引擎。WebKit 是新贵，它改变了一切，并为 WEB 增加了许多有用的新功能。
但时代变了。Safari 已经落后很难跟上 WEB 平台的发展方向。我不是在说一些只有Chromium才实现的奇异功能。即使是其他浏览器中适当的标准和广泛支持的功能也可能需要数年才能在Safari中出现。
Web 开发人员的口头禅是“Safari 是新的 IE”。可悲的是，它已经有一段时间了。
不幸的是，与 Internet Explorer 不同的是，在iOS上用户不能简单地选择使用其他浏览器。嗯，他们可以，但正如我们刚刚看到的，他们只是伪装的 Safari。
所以不仅仅是一个浏览器落后了。iOS上的所有浏览器都落后了。iOS上的整个 WEB 都落后了。iOS已经变得如此重要，以至于整个 WEB 平台都被阻碍了。
正如开发人员对因为对长期支持 Internet Explorer 6感到沮丧一样，他们也因为必须支持Safari而感到沮丧。
更令人沮丧的是苹果最近发表的一些声明。在诉讼和监管机构的压力下，苹果为 App Store 的封闭性质辩护，称 WEB 是构建原生应用的合适替代品。你不必遵守应用商店的规则；你也可以创建 WEB 应用。
同时，他们对实现允许 Web 应用程序与原生应用程序竞争的功能不感兴趣，读到这有点伤人。
漫长的等待
不幸的是，对开发人员来说，让事情复杂化的不仅仅是缺少功能。令人沮丧的一个主要原因是突然出现的小 Bug 和错误。
现在，我不是说 Safari 比其他浏览器有更多的错误。每个浏览器都有错误。然而，当错误出现时，最重要的是问题修复的速度有多快。我要说的是，与其他浏览器相比，向用户推出错误修复需要更长的时间。
以一个关于indexedDB的严重错误为例。错误的技术细节并不重要，但时间线很重要。这个错误是在5月24日发布的iOS 14.6中引入的。它在6月2日被报告并很快修复。到目前为止，一切都很好。然后直到7月19日iOS 14.7发布才向用户推出此功能。在此期间，indexedDB 在Safari中实际上是不可用的，你的客户抱怨你的 WEB 应用程序坏了，你应该修复它。
任何其他浏览器都会立即发布错误修复。他们可以在几天内而不是几周内开始推出修复程序，因为他们的浏览器是独立于操作系统推出的。
但Safari或iOS上的任何其他浏览器不是这样；相反，你必须等到 iOS 版本中包含该修复程序，并且根据该版本的发布时间，它甚至可能不会发布即将发布的版本。你甚至不知道它是否会被包含，因为“苹果不对未来的版本发表评论”。
大多数这些问题并非源于 Safari 团队。我很确定他们会喜欢更快地发布修复程序。这是iOS平台的问题。但话虽如此，对于 Safari 和 iOS 上的其他浏览器来说，这仍然是一个问题。
所有浏览器都是平等的，但有些更平等
在这篇文章的开头，我提到Safari也使用WebKit。这是真的。但是Safari和其他浏览器的最大区别在于Safari可以自由地在用户界面和渲染引擎上竞争。如果他们想实现一个新的标准或功能，他们可以自由地这样做。其他浏览器必须等待苹果是否以及何时实现一个特定的功能时，苹果可以随时添加他们想要的任何东西。这不是公平竞争。
更糟糕的是，WebView和Safari系统在标准支持上存在差异，有时功能首先在Safari实现，但在一两个版本后才会出现在WebView中。
最近，基于 WEB 的视频通信出现了一个问题。一个允许浏览器访问手机前置摄像头的 WEB 标准在Safari中得到了一段时间的支持，但在 WEB 视图中却没有。所以如果你想使用任何形式的基于 WEB 的视频聊天，你必须使用Safari。截至iOS14.5，这个问题已经得到解决。
几年前一个更著名的例子是，Apple 拒绝允许第三方浏览器使用他们更快的 Nitro 引擎运行 JavaScript。这涉及到一些真正的安全问题，因为当时 WebView 在与应用程序相同的进程中运行，允许 Nitro 意味着允许应用程序运行任意代码。iOS 上的一大禁忌。但当然，Safari 没有这些限制。最后，他们用一个全新的 WebView 替换了旧的 WebView，它在自己的进程中运行渲染引擎，完全避免了这个问题。
他们幸运地解决了这两个问题。对他们和依赖这些功能的浏览器来说都很好。此外，Safari 团队似乎有充分的理由不将这些特定功能推出到 WebView，直到他们能够正确地这样做。
某些功能可能与 Safari 应用程序或 Apple 生态系统高度集成。因此，将该功能也推广到 WebView 是没有意义的。
但无论如何，苹果不受自己规则的约束，可以自由创新，而其他人则不能。
iOS 上的所有浏览器都是平等的，但 Safari 更平等。
那么其他浏览器能做什么呢？
浏览器可以做两件事来解决这个问题。不幸的是，两者从一开始就注定了。
正如我所提到的，WebKit 是开源的，其他浏览器制造商可以投入时间和金钱来实现他们想要的功能。如果该功能被接受并符合 Apple 对网络的愿景，那么它很有可能会被包含在 Safari 的下一个版本中——无论何时。
问题在于，这增加了使用其他浏览器改进 Safari 的负担。这不是现实世界的运作方式。
即使有大笔资金的大型浏览器供应商选择为团队提供一个，也不能保证 Apple 会在 Safari 中提供该功能。即使在今天，WebKit 仍被多方使用和开发，因此，WebKit 支持许多 Safari 未包含的功能。
我并不是说他们会出于恶意或由于“非发明在这里”综合症而忽略这些贡献。但是因为不同的愿景，他们对于网络平台有着不同的看法。
假装直到你打破它
可以工作的一件事是停止寻找解决方案的 WebKit，而是 WebView 本身。浏览器可以在 WebView 中插入 JavaScript，并且 JavaScript 可以向浏览器应用程序发送消息。这有点老套，但您可以创建一个在页面加载时自动插入的 polyfill，假装支持该功能。如果该功能需要，该 polyfill 甚至可以与浏览器应用程序对话并告诉它执行本机代码。
这就是 Cordova 和 Capacitor 应用程序的工作方式。他们运行 WebView 并提供与应用程序本机端通信的 API，以支持浏览器通常永远不会支持的功能。浏览器也可以使用这种技术。
这不仅仅是一个理论。在 Apple 在 Safari 中支持它之前，Chrome 使用它在 iOS 上提供 PaymentRequest 支持App Store 中甚至还有一些特定于功能的浏览器提供 WebBluetooth 或 WebMidi 支持。
但就像我说的。它很笨拙，随时可能不工作。并且某些功能不能被 polyfill。
当然，作为用户，如果浏览器能更多地使用这种技术为 iOS 带来新的网络平台功能，我会很高兴。但我理解为什么浏览器会犹豫这样做。
前景黯淡
那么真正解决这些问题的方法是什么？我们如何让浏览器不仅在外观上而且在网络平台功能上竞争？
只有一个合适的解决方案：Apple 需要向具有其他渲染引擎的浏览器开放他们的 App Store。废弃规则 2.5.6 并允许 iOS 上的其他浏览器并让它们真正参与竞争。尽管 Apple 被迫在某些 App Store 规则上妥协，但我对这种情况发生的希望不大。
这就是为什么我认为市场监管机构需要对此进行调查。Apple 声称 Web 是 App Store 的合适替代品，因此监管机构应该接受他们的说法并确保它成为现实。