WebKit控件自从 App Store 向第三方浏览器开放以来，它就定义了 iPhone 的浏览方式。 Chrome、Firefox、Edge、Brave、DuckDuckGo、Opera 和其他浏览器可以在 iOS 上提供不同的界面、帐户同步、隐私工具和搜索功能，但在苹果的全球规则下，它们仍然必须使用 WebKit 作为底层引擎。
该规则使得 iPhone 浏览器与 Mac、Windows、Android 和 Linux 上的浏览器不同。在这些平台上，Chrome 可以使用 Blink，Firefox 可以使用 Gecko，Safari 可以使用 WebKit。在 iPhone 上，竞争浏览器很大程度上需要使用 Apple 的引擎，这意味着页面渲染、JavaScript 行为、Web 应用程序功能和引擎级性能的最深层部分仍然与 Apple 的平台决策相关。
该规则现在正面临直接压力。在欧洲联盟，Apple 引入了对替代浏览器引擎的支持，以遵守《数字市场法案》。在英国，竞争与市场管理局继续审查苹果的浏览器引擎限制，作为其移动平台工作的一部分。开发人员、浏览器制造商和开放网络倡导者认为，当每个 iPhone 浏览器都构建在同一引擎上时，真正的浏览器竞争就不可能存在。
苹果的防御同样直接：浏览器引擎与安全、隐私、电池寿命、网络内容隔离和系统性能密切相关。苹果公司认为，开放这一层与允许另一个笔记应用程序或支付服务不同。
移动浏览的未来取决于监管机构相信哪一方。
浏览器引擎不仅仅是一个视觉渲染器。它决定如何解释网页、支持哪些网络标准、JavaScript 如何运行、网络应用程序如何运行、媒体如何播放、隐私提示如何工作以及网站采用新平台功能的速度。
这就是为什么 Apple 的 WebKit 要求始终比 Safari 更重要。竞争的 iPhone 浏览器可以构建更好的选项卡系统、更强大的书签工具、不同的密码管理器或更深入的桌面同步。但是，如果网站或 Web 应用程序需要 WebKit 不支持的引擎功能，则每个 iPhone 浏览器都会面临相同的限制。
这对于渐进式网络应用程序尤其重要。 Web 应用程序依赖引擎支持推送通知、存储行为、后台任务、可安装性、图形性能、文件处理、设备访问和高级 API 等功能。如果苹果限制 WebKit 中的这些功能，该限制将影响整个 iOS 浏览器市场。
批评者认为这是一种竞争盾牌。如果网络应用程序无法与本机应用程序完全竞争，那么应用程序商店仍然会更强大。如果 Chrome 和 Firefox 无法将自己的引擎引入 iPhone，那么 Safari 面临的来自竞争对手浏览器技术的压力就会较小。如果每个浏览器都共享 WebKit，iOS 用户可以在界面级别获得浏览器选择，但在引擎级别的选择就会减少。
苹果将相同的结构视为信任的控制点。一个引擎意味着一种安全架构、一种更新路径、一套隐私规则、一套系统集成以及更少的用户未知数。
欧盟打开第一扇门
欧盟n迫使苹果公司的统治首次发生重大突破。 Apple 现在为欧盟的浏览器应用和应用内浏览体验提供使用 WebKit 以外的浏览器引擎的权利。Apple 的 BrowserEngineKit框架支持创建使用替代引擎呈现内容的浏览器，这些功能可供 iOS 17.4 或更高版本以及 iPadOS 18 或更高版本上的欧盟用户使用。
从设计上来说，这种变化是狭窄的。它适用于欧盟，需要开发人员批准，并附带技术、隐私和安全要求。苹果还将专用浏览器应用程序与提供嵌入式浏览体验的应用程序分开，每个应用程序具有不同的权利。
这种结构表明，苹果公司是如何遵守规定的，却没有将 iOS 转变为全球范围内完全开放的浏览器引擎平台。该公司根据 DMA 的要求创建了一条受监管的路径，同时将 WebKit 保留为该框架之外的默认全局规则。
对于开发商来说，欧盟的道路既具有历史意义，又令人沮丧。这是历史性的，因为 iOS 现在为非 WebKit 引擎提供了官方路线。令人沮丧的是，浏览器制造商仍然必须决定构建、测试、运输、支持和维护单独的仅限欧盟的浏览器引擎的成本是否值得有限的市场。
这就是为什么替代引擎没有突然涌入 iPhone 的原因。浏览器公司可能需要一款适用于欧盟的 iOS 应用程序，另一款适用于世界其他地区的应用程序，具有不同的引擎行为、不同的合规性规则以及更多的支持复杂性。对于较小的浏览器制造商来说，这在商业上可能没有吸引力。对于大型企业来说，这在战略上仍然可能很尴尬。
英国可能成为下一个压力点
英国成为另一条主战线。中国气象局曾治疗过苹果和谷歌的移动平台作为可能需要竞争补救措施的领域，其公布的工作计划包括对苹果浏览器限制采取进一步行动，包括可能取消 WebKit 要求。
这很重要，因为英国的补救措施将扩大欧盟以外的压力。如果苹果在欧盟面临一项浏览器引擎规则，在英国面临另一项规则，而在其他地方又面临不同的规则，那么该公司最终可能不得不决定全球一致性是否优于区域碎片化。
苹果更喜欢统一的平台规则。区域例外会造成工程、合规性、支持和用户体验问题。但监管机构越来越多地利用地区压力来改变全球平台的行为。应用商店、支付、浏览器选择屏幕、NFC 访问和替代分发都遵循这种模式。
浏览器引擎可能比支付链接或店面规则更难，因为技术面更深。非 WebKit 引擎涉及沙箱、内存安全、JIT 编译、权限、Web 存储、媒体管道、图形、可访问性、电池行为和漏洞响应。监管机构可以命令访问，但实施仍然必须适应移动安全的现实。
这给了苹果谨慎行事的空间。这也为浏览器竞争对手提供了争论的空间，即复杂性不应成为控制的永久借口。
安全性是苹果最有力的论据
Apple 对 WebKit 控制的最强防御是安全性。浏览器处理来自整个互联网的不受信任的内容。它们始终是间谍软件、网络钓鱼、恶意广告、偷渡式下载、跟踪脚本和漏洞利用链的目标。在 iPhone 上，Safari 和 WebKit 与系统保护紧密相连。
浏览器引擎的开放创造了更多的活动部件。每个引擎都需要自己的更新流程、安全团队、漏洞响应、沙箱设计和兼容性层。如果第三方引擎修复严重缺陷的速度很慢，用户可能会暴露。如果引擎处理权限不当，隐私可能会受到影响。如果浏览器耗尽电池电量或破坏网站，苹果公司担心用户会将责任归咎于 iPhone。
这些担忧并非虚假。浏览器引擎是任何设备上最复杂的软件组件之一。 Chrome、Firefox 和 Safari 都会频繁发布安全更新，因为 Web 引擎是高风险目标。
反驳的观点是竞争也可以提高安全性。 Chrome 和 Firefox 拥有自己成熟的安全团队、漏洞赏金计划、沙盒模型和更新系统。在桌面和 Android 上，多个引擎并没有破坏浏览器的安全性。在某些情况下，竞争推动了更快的标准采用、更好的开发工具和更快的性能提升。
更好的问题不是安全是否重要。确实如此。问题是，苹果是否应该是唯一一家被允许为所有 iPhone 浏览器进行安全权衡的公司。
Web 应用程序问题是核心
最大的长期影响可能是网络应用程序。原生应用程序在 iPhone 中占据主导地位，部分原因是它们具有更深入的系统访问权限、通过 App Store 更好的分发、更强大的通知、更好的性能以及更完整的平台 API。网络应用程序仍然有用，但它们在移动设备上常常显得次要。
如果 iPhone 浏览器可以使用不同的引擎，网络应用程序可以发展得更快。浏览器制造商可以更早地发布新标准，支持更多类似应用程序的功能，以不同的方式优化 JavaScript，或者构建更强大的开发工具。这可以使网络应用程序成为本机应用程序更可靠的替代品，用于生产力、游戏、企业工具、教育平台、创意软件和内部业务应用程序。
这就是为什么争论比 Safari 市场份额更大的原因。更强大的移动网络可能会削弱 App Store 作为 iPhone 软件主要路径的角色。开发人员可以构建更多存在于浏览器中的服务，避免一些本机应用程序限制，并使用更少的独立代码库跨平台接触用户。
苹果有理由在这方面谨慎行事。该公司希望网络应用程序有用，但不能以牺牲安全性、隐私、电池寿命或本机应用程序体验为代价。它还具有商业激励措施来保持应用程序商店的中心地位。
监管机构认为这种紧张局势是问题的一部分。苹果对浏览器引擎的技术控制也可以保护其对应用程序分发的商业控制。
Safari 将面临不同类型的竞争
如果非WebKit引擎在iPhone上实用，Safari将面临更深层次的竞争。 Chrome 可以将 Blink 的更多行为引入 iOS。 Firefox 可能会带来 Gecko。浏览器制造商可以针对特定的网络标准、开发人员工作流程、隐私模型、人工智能功能或企业用例进行优化。
这可能会让 Safari 变得更加困难。苹果不仅需要通过默认布局和系统集成来竞争，还需要通过网络兼容性、速度、扩展支持、开发人员满意度、隐私工具和网络应用程序功能来竞争。
这对用户来说可能是件好事。浏览器竞争历来改善了性能和标准支持。它还可以产生有关跟踪保护、阅读器模式、密码管理、配置文件、选项卡组织、翻译、设备上人工智能和跨设备同步的不同想法。
风险在于碎片化。开发人员可能需要跨多个引擎而不是一个引擎测试 iPhone Web 应用程序。有些网站在一种浏览器中可能比在另一种浏览器中运行得更好。支持团队可能面临更多变化。用户可能会看到 iOS 基本上避免的兼容性差异。
这就是真正选择浏览器的代价。它同时带来了更多的竞争和更多的复杂性。
人工智能将使浏览器引擎更具战略性
浏览器正在成为人工智能界面。搜索、摘要、页面理解、购物助手、翻译、表格填写、编码工具、研究代理和反诈骗检测越来越与浏览器行为联系在一起。控制引擎的浏览器可以将AI更深入地集成到页面结构、隐私边界、本地处理和扩展系统中。
这给 WebKit 的争论带来了新的层面。如果 iPhone 浏览器仍然与 WebKit 绑定，那么苹果可以更好地控制 AI 功能如何与 iOS 上的网络内容交互。如果替代引擎变得可行，谷歌、Mozilla、微软、Brave 和其他浏览器制造商可以将更多自己的人工智能浏览架构引入 iPhone。
这也可能会影响搜索。 Safari 的搜索关系长期以来一直具有重要的商业意义。人工智能浏览器可能会通过将浏览变成一种更具对话性、基于任务的体验来挑战旧的搜索框。如果竞争对手的浏览器引擎在 iPhone 上受到限制，苹果可能会减缓这种转变。如果获得允许，iPhone 用户可能会看到更快的实验。
苹果仍然可以通过隐私来竞争。使用设备智能、私人中继式保护、防指纹识别和紧密系统集成的 Safari 体验可能仍然具有吸引力。但它将与真正的浏览器产品竞争，而不仅仅是围绕 WebKit 的 iOS 皮肤。
这就是监管机构试图创造的未来版本。
苹果可能的路径
除非被迫，否则苹果不太可能放弃全球范围内的 WebKit 控制权。该公司可能会继续采用区域合规模式：在法律要求的情况下使用替代引擎，在其他地方使用 WebKit，并对符合资格的开发人员制定严格的权利规则。
与此同时，监管压力可能会使这一地位更难维持。如果欧盟推动更实际的合规性，英国遵循浏览器引擎补救措施，并且其他市场研究类似的规则，那么苹果可能需要决定维护单独的区域浏览器架构是否值得如此复杂。
该公司还可以积极改进 WebKit 和 Safari 以减轻压力。更好的网络应用程序支持、更快的标准采用、更强大的开发人员沟通、改进的扩展支持以及更丰富的浏览器选择设置可能会让监管机构不那么急于实施更深入的补救措施。
这可能是最现实的近期结果。 Apple 在能控制的地方保持控制，在必须的地方开放，并对 Safari 进行更多投资，因此 WebKit 要求看起来不像是瓶颈。
对于移动浏览器，下一阶段将是实践而非理论。问题不再是是否可以在某个地方允许使用替代发动机。他们已经可以进入欧盟了。下一个测试是浏览器制造商是否可以大规模交付它们，监管机构是否认为苹果的条件可行，以及用户是否会得到有意义的差异，而不是另一个几乎没有变化的设置屏幕。
第一个成功为日常用户带来非 WebKit 引擎的 iPhone 浏览器将不仅仅是一个浏览器的发布。这将是一个测试案例，检验 iPhone 上的移动软件能否超越苹果的引擎，同时又不破坏人们对 iOS 最初的价值的信任。
