苹果：日本用户可以使用其它浏览器引擎
这次变更实质上意味着Chrome取代Safari——这其实没什么意义。它们都是同一代码库的分支。
在 iOS 26.2 及更高版本中，日本用户可在两类应用中使用 WebKit 以外的浏览器引擎：提供完整网页浏览体验的专用浏览器应用，以及由浏览器引擎维护者开发的应用——这些应用通过嵌入式浏览器引擎提供应用内浏览体验。
苹果将向授权开发者开放系统内关键技术，助力其提供高性能现代浏览引擎。这些技术包括即时编译、多进程支持等功能。
然而，由于浏览器引擎持续暴露于不可信且可能恶意的内容中，并能接触敏感用户数据，其已成为恶意攻击者最常利用的攻击载体之一。为保障用户网络安全，苹果仅授权满足特定标准且承诺持续履行隐私安全要求的开发者实施替代浏览器引擎，包括及时发布安全更新以应对新兴威胁与漏洞。
网络浏览器引擎权限
浏览器应用相关
通过浏览器引擎权限，您可在浏览器应用中使用替代浏览器引擎。若有意在浏览器应用中采用替代引擎，请查阅以下要求后提交浏览器引擎权限申请。技术指导请参阅：
要求
要获得此权限，您的应用必须：
- 仅在日本的 iOS 平台上分发(除非您已根据《开发者协议》(含所有附录)获得苹果明确许可，可在其他司法管辖区或苹果平台分发，并已相应获取权限配置文件)；
- 与使用系统提供的网页浏览器引擎的任何应用程序保持独立二进制文件；
- 具备默认浏览器权限
- 满足以下功能要求，确保应用程序使用的网页浏览器引擎提供基础网络功能：
- 您和您的应用必须满足以下安全要求：
- 承诺采用安全开发流程，包括监控应用软件供应链中的漏洞，并遵循安全软件开发的最佳实践(例如对开发中的新功能进行威胁建模)。
- 提供已发布的漏洞披露政策网址，其中应包含第三方(可能包括苹果公司)向您报告安全漏洞和问题时的联系方式、报告需提供的信息内容以及状态更新的预期时间。
- 承诺及时缓解应用程序或其使用的替代网页浏览器引擎中正在被利用的漏洞(例如：针对最简单类别的活跃漏洞，修复期限为30天)。
- 提供公开网页(或多个网页)的URL，说明已修复的漏洞在浏览器引擎的具体版本中得到解决的情况，若应用程序版本不同则需注明对应版本。
- 若替代网页浏览器引擎使用的根证书存储库未通过iOS SDK访问，则必须公开根证书策略，且该策略所有者必须以浏览器身份参与认证机构/浏览器论坛。
- 证明浏览器引擎运行时支持现代传输层安全协议，以保护传输中数据通信的安全性。
程序安全要求
您必须：
- 在替代网页浏览器引擎中，至少对所有处理网页内容的代码使用内存安全编程语言，或采用能提升其他语言内存安全性的特性；
- 采用最新的安全缓解措施(例如指针认证码)，这些措施能消除特定类别的漏洞或大幅增加开发漏洞利用链的难度。具体包括：
- 指针认证码(PAC)；
- 对任何内容扩展中的系统分配器，以及应用程序(包括网络和图形渲染扩展)中所有进程和扩展的自定义/系统分配器实施内存完整性强制(MIE)；
- 遵循安全设计与编码最佳实践；
- 采用进程隔离限制漏洞利用影响，并在替代网页浏览器引擎内验证进程间通信(IPC)；
- 监控第三方软件依赖项及应用程序更广泛的软件供应链中的漏洞，若漏洞影响应用程序则迁移至新版本；
- 避免使用不再针对漏洞提供安全更新的框架或软件库；以及
- 优先快速修复已报告漏洞，而非开发新功能。例如，当替代网页浏览器引擎在平台SDK与网页内容间建立桥梁以启用Web API时，若发现该Web API存在漏洞，必须应要求立即移除其支持。多数漏洞应在30天内修复，但部分复杂漏洞可能需要更长时间。
计划隐私要求
您必须：
- 默认阻止跨站Cookie(即第三方Cookie)，除非用户在知情同意下明确允许此类Cookie，或为兼容弹出窗口与打开窗口框架交互而必须允许；
- 按顶级网站对网站可观察的存储或状态进行分区，或阻止此类存储或状态在跨站使用及被观察；
- 不得在应用与其他应用(包括同一开发者的应用)间同步任何状态(含Cookie)，除非用户通过登录双方应用或提供明确授权等方式主动许可同步；
- 未经知情同意及用户主动授权，不得与网站共享设备标识符；
- 使用提供给 iOS 的 API 标记网络连接以生成应用隐私报告(即应用分发的任何平台)；
- 遵循通用网络标准，在需要时要求用户知情激活和/或同意(适用于网络 API，如剪贴板或全屏访问权限)，包括涉及个人身份信息访问的场景。
嵌入式浏览引擎权限
应用内浏览场景
通过嵌入式浏览引擎权限，您可在应用内嵌入替代浏览引擎以实现应用内浏览功能。应用内浏览指动态展示可通过网页浏览器访问的内容，此类内容需能在网页浏览器应用中正常运行。此功能不包含仅通过应用内嵌或获取的内容。
提供应用内浏览时，您的应用核心功能必须是提供网页浏览服务。应用内浏览界面必须满足以下要求：
- 除用户控制浏览会话的相关控件外，界面应占据屏幕大部分区域；
- 提供系统默认浏览器的按钮或链接，允许用户通过独立浏览器应用查看当前显示内容；
- 显示当前通过应用内浏览呈现内容的域名或URL。
若您希望在应用中使用替代浏览引擎提供应用内浏览体验，请查阅以下要求后提交嵌入式浏览引擎授权申请提交请求。您需提供拟嵌入引擎的相关信息，包括其如何满足要求以及如何集成到应用中以实现应用内浏览体验。技术指导请参阅示例与资源部分。
要求
要获得该授权资格，您的组织必须是浏览器引擎管理方。浏览器引擎管理方是指对独立网页浏览器引擎运营承担主要责任的实体。
- 主要责任指您对浏览器引擎拥有运营控制权，并在发现安全或隐私漏洞时承担协调响应及最终解决责任。
- 独立的网页浏览器引擎由与其他浏览器引擎不同的实体或组织维护，其架构和对 Web API 的支持与其他引擎存在实质性差异。该引擎通常不会根据分支版本的变更进行更新，而是向分支版本推送变更。
应用要求
您的应用必须：
- 仅在日本的 iOS 平台上分发(除非根据《开发者协议》(含任何附录)获得苹果明确许可，可在其他司法管辖区或苹果平台分发，且您已相应获取许可配置文件)；
- 仅将权限用于应用内浏览；
- 不得拥有默认浏览器权限
- 满足以下功能要求，确保应用使用的网页浏览引擎具备基础网络功能：
- 满足以下安全要求：
- 承诺采用安全开发流程，包括监控应用程序软件供应链中的漏洞，并遵循安全软件开发的最佳实践(例如对开发中的新功能进行威胁建模)。
- 提供已发布的漏洞披露政策网址，其中应包含第三方(可能包括 Apple)向您报告安全漏洞和问题的联系方式、报告需提供的信息内容以及状态更新的预期时间。
- 承诺及时缓解应用程序或替代网页浏览器引擎中正在被利用的漏洞(例如，对于最简单的正在被积极利用的漏洞类别，应在 30 天内完成)。
- 提供公开网页(或多个网页)的URL，说明已修复的漏洞在浏览器引擎具体版本中的解决情况，若应用版本不同则需注明对应版本。
- 若所选替代网页浏览器引擎使用的根证书存储库无法通过iOS SDK访问，则必须公开该根证书策略，且该策略所有者必须以证书消费者身份参与认证机构/浏览器论坛。
- 证明浏览器引擎运行时支持现代传输层安全协议，以保护传输中数据通信的安全性。
程序安全要求
您必须：
- 在替代网页浏览器引擎中，至少对所有处理网页内容的代码使用内存安全编程语言，或采用可提升其他语言内存安全性的特性；
- 采用最新的安全缓解措施，消除特定类别的漏洞或大幅增加漏洞利用链的开发难度；
- 遵循安全设计与安全编码的最佳实践；
- 监控第三方软件依赖项及应用程序更广泛的软件供应链中的漏洞，若漏洞影响应用程序则需迁移至新版本；
- 不得使用不再针对漏洞提供安全更新的框架或软件库；以及
- 优先快速修复已报告漏洞，而非开发新功能。例如，当替代浏览器引擎通过连接平台SDK与网页内容来实现Web API时，若发现该Web API存在漏洞，必须应要求立即停止支持。多数漏洞应在30天内修复，但部分复杂漏洞可能需要更长时间。
程序隐私要求
您必须：
- 默认阻止跨站Cookie(即第三方Cookie)，除非用户在知情同意下明确允许此类Cookie，或为兼容弹出窗口与框架交互场景而必须启用；
- 将网站可观察的存储或状态按顶级网站进行分区，或阻止此类存储/状态在跨站点间的访问与观察；
- 未经知情同意和用户主动授权，不得与网站共享设备标识符；
- 使用iOS系统提供的API标记网络连接以生成应用隐私报告(即应用分发所在平台)；
- 遵循普遍采用的网络标准，在需要时要求用户知情激活和/或同意(适用于Web API，如剪贴板或全屏访问权限)，包括涉及个人身份信息访问的API。
附加要求
- 每次提交二进制文件时，必须附上应用内嵌替代网页浏览器引擎的名称及版本号。
- 当应用内嵌的替代网页浏览器引擎发布新版本时，您必须在十五(15)个日历日内提交包含该新版本的应用更新。
示例与资源
本节提供额外资源和示例，帮助您满足使用替代浏览器引擎的相关要求。
安全软件开发生命周期(SDLC)
您需满足的诸多要求，均依赖于在应用程序中引入新功能时采取安全与隐私优先的开发策略。启动新功能开发时，应首先建立威胁模型，并制定计划以确保架构设计及应用发布版本能有效规避已识别风险。验证手段包括代码审计、模糊测试以及编写验证安全属性的测试用例。请将所有网页内容视为不可信且可能存在恶意。
资源
安全缓解措施与内存安全
您还应考虑 iOS 或 iPadOS 提供的现有安全缓解措施(如指针验证码和内存完整性强制机制)，以及可用于缓解各类已识别威胁的编程语言(或语言特性、编译器功能及其他工具)。例如 Swift 默认具备内存安全性，可帮助您规避多种常见漏洞源及其他内存相关软件缺陷。然而，C++等内存不安全的语言也提供了增强内存安全性的特性——例如std::span。此外，编译器选项和工具同样可发挥作用，例如C语言的-fbounds-safety选项，它允许对现有代码进行注释标记，从而缓解越界内存访问问题，而无需始终将功能重写为默认内存安全的语言。
参考资源
漏洞管理
您应假设浏览器引擎中始终存在未被发现的漏洞，或任何新功能都可能引入意外风险。因此，建立完善的响应流程至关重要——无论漏洞是通过内部测试、安全隐私保障工作、软件供应链环节发现，还是由第三方披露，都需确保能及时应对。
若您为第三方(如安全研究人员)提供了漏洞上报渠道，需明确要求其提供哪些信息才能快速判断漏洞有效性及成因。同时应确保建立优先修复漏洞的流程，并能随时发布更新——即使这可能打破常规发布周期。
用户应能快速查明：哪些已公开且关联CVE-ID的漏洞已在您应用程序(或替代浏览器引擎)的哪个版本中修复。
参考资源
网络安全
通过使用 iOS SDK(特别是网络框架和/或 SecTrust API)，您无需承担评估网络证书可信度、维护或使用对应根信任存储库的责任，也无需为所使用的替代浏览器引擎配置相应程序。若您仍需运行此类程序，则应提供以下信息：根证书颁发机构(CA)如何申请加入该计划，以及如何报告安全事件(例如根证书颁发机构私钥材料泄露)，以便您及时采取应对措施。
网络协议持续演进以应对新兴威胁并强化用户隐私安全防护。当前应与替代浏览器引擎兼容且未被弃用的现代 TLS 版本为 TLS 1.2 和 1.3，但未来可能变更。您可在替代浏览器引擎中支持已弃用的协议，但当用户访问仅支持此类协议的网站时，应予以提示。
参考资源
协议
本文文字及图片出自 Using alternative browser engines in Japan，由 WebHek 分享。
我不会说苹果应该封杀竞争浏览器，但我知道这种事迟早会发生。
天啊，我实在不愿看到这种局面。iPhone几乎是唯一能阻止Chrome/Chromium像当年IE那样统治整个网络的屏障。
我不认为谷歌会像微软那样彻底放弃某些领域，但他们绝对拥有微软当年那种强推功能的霸权。
我绝不愿被迫使用Chrome——只因它成为多数网站唯一兼容的浏览器。某些网站的兼容性问题已经够糟了。
而苹果的固执与截然不同的考量，恰恰意外地阻挡了这股浪潮。
我迫切期待监管机构履行职责，剥夺苹果在所有领域的独裁控制权，届时所有关于这些边缘问题的末日预言终将显得荒谬可笑。
Chrome能对网络施加何种控制？新增API并不能强迫数十亿网站采用。即便某网站启用了WebBluetooth又如何？反正你本就不愿网络具备此功能，继续用Safari也依然无法获得。真为你高兴！
当年桀骜的Firefox能在开放平台上拯救网络免遭95%的IE垄断，为何如今我们竟全盘依赖苹果一家来拯救我们免受~60%的Chrome支配？这分明是习得性无助和斯德哥尔摩综合症作祟。真好奇在万亿市值公司开始“精心呵护”我们之前，人类是如何生存下来的！
就在昨日https://news.ycombinator.com/item?id=46454115：
> 我希望浏览器能抵御所有这些侵扰。Ublock Origin曾完美做到，直到谷歌出手扼杀它。如今的Ublock Lite远不及从前。
>
> 我视此为背叛——谷歌自不必说，连Python官网这类随机网页设计师也同样可耻，他们竟认为在访客抗拒干扰时进行骚扰是道德正当的。我不接受广告；不接受弹窗或滑入式效果(99.999%的情况下；某些通知尚可接受，但捐赠版罗宾汉式的敛财者不在此列)。"
你为何给我发个随机评论链接？
编辑：明白了。火狐还有uBlock Origin。你没抓住重点。若Chrome想降低自身吸引力，你反而该庆贺。
> 若Chrome想降低自身吸引力，你反而该庆贺。
我认同Chrome为推进谷歌商业目标而削弱用户自主权的行为，在完美市场中本应降低其竞争力。
但当今浏览器市场并不存在完美竞争，我甚至想不起它曾有过完美竞争的时期。
监管机构阻止苹果控制iOS浏览器引擎，却允许谷歌实质掌控网络生态——这正是政府干预市场、选择赢家输家的典型案例。
公共政策需要推动市场走向真正的竞争。
若你读过该报告，便会明白谷歌对终端用户浏览器体验的影响力。
Firefox之所以能运作，是因为iOS迫使网站所有者支持多种引擎
不知有多少Chrome粉丝还记得IE6时代。
> Chrome能掌控网络到什么程度？新增API并不能强制数十亿网站采用。
你假设新增API是净收益，但Chrome隐私沙盒计划的惨败表明事实并非如此
> 为何我们全盘依赖苹果来拯救我们免受~60% Chrome的统治？
火狐现在状况如何？他们实际上依赖Chrome才能生存。没有谷歌，他们就没有资金支持开发。
如今唯一可行的非Chromium浏览器引擎且不受谷歌资助的只有WebKit。
但那已是近二十年前的事了。如今形势截然不同，很难想象火狐还能拯救什么。可悲的是，唯一有能力制衡FANG巨头的正是FANG巨头本身(尽管我们仍期待欧盟能保持决心，各国能迟来的意识到：依赖美国科技巨头是巨大的战略失误，如同乌克兰过度依赖美国军事卫星数据般危险)。
没错，新问题需要新方案。我质疑的是那种寄希望于“仁慈”企业永远保持绝对控制权的父权主义逻辑——这不过是徒劳的幻想。
考虑到火狐的组织更迭和文化问题，我对其拯救我们并不抱太大信心。
我更看好Ladybird这类新晋浏览器。iOS系统理应支持Ladybird，为何不可？
“新晋浏览器”的困境在于：唯有革命性功能才能促使用户大规模迁移。
标签页/稳定性(Firefox vs IE)。V8引擎(Chrome vs Firefox)。
除此之外都是消耗战，最终由广告预算最雄厚的竞争者胜出。或者谷歌胜出，因为它能淹没所有自有广告渠道。
而Chrome仍只是险胜。
Ladybird团队过于自负。
他们更热衷于从零打造产品，而非专注于实际可用性。
此外他们正转向Swift语言，这只会让性能更糟。
所以你还想要另一个基于Chromium的浏览器？Ladybird项目的核心价值在于证明完全独立的浏览器引擎是可行的。况且并非所有功能都从零开发——例如它将沿用Chromium(及现今Firefox)使用的图形库Skia。建议阅读官网FAQ说明：
https://ladybird.org/#:~:text=What%20does%20%22No%20code%20f…
> 所以你想要另一个基于Chromium的浏览器？
我想要不含谷歌代码的产品，但既然涉及Skia，他们显然没做到。
反而把资源浪费在非必要领域。比如自研JS引擎，而不是直接采用SpiderMonkey、JSCore或QuickJS这类现有方案。
让他们随心所欲地花钱吧。又不是靠政府补贴
>又不是靠政府补贴
查看赞助商 https://ladybird.org/
我是不是漏了哪个政府机构？
补贴不一定指政府资助。
> Chrome将对网络施加何种控制？
还记得Manifest 3.0吗？他们直接废除了广告拦截扩展。
若所有人都转用Chromium，网络标准将不复存在。届时所有网站都必须支持Chromium，任何符合谷歌标准的方案都将成为规范。这意味着将出现未公开的规范文档。浏览器引擎开发者根本无法与之抗衡，他们的资源远不及谷歌。
你认为网络应该保持开放标准吗？如果谷歌主导技术边界拓展，其他公司如何追赶？
在此必须彻底澄清……问题中的另一方是苹果——这家全球最富有的公司正制造着全球最漏洞百出的浏览器，详见此文https://wpt.fyi/results/?label=master&label=experimental&ali…
你所鼓吹的观点恰恰是苹果自掘的坟墓——这绝非疏忽，而是他们为保护利润率刻意做出的决策。其核心用户留存策略正是基于全球(尤其美国)法院永远不会迫使他们在开放市场中自由竞争的事实，消费者选择权根本不构成制约因素。
我从未说过任何赞同Safari的话，这并非我“鼓吹”的观点。我支持的远不止Chromium。
> 若说Firefox当年能异军突起
只因IE当时简直是狗屎。FF的改进如此显著，用户不得不转向。
Chrome固然优秀。但新晋浏览器根本无从竞争。
浏览器完全有能力竞争：阻挡现代弹窗(如今弹窗直接嵌入页面，用渐变色覆盖内容迫使你点击“订阅邮件列表”或“加入社交网站”提示，浪费时间点击关闭)；自动暂停未聚焦标签页的循环视频；限制加密货币挖矿标签页；集成uBlock Origin；处理WiFi服务条款点击确认； 等等。
想想那些你希望浏览器稍作调整就能提升体验的场景吧
竞争点不胜枚举：效率(启动速度、内存占用)、安全性(从网站广告拦截到扩展程序乃至应用本身)、定制化(外观与行为双重调整)
此外，当时Windows系统强推Edge浏览器的掠夺性界面，以及Google.com强推Chrome的策略根本不存在。
按你的逻辑，一家占据全球智能手机市场约25%份额的公司，竟应被_法律禁止_打造软硬件深度整合的生态。
而占据全球浏览器市场70%份额的企业，即便份额进一步扩大，却莫名其妙地无法从中获益。
真不知若没有诸位独一无二的头脑进行独特的市场分析，我们这个物种该如何生存下去。
> 一家占据全球智能手机市场约25%份额的公司，竟被要求_法律禁止_打造软硬件深度融合的产品组合。
绝对不行。我们大多数人都完全满意苹果将Safari与硬件深度整合的做法。
然而，我们将通过法律手段禁止苹果阻止用户打破这种深度整合，因为这是用户自己的设备。苹果并不“拥有”智能手机市场：它提供硬件和服务，然后闭嘴。
网络生态与苹果生态不可同日而语。IE曾占据相当大的市场份额，却在短时间内被Chrome击垮。此前Firefox也曾有效挑战过IE。但即便谷歌、Linux和苹果(macOS)全力竞争，Windows(桌面端)至今仍保持着相当大的市场份额。
操作系统的锁定效应远比网络更难打破——后者标准是公开制定并共享的。谷歌的优势之一在于实现所有标准的复杂性。但这并非锁定，而是能否投入足够资源开发合规浏览器的问题。
过去十年你躲哪儿去了？Chrome早已将网络视作私有领地，而开发者们欣然配合。如今数十项Chrome专属的非标准特性被冠以“公开制定标准”之名，开发者们甚至嘲讽其他浏览器未予支持。
其他厂商选择不实现标准是出于正当理由(例如隐私保护)，但这终究是厂商的决策而非技术限制。相关文档和规范均可免费获取。
至于Windows系统，根本不存在规范文档。由于专利限制，根本不可能实现另一个Windows克隆系统。Wine虽存在，但其逆向工程过程极其艰难。
> 其他厂商选择不实施标准是其自主决定
餐巾纸上的涂鸦不能成为标准。
在未获支持、未经同意且遭其他浏览器厂商反对的情况下，单一浏览器引擎发布的特性不能成为标准。
Chrome发布的内容并不意味着其发布的内容就是标准。
> 文档和规范可免费获取。
Chrome正是如此滥用其地位，利用轻信的开发者误以为：只要文档存在，功能随Chrome发布即成标准。
标准制定绝非如此运作。
坦白说我不认为这是威胁。Safari作为默认应用已确保其地位，除非谷歌为iOS版Chrome推出杀手级功能。而苹果要求该应用仅限日本分发，谷歌不太可能为此强推。
况且移动网页正日益成为小众平台——随着时间推移，网络正趋于中心化，多数主流网站都将用户重定向至自家应用。
更不用说直接网页搜索正被AI搜索取代，谷歌似乎坚信这是未来方向。
它曾是Mac的默认浏览器，但远非当地最受欢迎的选择。
谷歌对Chrome的推广力度极大。
确实。最近甚至在亚马逊Prime视频上看到Chrome电视广告。尽管市场地位稳固，他们仍在大力营销。
此外，切勿低估开发者停止支持非Blink浏览器的威力——他们正重演IE时代的套路，用“最佳浏览效果需Chrome”和“浏览器过时！请下载Chrome”的提示牌施压。没有什么比功能失效更能驱动用户行动了。
同理，Edge是Windows的默认浏览器。Chrome占据75%的市场份额。
确实有趣——每次我在iOS的Safari上进行谷歌搜索时，总要先关闭满屏的Chrome广告才能看到搜索结果。
没错，但解决之道在于善于打破垄断，而非允许一方阻挠另一方。
这本该是早该发生的事。
就我所见，短期内只有两种可能：
苹果封杀谷歌及其他竞争者，或谷歌全面掌控网络。
眼下似乎只有这两种选择。我都不喜欢，但更讨厌其中一种。
你的论点建立在虚假二分法上，充斥着挑拨性言论的气息。你宣称我们只有两种选择：苹果的暴政或谷歌的霸权。这完全忽略了原帖明确提出的第三种方案：强力反垄断执法。当你说“这本该是多年前就该采取的措施”时，你假装我们如今束手无策，仿佛无法通过立即实施恰当的反垄断措施来解决问题。
谷歌构成的威胁存在，并不能成为苹果实施反竞争商业行为的正当理由。我们无需在垄断者之间“选边站队”，完全可以且应当通过立法手段同时应对两者。将此问题简化为二元选择，不过是保护守门人、维持现状的消极策略。
我们当下在短期内确实束手无策。这不是在挑衅。
那么在未来两年(姑且如此设定)内，我们能采取什么措施既允许其他浏览器登陆iOS平台，又能阻止Chrome全面垄断？
我实在想不出其他方案。就我所见，这已是唯一选择。
长远来看确实该拆分谷歌。若他们不再拥有Chrome，问题自然解决。但这种情况会在一两年内发生吗？
还是说我们即将赋予他们更多控制权，然后耗费未来5-10年试图扭转局面？
正如我在其他场合所言，我不喜欢这种局面。政府本不该放任事态发展至此。我并非在选择“偏爱的垄断者”，只是在现有两个选项中，认为危害较小者。
我们自食其果，至少在未来数年内，我不愿让局面进一步恶化。
我们并非“束手无策”，设定两年期限纯属转移视线。美国司法部和欧盟的行动速度已创数十年之最。你问我们能做什么？我们可立即强制执行浏览器选择界面并开放替代引擎。这将首次为火狐(Gecko)在移动端创造竞争机会。维持生态系统封闭只会永远扼杀火狐的生存空间。
你那套说辞根本是“末日防御论”的续篇。如今又添上“未来两年”的任意时限来为不作为开脱。我们无需先“瓦解谷歌”才能制止苹果的反竞争行为，完全可以同时推进两项工作。你将“允许其他浏览器”(如火狐)等同于“将控制权交给谷歌”的观点，暴露了逻辑谬误。这无异于主张为消灭恶龙必须摧毁村庄(开放网络)——若这不算忧思型网络喷子，我真不知何为。
别搞错了，这正是“放过万亿市值企业”派在相关讨论中最爱搬出的五大论点之一。这种论调绝非偶然或无心之失，凡是讨论苹果与反垄断的文章下，它几乎都会如影随形。这种论调本质上是在为苹果的反竞争行为开脱，其逻辑等同于“放任苹果反竞争行为，否则[此处填入末日场景]”。他们拒绝推动实施正当反垄断措施以恢复健康竞争市场，反而企图维持现状——让守门人继续为所欲为。
向来如此。从通过用户代理屏蔽功能到价值数十亿美元的广告(实际支付的仅是九牛一毛)。
谷歌已无实质内容可供检索，充斥着一个接一个的AI垃圾网站。
即便找到内容，也必然出现在广告泛滥的网站上。
AI搜索完全没有这些问题。十五年前的谷歌远比今天优秀得多。
>AI搜索完全没有这些问题
目前如此。AI的养分来自它所替代的内容。正因如此我对它的长期可行性持怀疑态度——例如当新闻发布不再盈利时，它如何继续为我提供新闻？
谷歌搜索里唯一还能用的站点是Reddit。添加关键词“reddit”就能启用，但效果令人失望。
赞同。这已成为我唯一仍使用谷歌的场景。
> Safari作为默认应用
但这种情况可能改变。至少在欧盟，苹果已开始提示用户选择浏览器[1]。虽然目前所有浏览器底层都基于WebKit引擎，但随着欧盟要求苹果开放其他引擎[2]——加之用户通过广告、工作或安卓手机接触过Chrome，我认为很多人会选择Chrome作为默认浏览器。
1: https://www.heise.de/en/news/Apple-alters-selection-screen-f… 2: https://developer.apple.com/support/alternative-browser-engi…
直到网站开始阻止你在非Chrome浏览器登录、完成交易或下单
或者直接出现故障。我确实遇到过在移动版Safari能正常运行的网站，却无法在桌面版Safari上使用。因为开发者既不测试也不在乎。
你必须使用Chrome或Firefox。我们早就看清Firefox的所作所为，他们不会再成为我们的救星了。
苹果公司在此事上难辞其咎。
1. 他们打造了全球漏洞最多的浏览器。看看这份图表，它展示了仅在单一浏览器中出现的漏洞数量。https://wpt.fyi/results/?label=master&label=experimental&ali…
2. 他们拒绝支持任何现代测试协议，例如WebdriverBiDi
3. 他们拒绝向非苹果硬件用户开放软件。
问题的核心根源显然在于苹果——他们除了制造全球漏洞最多且最不兼容的浏览器外毫无建树，还试图将被迫使用该浏览器的用户捆绑为人质，直至法院介入才被迫停止。
> 他们拒绝向非苹果硬件用户提供软件。
凭什么？这何时成了规定？若雅达利存活至今，难道就必须开发Windows软件？康懋达呢？
法律何时/为何要求所有厂商都开发Windows应用？
当真？
为何用户要购买昂贵的专用硬件来测试糟糕的网页浏览器？
跳过这一步才合乎逻辑。
完全赞同，过去一年我一直在向人们解释这个道理。
现在用iPhone时，我怀念Android版Firefox(带Ublock、赞助商屏蔽等功能)。但正是这种痛苦的限制，才阻止了Chrome沦为新的IE6。
我在几家初创公司工作时，开发人员全部只用Chrome，开发期间也只在Chrome上测试。
他们考虑其他浏览器唯一的原因是iOS平台的Safari。有时是发布后接到iOS用户的求助电话/投诉才被迫测试。如果Chrome引擎获准登陆iOS，客服就能直接让用户安装Chrome(就像现在Windows用户在其他浏览器遇到问题时客服的做法)。这意味着Firefox通常也能正常运行。
多年前，当我的银行网站在Opera 12上无法运行时，我得以更换银行。若所有主流银行/网站都只针对Chrome优化，我们别无选择只能使用它。届时当谷歌在Chrome中推行新限制时，我们将完全失去控制权。
这艘船早已启航。而苹果正是问题的一部分。最近因Facetime不支持Firefox，我改用微软Edge。但音频功能失效后，又切换到谷歌Meet(该功能在Firefox上正常)。
虽然部分认同你的观点，但安卓版Firefox实属优秀的移动浏览器(尽管存在某些怪异之处)。我渴望在iOS设备上获得同等体验，可惜目前完全不可能。
若苹果持续创新并采纳部分网络标准，其引擎必将胜出。但现实是，他们100%在封锁其他引擎且拒绝采纳标准——只因当开发者无法发布PWA应用被迫采用“应用程序”模式时，他们就能坐收30%的甜美分成。
WebKit近年确有显著进步，只是更专注于优化CSS这类功能，而非开发者梦寐以求的API——比如能查询用户冰箱里啤酒数量的接口。
你无意间印证了他的观点。苹果从不盲目开发，他们深谙自身利益所在——任何可能削弱利益的功能都会被跳过、忽视或草率实现。
这取决于视角。
在我看来，谷歌倾向于专注于小众功能，仅惠及少数网页应用。反观苹果，其研发成果能惠及从静态博客到大型商业网应用的各类场景。
我希望谷歌能在这方面更像苹果，因为支撑整个网络的基础组件仍极其粗糙，导致如今的框架和应用如同“高尔夫球车上载着半吨卡车”般荒诞——这正是网络生态闻名遐迩的怪象。若能让网页开发摆脱螺旋分形般的依赖树困局，其作为平台的繁荣前景远比GPU或USB设备访问权限这类功能更为关键。
当IE凭借强势姿态不断添加实用新功能时，人们并不介意。他们放弃网景浏览器，是因为这些功能让网络变得更好。直到他们停止在浏览器本身添加功能时，问题才真正显现。他们仍在添加功能，但过度依赖ActiveX——这并非必然之恶，其中蕴含着跨操作系统和各类应用程序复用组件的宏伟愿景，Java小程序乃至Shockwave/Flash也曾尝试类似路径，但效果更差且均饱受安全问题困扰。随后微软几乎完全停止创新，长期拒绝追赶技术潮流——无论是浏览器外插件(哦，Silverlight…)还是浏览器本体。长期不支持标签页、弹窗拦截(后期广告拦截)，性能表现糟糕… 当各类“网页标准”不断进步，为用户和开发者带来更优体验，并增加无需外部插件的功能时，微软同样步履蹒跚。
最终，IE地狱般的体验源于多重因素：恶劣的用户体验、安全漏洞、性能问题，以及开发者为寻找替代方案或支持而承受的痛苦——因为它在所有方面都严重落后。这与其制定规则或尝试新功能的能力毫无关系。这种恶劣用户体验的负面影响甚至蔓延至浏览器之外，催生了“仅IE兼容”的特殊需求——迫使用户为特定网站使用IE。总体而言，这种现象与“仅支持Flash或Java小程序”的困境相当，但远不及IE浏览器本身的糟糕体验。如今，当年地狱般的体验中仍有两部分具有现实意义：恶劣的用户体验和开发者的痛苦。十多年来，移动版Safari继承了这两大特点。虽然没人再支持IE11(更不用说更早版本的IE)，但开发者仍不得不支持移动版Safari。相比移动版Safari的糟糕表现，我反而怀念当年为IE11(及更早版本)提供支持和解决问题的日子。我认为移动端更应推广基于Chromium的浏览器——尽管我个人在PC和安卓设备上仍使用Firefox(尽管其用户体验存在缺陷，至少不算恶劣)。唯一令人担忧的地狱环节是恶劣的用户体验，但只要给予用户选择权，这个问题完全可以通过个人调整来规避。
直到他们停止为浏览器本身添加功能，问题才真正开始显现。
这只对那些被误导的“推动网络进步”的蠢货们适用——他们只想要最新最炫的玩意儿，还被谷歌掌控互联网的计划所助长。对于其他所有需求，纯HTML本已足够好用。
谷歌的武器就是变革。他们拥有无限资源，能通过随意改写“标准”碾压所有竞争者。人们越不认为持续变革是必需的，网络就越能健康发展。
我认为这种观点很愚蠢。
HTTP和Wasm这类技术实为跨平台软件交付的卓越工具，而浏览器正是理想的沙盒执行环境。
认为网络只该承载纯HTML文档的观念，本身就是一种错误的思维模式。
苹果公司拥有数十亿美元的收入来源，其根基正是建立在“除非能掠夺企业30%利润，否则无人能在其平台发布软件”的逻辑上。为此他们耗费大量精力破坏“网络可成为应用平台”的理念，但你没必要为苹果的利润率和反消费者胡扯摇旗呐喊。
问题不在于网页应用本身，而在于那些本可用简单HTML实现的功能却要依赖网页应用。
Safari太糟糕了，我想要iOS上真正的Chrome体验
具体表现如何？标准实现差？性能问题？用户体验？
缺乏全屏API导致无法实现多种游戏体验
缺少方向API导致无法开发需特定方向的游戏及其他体验
不支持WebXR(尽管苹果将在Vision Pro上开放)
不支持ResizeObserver的devicePixelContentBoxSize属性，导致无法根据用户缩放级别正确渲染内容
无法简易安装PWA应用，需执行只有专家用户才懂的晦涩操作。
以上仅是随手列举的几项缺陷。
我明白评论区会充斥“不需要这些功能”的言论，但这完全无关紧要。允许用户关闭功能即可，需要权限验证也行。这些功能在其他操作系统(桌面端和移动端)已稳定运行五年以上，世界并未因此终结。
世界确实没毁灭，但这些功能很可能让情况更糟。这已足够成为不实施它们的理由。
我常听到这种说法，但自2003年发布以来，我始终将Safari作为首选浏览器。其性能始终出色，界面始终简约不干扰，从未向我推销任何附加功能。它有时会出现卡顿，有时又引领行业标准。偶尔会有网站无法正常运行，但iOS系统大大降低了这种可能性。唯一能想到的缺点就是它不是<插入你最爱的浏览器>，或者缺少<某些冷门特色功能>。
不过话说回来，我只用广告拦截插件，或许我错过了某些功能。
从用户视角看或许无碍，但诸多问题都转嫁给了网页开发者——他们不得不绕过这些限制才能让页面在Safari正常运行。
自2000年代初涉足网络技术领域，Safari从未带来困扰，除了像Flash时代那样侵入性的广告。
这纯属无稽之谈。所有网页开发者都清楚你并非实话实说。为让更多人看清真相，特此附上仅在单一浏览器中出现的漏洞数量图表。
https://wpt.fyi/results/?label=master&label=experimental&ali…
苹果浏览器烂得像狗屎，这是不争的事实。
> 这纯属胡扯，所有网页开发者都知道你并非实话实说
在你看来“实话实说”就是代表所有网页开发者发声？
我从事网页开发25年(天啊我老了)，Safari从未给我带来过重大困扰。
你总在拿wpt.fyi测试结果说事，却根本不懂其含义。比如Safari在150项加速度计测试中仅通过8项。所以呢？这影响到所有网页开发者了吗？笑死。但它在57项无障碍测试中全部通过，这才是真正重要的。
*编辑补充：*别忘了还有Interop 2025测试报告，呈现的是截然不同的画面：https://wpt.fyi/interop-2025?stable
我在2000至2016年从事网页开发及相关工作。IE6的糟糕程度远超Safari任何版本。
该浏览器在众多标准上严重滞后，存在诸多怪癖且漏洞百出，尤其在图片视频处理方面。定位功能也问题频发——近期连固定定位都出现故障，导致iOS端大量网页(包括apple.com)无法正常显示。
我想要Chrome或Firefox那样的扩展生态系统。怀念安卓上真正的Firefox搭配真正的Ublock的日子。
你说谷歌正在封闭的扩展生态系统？现在Safari和Chrome(包括桌面版和iOS版)都能安装相同的UBlock扩展了。
幸好我提到了Firefox。Safari和iOS上的Ublock并非同款。
没错，它与Firefox上仍可使用的版本不同。但你提到“我想要Chrome或Firefox的扩展生态”。我只是指出Chrome的扩展生态已被限制，如今运行的UBlock版本与Safari相同。
幸好我提到了火狐
我发现“自动启用阅读器模式”设置帮助很大
在Safari iOS及其他浏览器上，我每天都会遇到“因问题已重新加载此标签页”的提示。这种情况持续多年，跨设备存在。简直狗屎。Mac版Safari倒是正常。
即便这是个特例，单引擎设计本身就是病态。Safari iOS或许适合你，但不适合我。别拿“这不是苹果的错”“Safari没问题”‘总有一天会修复’“是我操作不当”之类的粉红话术搪塞我——听起来就像在纵容酒鬼的亲戚。无所谓。我理应能因最无谓的理由更换浏览器。或许我就是不喜欢它没把每个网站都渲染成粉色。
这就像世上只存在一种巧克力。这种情况从来就不正常。
这种情况极其罕见。二十年来，无论手机还是电脑，我整天都在大量浏览网页。
我甚至不知道这种事可能发生。
你发现它只出现在特定页面吗？
问题在于苹果还限制Safari功能，让网页应用无法与自家应用生态竞争——比如以安全为名，若应用一周未使用就清除存储空间。若真存在存储压力尚可理解，但若用户使用频率低，就无法获得优质本地体验，只能被迫依赖服务器。
虽然这个借口在今天还成立，但我们不该忘记，十年前正是这项政策将Mozilla拒之门外，使其错失移动浏览器市场的席位。我认为Mozilla衰落的重要原因在于他们执着于Boot2Gecko这个空中楼阁——而这恰恰源于他们无法在iOS上部署Gecko引擎。
Chrome/Safari之所以形成霸权格局，正是因为苹果坚持在其设备平台上所有浏览器都必须基于Safari。加之Android系统多年来搭载WebKit引擎，导致移动端唯一重要的浏览器引擎就是WebKit。虽然Chrome如今采用不同引擎，但它最初是从WebKit分叉而来，且曾保留大量相同的特性。更别提微软转向Blink引擎，正是因为其自主开发的Web应用壳Electron无法在EdgeHTML上运行。
这次变更实质上意味着Chrome取代Safari——但这其实意义不大。它们本质上都是同一代码库的分支。你担忧的单引擎噩梦早已降临。我日常使用Firefox，谷歌在Gecko引擎上故意搞破坏的行为显而易见。比如YouTube标签页每隔几小时就会因垃圾回收卡死，我必须手动终止YouTube进程才能继续观看视频。诸如此类的问题层出不穷。
我认为问题的根源在于谷歌从未被拆分。
一家公司不该垄断谷歌所掌控的一切业务。这赋予了他们在网络领域过多的扭曲激励机制。
我并非赞同现状是明智之举，也非认为现状良好，更非主张维持现状。
我只想说——我们确实身处此境。鉴于此(实质性失误)，我担心这将使局面急剧恶化。
> 我认为不该让单一企业掌控谷歌所涉足的所有领域。这会使其在网络领域获得过多扭曲的激励机制。
当真如此？某些情况下或许如此，但在其他场景中，这种垄断反而能通过内部化外部性完美对齐激励机制。Chrome向高管推销的核心卖点，以及它推出众多优质功能的根本原因，正是整合带来的激励效应——他们有动力投资于提升网站性能的技术(更优秀的Chrome意味着更优质的谷歌/Gmail/YouTube/云端硬盘)。
我们都视其为谷歌，但实情是——他们本质是DoubleClick。
谷歌滋养着DoubleClick，Gmail亦然。YouTube纯粹是广告业务。
云端硬盘/文档等服务，我认为它们推动Chrome发展并削弱竞争对手。
而Chrome？它驱动着谷歌。谷歌同样助力YouTube发展。
所有业务最终都指向广告。
若Chrome不隶属于这家掌控所有业务的广告公司，我倒不会如此担忧。我依然不认同Chrome单一生态的理念，但若它能独立运营，我的警觉性会降低许多。
这番对苹果实力的严苛评价，竟断言其无法凭实力竞争！我绝不认同。苹果的软件有太多深受用户爱戴。
我钟爱Safari。自Mac发布不久购机那天起就一直使用它——那时系统还捆绑着IE 5.5。
我认为苹果根本无法竞争。他们不再为Windows发布Safari(天啊，以前版本糟透了)，这基本断送了他们在桌面端的存在感。
但即便发布了，我的观点是谷歌凭借Chromium项目已掌握压倒性优势，事实上近乎垄断。iOS是苹果仅存的合理规模据点。
这完全源于苹果的政策选择，无论你认为对错。
竞争天平严重倾斜，市场机制已然失灵。
而我们即将见证这场“解放”——本质上是将市场拱手让给谷歌实现完全垄断。
无论我对苹果谷歌当下及过往种种问题的看法如何，我都不喜欢这样的未来。
谷歌在其他领域都如此行事，我看不出他们不会大肆砍掉网页功能的理由。
因为他们自己也在用这些功能？
更何况他们清楚微软当年在IE浏览器上这么干的下场。
微软当时没掌控头号搜索引擎、头号邮箱客户端、头号视频网站、可能还有头号在线办公套件、头号智能手机平台……
当时还能把用户从微软手中挖走。但这次用Chrome恐怕行不通了。
试着告诉别人：放弃Chrome可能意味着放弃所有谷歌服务——因为到那时Chrome将是谷歌唯一支持的浏览器。
看看这论点多么站不住脚。简直和“别帮资本主义了，去森林里住吧”一样荒谬。
届时反垄断诉讼第二轮将打响，若局势如此，我怀疑法官和监管机构对谷歌保留Chrome的态度不会再那么宽容。
我觉得这本该是好事。但……
1. 美国并未这么做。他们虽有案可查却未要求拆分
2. 我们都清楚反垄断诉讼和上诉会拖多久
如果谷歌今年被迫接管网络(姑且这么说)，而苹果被迫允许他们这样做，那么谷歌方面的问题可能要十年以上才能得到解决。
我担心在这段时间里他们能造成多大的破坏。
我认为，在强制iOS允许其他浏览器之前，先解决谷歌对Chrome的所有权问题，比强制iOS允许除谷歌以外的其他浏览器更无害。
我完全支持两者并行推进，但担忧实施顺序可能产生的连锁效应。
此处仅针对浏览器引擎提出异议。切勿将其解读为默许苹果继续其十余年来滥用市场地位的种种荒唐行径。
我认为这可能成立，但前提是保持开源性质(假设指基于Chromium而非Chrome的浏览器)。坦白说，我对开源浏览器形成垄断并无根本异议，因为开源特性意味着若出现问题，随时可以分叉代码开发更优版本。
Firefox已经存在了。
可惜它的用户群基本上就是HN用户
而且它正竭力让这些用户尽快逃离。
Firefox不会再次拯救我们。从某种角度说，它本身就是问题的一部分。
令人惊叹的是，你竟能创办非营利组织开发价值数十亿美元的浏览器，免费提供给大众，允许用户随意修改代码，而HN用户仍会设法将其诠释为邪恶剥削。他们似乎更热衷于抱怨，而非践行所谓的开源理念。
https://en.wikipedia.org/wiki/False_equivalence
HN用户几乎全是谷歌用户
所以你反对霸权却支持霸权？
那些迫使苹果这么做的实体，难道不能同样迫使谷歌采取或放弃某些行为吗？
你认为短期内会发生这种情况吗？
我见过最接近的案例是美国对谷歌的诉讼，但最终未要求拆分。
我不认为欧盟会试图拆解谷歌的所有业务。
虽然日本早有先例，但这条要求引起了我的注意：
苹果自身能满足这个要求吗？WebKit不是C++吗？当然，我不确定所谓“其他语言中提升内存安全的特性”具体指什么，这个表述有些模糊。
https://github.com/WebKit/WebKit/wiki/Safer-CPP-Guidelines
仅靠文档指导开发者安全使用C++就够了吗？
既然如此，任何语言只要提醒开发者谨慎使用就该被允许。
合规性要求往往就是这么运作的。
不清楚他们是否这么做，但这些规范本可通过工具强制执行。
军用飞机里就有C++，他们只是砍掉了90%的功能：https://www.stroustrup.com/JSF-AV-rules.pdf
相关精彩视频：https://youtu.be/Gv4sDL9Ljww?si=Z4riPMKAKcIKaU0s
是的，在WebKit中，SaferCPP规范通过静态分析工具强制执行。
我们公司禁止直接使用new和delete，只允许使用unique_ptr。虽然不如Rust的借用检查器那么安全，但我从未见过段错误。
确实如此，这要求其实很合理。
当然。他们对竞争——我是说替代浏览器引擎施加严苛限制纯属巧合。这些限制他们自己当然无需遵守。
我确信苹果绝不会阻挠他人打破花园围墙。那简直荒谬至极，坦白说，完全不符合苹果风格。
Chrome和Firefox都已合规，所以我认为限制并不严苛。但这份清单的完整语境确实向监管机构和其他浏览器厂商发出极其响亮而明确的“去你的，我们掌控着你们”的宣言。
你认为他们违反了哪些限制？看起来他们完全遵守了自身设定的规则
> 在替代网页浏览器引擎中，至少对处理网页内容的所有代码使用内存安全编程语言，或采用能提升其他语言内存安全性的特性；
后半条要求根本不可能满足。充其量只是无法强制执行。如果我用C++时用std::span代替C风格数组，这样够格吗？
为什么不行？原文表述是“提升内存安全性的特性”。
并未要求必须提供绝对内存安全性。根据链接的WebKit指南，这些特性似乎符合标准。
据我所知，这是评论者的观点，并非来自苹果官网页面。
我的核心观点是：该要求过于宽泛，无法有效落实。
这段文字直接摘自他们的需求说明页面
https://developer.apple.com/support/alternative-browser-engi…
要在iOS上成为浏览器，必须申请明确许可。你不能直接发布应用。我认为该流程要求你必须明确证明已尽最大努力采用最佳安全实践。
再次强调，这并非绝对安全保障，仅是尽职审查机制。
抱歉之前表述不清。我指的是WebKit规范来自评论者而非苹果官网。
> 或至少在替代网页浏览器引擎中，为处理网页内容的所有代码提供增强内存安全性的语言特性；
这根本无法进行实质性分析，不过是苹果限制网页引擎的借口，声称理由是“未充分利用内存安全语言特性”。
苹果自己不链接WebKit文档有何影响？这明明是他们的项目，且似乎符合其要求。
要求中包含许多苹果无法验证的内容，比如资金支持。我觉得你对此过于非黑即白了。
其中部分条款显然旨在要求“证明你们至少考虑过这些安全措施，并已建立实践来最小化已知问题”。再次强调，这绝非追求完美安全的清单——清单中其他条款已涉及更深入的缓解策略。
> 这明明是他们的项目，且似乎符合他们的要求。
这种说法毫无意义。苹果随时可以为自己开特例。
例外是什么？我指的是他们满足了对其他浏览器提出的相同要求。
这正是我开帖时提出的核心问题，而你却陷入“他们无法强制执行”的循环论调，始终未给出实质回应。
你的“实质”无非是“相信苹果能在没有标准答案的情况下正确执行某项规定”。我不同意这种说法。苹果向来擅长为自身利益曲解规则，并以各种理由阻止第三方实现相同功能。
制定规范就该确保其可评估性。当前规范显然做不到。若真重视内存安全，要么要求使用内存安全语言，要么提供明确的参考指南说明如何让XYZ语言满足要求。
苹果对Rust的抵触实在令人费解
真好奇苹果何时会用Swift编写的引擎取代WebKit，或逐步将浏览器引擎迁移至Swift。
苹果至今仍未全球开放平台的做法令人惊讶。在某些国家相对开放运行系统，在另一些国家却设置壁垒，这种做法迟早会因混乱和问题丛生而难以维系。
> 在某些国家相对开放运行系统，在另一些国家却设置壁垒，这种做法迟早会因混乱和问题丛生而难以维系
只要有利可图，他们就会继续这样做。应对多司法管辖区的复杂性正是跨国公司的立身之本——这是加入跨国俱乐部的入场券。苹果必然已为此配备了律师、行政人员和高管团队。
或者直到他们成功“证明”这种做法从一开始就不可行。
> 苹果必然已为此任务配备了律师、行政人员和高管团队。
作为股东兼用户，我真心希望他们能将资源投入功能开发而非制造障碍。
律师、行政人员和高管固然重要，但工程师们如今要维护日益膨胀的模式矩阵，这种复杂性该如何应对？这绝对会成为沉重负担。
关于iOS质量下滑的讨论早已铺天盖地。
坦率地说，近年来苹果在软件质量方面缺乏强有力的外部证据表明其是核心优先事项，因此对可维护性的担忧很可能同样被忽视。
你说得没错，这确实是种负担。但他们凭借寻租特权(尤其在美国——这个他们主导最深且监管最弱的市场)所获取的巨额资金，足以支撑起这套荒谬至极的复杂体系。况且代码崩溃的苦果主要由用户吞下，苹果决策者们可不会为此买单。
50万美元+的年薪让诸多负担都值得承担
他们年收入10亿美元，日利润3亿美元
工程师们声称想攻克难题，转头又抱怨无法解决问题因为太复杂
关键在于这并非本质难题，纯属愚蠢所致。其困难性毫无价值，因为全是人为制造的。
赞同，合规引发的复杂性是编程技能最愚蠢乏味的应用。
听起来像是克劳德该操心的问题
既然牵涉数十亿美元利益，这行当还能长期盈利。
我向来持相同观点。既然他们拥有工程人才，显然技术门槛并不高。但追踪所有跨区域规则，并培训员工和用户遵守这些规则，必然在多个层面(时间、精力、思维模式等)造成巨大成本。
我个人认为，锁定浏览器引擎本身并不会带来多少利润，而完全掌控应用商店则能创造可观收益。
限制浏览器引擎功能是应用商店管控的核心支柱。完善的PWA支持将对苹果利润构成重大打击。
Chrome在安卓系统上的PWA支持是否对安卓应用商店利润构成重大威胁？
我不认同“Safari被刻意削弱以支撑应用商店”的说法。iOS究竟缺什么，导致PWA无法成为企业的盈利利器？既然涉及巨额利益，理应有企业采用。Match.com的约会应用组合为何必须依赖网站而非PWA？
实际上，当你真正关注苹果的软件工程实践时，就会发现他们极其吝啬。所有应用都严重资金不足且开发滞后。原生平台处处存在漏洞却长期无人修复。
> Chrome在安卓系统对PWA的支持是否大幅提升了安卓应用商店的利润？
可能如此，但安卓允许旁加载，iOS则不支持。
> iOS究竟缺什么才能让PWA成为企业的盈利利器？
做好心理准备。
1. 通知功能严重受限。这点至关重要。静默推送、富媒体通知、通知服务扩展、可靠的徽章计数和推送成功率。更糟的是：
2. 后台运行权限受限。PWA会被频繁挂起和终止。无法维持长期进程，进程执行无法保证。IndexedDB和内存状态随时可能被清除。
3. PWA无法访问多数系统框架：蓝牙(CoreBluetooth)、NFC(Core NFC)、后台定位追踪、HealthKit、HomeKit、CallKit/VoIP、Siri快捷指令/应用意图、AirDrop、Apple Pay(完整API)、CarPlay、系统共享扩展。
4. 无法访问原生渲染管道，性能严重受限。
5. PWA内存不稳定且可被清除，无持久化文件存储。
6. 用户体验与生命周期控制受限：无终止回调，无暂停通知，页面可被任意重载，前后手势与浏览器冲突。
7. 无法访问原生UI组件：FaceID、原生文本框、跨应用拖放、上下文菜单及触觉反馈。
苹果已竭尽所能确保PWA在iOS上无法正常运行。
不仅如此，苹果每年还因Safari默认搜索引擎身份从谷歌获得逾200亿美元AdSense收入。即便市场份额仅下降10%，苹果就将损失数十亿美元，而这笔收入纯属利润。
https://www.cnbc.com/2023/11/14/google-pays-apple-36percent-…
这是阴谋论版本。
更合理的解释是：当每个应用都能捆绑自有浏览器引擎时，竞争不会激增。相反，电子应用将登陆移动端，每个应用都自带浏览器栈。
别跟我说Gecko——这个在桌面端已失败的引擎——会在移动端突然流行起来。但你完全可以预见，每个应用自带Chromium内核的方案将深受开发者欢迎。
如今Firefox在安卓平台表现卓越，已成为我日常使用的首选浏览器。它仅需完整插件支持——当这项功能最终实现时，体验便变得完美无缺。
这确实如此，但我认为应用商店应制定规则：若要发布浏览器引擎，必须是真正的浏览器——即拥有在MacOS、Linux和/或Windows平台上维护的浏览器，且能在这些平台上被设为默认浏览器。或者更简单地说，其核心功能必须是为用户提供网页浏览服务，而非次要地用于访问内容/购物/游戏。
无论采用哪种标准，Slack、亚马逊应用等程序都将无法发布其过时的900MB Chromium版本，但Chrome、Firefox、K-Meleon等浏览器则不受限制。
浏览器本质上是免收苹果30%分成费的应用商店。只要能发布浏览器，就无需缴纳苹果税
PWA在安卓或Windows这类无限制平台上普及了吗？
没有。
即便在iOS上不受限制，PWA仍会失败，因为这项技术本身就令人困惑。对非技术用户的推广效果极差，就像同样糟糕的通行密钥技术。
是的，PWA在这些平台上已广受欢迎。我在微软负责Microsoft Store(Windows应用商店)工作，同时与Edge团队协作，并运营PWABuilder.com——该平台将PWA发布至应用商店。微软应用商店中最受欢迎的应用中，Netflix、TikTok、Adobe Creative Cloud、Disney+等众多应用都是PWA。
要在Windows设备上查看商店中的PWA列表，可运行以下地址：
ms-windows-store://assoc/?Tags=AppExtension-microsoft.store.edgePWA
我同时运营PWABuilder.com，可以确认大量PWA应用发布在Google Play商店，其中不乏热门应用。
我认同当前PWA安装流程存在混淆。谷歌和微软正联合推动相关网络标准以解决此问题，例如Web Install规范：https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/…
>PWA在安卓或Windows这类无限制平台上普及了吗？没有。
显然如此。当主要守门人系统性地阻挠其发展以防止其挑战其税收渠道时，PWA就失去了竞争机会，因此在竞争平台上也不会被采用，这将阻碍其普及和任何相关投资。
>即便在iOS上不受限制，PWA仍会失败，因为这项技术本质上令人困惑。
PWA并非“本质上令人困惑的技术”，未经充分论证就做出如此荒谬的断言，充斥着纯粹的偏见。
其实并不复杂。对用户而言，它可能与应用程序无异——只是无需下载即可即时“安装”，且不占用设备空间。
若苹果没有阻碍PWA使用的动机，本可像提示安装/打开App Store应用那样，通过顶部横幅让用户“安装”PWA。但苹果却将其藏在Safari分享菜单的深层选项里。
据我所知，目前并未禁止应用自带Chromium引擎，只是不允许在WebView中使用自有引擎。
技术上你甚至可以编写自己的WebView，但无法将其设为默认，也无法实现JavaScript即时编译(JIT)，因为这需要苹果从未授予的权限。缺乏JIT功能将严重损害性能和电池续航。
https://www.macobserver.com/news/15-months-later-iphone-user…
>这是阴谋论版本。
凡是与您偏好的叙事相悖的事实，皆可轻描淡写地归为阴谋论——这让世界变得多简单，不是吗？我整理了部分证据，清晰揭示了守门人之一(苹果)如何存在巨大利益冲突，这种冲突多年来以系统性破坏PWA的形式显现：https://news.ycombinator.com/item?id=45534316
很好。我越早能在Firefox上运行正版uBlock Origin越好。
虽然不是火狐，但你可以用Kagi团队开发的Orion浏览器运行uBlock Origin。
我目前就是这么做的——勉强能用。相信最终会完善，但它漏掉了桌面版能拦截的大量内容。
我在iOS版Safari用1Blocker，有什么问题吗？
我用wipr效果超棒，视频广告拦截还搭配醋和小苏打。
正确且完全拦截广告和追踪器。即便你看不见其中大部分，网络请求仍在持续发送。你并未获得免费开源的扩展程序，每月钱包里也不会多出3美元——因为那些骗子让你为几个像素付费，却未曾为广告拦截列表贡献一分力，而他们的“生意”正依赖于此。
什么意思？1Blocker能拦截网络请求啊。
它或许没uBlock Origin那么彻底，但确实能拦截网络请求。
我指的就是那些漏网之鱼。
既然话题已展开，为何Orion浏览器能在App Store上架而其他浏览器不能？
能否在此领域进行更多创新？比如开发扩展程序增加权限支持，或基于Orion技术进行分叉开发，最终实现苹果iPhone支持PWA？
App Store上的浏览器虽多，但都必须基于iOS内置的两大浏览引擎之一。
不，你没明白我的意思——iPhone上所有浏览器(包括火狐和Chrome)都是WebKit的分支版本
且均不支持任何扩展程序
据我所知，Orion是唯一仍兼容火狐/Chrome扩展的浏览器。我确信它能支持PWA(或已支持)，但不确定具体情况，建议有人实际测试验证。
理论上，若能对引擎进行深度改造，使其能在Firefox/Chrome原生版本无法支持的情况下运行扩展程序——而Orion却能实现——我实在想不出为何其他浏览器不这么做。更何况它还结合了极其出色的PWA支持？
你似乎没搞懂原理。iOS浏览器下载后根本不包含引擎——连“WebKit分支”都没有。这些浏览器只是iOS系统内置引擎的UI包装层，对引擎本身完全无法修改，因为它属于操作系统核心组件。
抱歉，我确实没有iPhone，刚才只是凭直觉猜测。
我很乐意就此展开讨论，了解Orion的具体实现机制。
我想问的是：Orion如何能在WebKit环境下运行Firefox/Chromium扩展？因为我知道Orion核心本身基于WebKit构建，但好奇他们做了哪些额外改造才能实现iOS平台运行Firefox扩展等功能。
能否详细说明实现原理？我看不出其他方案能做到这一点。具体而言，在iOS系统中引擎已打包的情况下，他们如何实现扩展功能？
另想请教：是否意味着我能直接从Firefox/Mozilla扩展商店获取任意扩展并在Orion中使用？这是否类似于零限制的应用商店？毕竟Firefox扩展通常限制极少，且与PWA特性相似(不确定)。
既然Orion已实现这些功能，为何该领域没有更多创新？我期待看到开源替代方案，比如为iPhone开发的Orion替代品。
感谢告知浏览器在iOS中运行于操作系统层级，但能否解释Orion如何实现这些功能？那么在PWA支持、类似Orion的扩展支持等方面，是否还能有更多突破？
Firefox/Chromium的扩展API本质上就是JavaScript。Orion通过Webkit/JavascriptCore提供的功能重新实现了这些API。
哦，明白了，感谢说明。
PWA功能真的毫无实现可能吗？iOS上阻碍PWA发展的因素是什么？我实在不太明白。若能澄清我的困惑就太好了。
“PWA”具体指什么？iOS缺少哪些API或功能？
Orion的设计初衷就是基于WebKit。
FeatureToggles.swift
eligibilityd
https://theapplewiki.com/wiki/Eligibility
正是如此。这是计算层面的问题。计算本身并不真正“理解”地缘政治边界。
我实在受够了全球不同地区应用商店产品差异的日益扩大。每次推送更新(大约每月一次)，我都得回答更新后的问题和声明，这些内容往往针对不同地区而异。
这是个考虑不周的论点，因为根本没有任何东西能“理解”地缘政治边界。
你显然不理解苹果的固执。他们最讨厌被人指手画脚。
虽然日本市场的协调进展远超欧盟，但苹果对此仍不满意。所以他们绝不会对所有人俯首帖耳。
苹果公司正刻意制造用户体验障碍，企图引发公众向相关机构抱怨“监管过度，应放手让苹果自主发展”——这正是他们近年来在欧洲大力推动的论调。
苹果似乎正在使用其在欧盟“允许”第三方浏览器引擎时自创的规则。值得指出的是，这些限制如此严苛，据我所知，尽管允许第三方浏览器引擎进入欧盟应用商店已逾一年，至今仍无任何浏览器搭载替代引擎成功上架。
要求搭载替代浏览器引擎的应用必须与现有内置浏览器应用完全分离——这使得Chrome等巨头面临困境：在过渡期需同时维护两个应用，据称这已是他们在欧盟遭遇的最大障碍之一。
欧盟的另一道门槛是浏览器应用开发商必须位于欧盟境内。
我曾期待日本和欧盟出台的法规能促使企业看清形势，在全球范围内改变做法——哪怕仅出于成本考量(维护多套规则体系显然更昂贵)。然而这些巨头如今体量庞大，完全能选择在各国层面吸收效率损失。
硬件层面似乎奏效了。以iPhone的USB-C接口为例。
软件层面？彻底失败。欧洲经济区用户可在Windows 11中禁用“开始搜索”功能，其他地区用户却无法实现。有趣的是，系统安装时根据用户选择自动判定欧洲经济区成员身份，且此后无法更改。
而iPhone则运行着一个守护进程持续检测用户位置——该检测并非基于手机初始设置地点。因此从欧洲前往其他地区时，用户可能无法更新通过第三方应用商店获取的应用：
https://www.macrumors.com/2024/03/06/alternative-ios-app-sto…
是的，软件领域不幸的是，通过设置足够精细的功能开关，他们能让软件在每个特定区域达到“最差体验”。在欧盟输掉一场官司被迫改进软件？他们只会针对欧盟优化。在日本因其他问题再败一场？只需设置“日本”标记，仅针对该地区特定使用场景进行微幅优化。若在其他地区再败，就继续添加新标记。
只要有机会将优化代码限制在特定区域，他们绝不会在全球范围部署“更优”功能。
1：当然，我所说的“更优”始终指“对用户更优”而非“对苹果更优”。
即便在硬件层面，这种差异化设计也易于实现，苹果早已如此操作。
中国版iPhone？配备两个物理SIM卡槽，无eSIM功能。
欧盟版iPhone？一个SIM卡槽加一个eSIM。
美国版iPhone？两个eSIM卡槽，无物理SIM卡槽。美国版还搭载了其他国家没有的毫米波技术。
若苹果有意为之，保留Lightning接口的美国版iPhone完全可行。欧盟在美国市场施压的作用被夸大了。
我父亲在为期一个月的旅行首日就遭遇手机失窃。整个旅程他都无法使用手机，部分原因在于担心携带欧洲手机回国后无法匹配当地通信频段。
确实存在差异。虽然仍能使用，但频段并不完全匹配，因此可能因网络不同导致覆盖问题。
你的观点很有道理。不过我猜苹果开发新硬件配置的成本，要比添加软件功能标记高出几个数量级。但假设全球范围硬件变更的成本超过工厂改造新硬件的成本，你说的没错——他们确实不会选择全球同步硬件变更。
几乎可以肯定有人(或整个团队)经过精确测算后，刻意决定不再保留美国版Lightning接口iPhone。
这些配置存在不同层次。不同机型间SIM卡槽数量或支持频段的差异并不罕见。普通用户只需设备能正常使用即可。事实上，SIM卡与频段配置的差异与地区性法律最低标准无关——它们更多取决于各区域的行业惯例和可用系统(例如毫米波技术在美国以外地区尚未广泛部署)。这些配置差异并非像限制浏览器访问那样“更差”。手机地区版本的存在由来已久，其原因相当普通且无害。
更重要的是，当用户跨区域旅行时，只要抵达地能正常使用手机，频段略有偏差或SIM卡配置不同根本无关紧要。设备与当地版本存在细微差异并非实质问题。
但充电器还要因地区而异？这简直是灾难的根源。这不仅增加了外壳设计的复杂度，更影响日常使用体验。当美国用户前往法国(或反之)时，若想购买充电器或与他人共享设备，同型号iPhone竟无法兼容，这将引发极大困扰。为每个市场单独设计Lightning和USB-C双版本设备显然愚不可及。
苹果钟爱USB-C接口，他们参与了该标准的制定，并率先推出仅支持USB-C接口的笔记本电脑
苹果承诺为Lightning接口提供十年支持，以平息放弃30针接口引发的争议
无论欧盟是否要求，iPhone采用USB-C接口已是必然趋势。
iPhone采用USB-C实属必然。要知道早在欧盟立法前，iPad系列就已使用USB-C接口多年。
欧盟能说的最好听的，就是这项法规将不可避免的变革提前了一两年。
听起来像是为法拉第GPS欺骗盒创造了市场。
我们还在玩《精灵宝可梦GO》吗？
若法规强制企业移除现有功能(如追踪透明度弹窗)，你怎么看？已有两个国家的法院因苹果强制弹窗警告用户第三方应用追踪行为(该功能苹果自身并未使用)而对其处以罚款。
我原以为苹果会全球性移除该功能，但本帖其他讨论表明：软件层面的分阶段削减对大型企业而言是可承受的成本。
苹果诸多举措确实存在反竞争动机，但浏览器引擎似乎不在此列。其初衷确系出于安全、续航与标准化考量。既然成本从未是决策根源，成本自然也不会成为改变的理由。
此举实为战略布局，旨在扼杀网络创新，确保网页应用技术无法发展到威胁原生应用及应用商店主导地位的程度。
任何持相反观点者都天真得无可救药——史蒂夫·乔布斯本人曾将网页应用视为技术未来，直到苹果发现应用商店这座金矿。
> 扼杀网络创新
我认为这是假设性论断，并非现实。Safari始终是完全现代化的浏览器。虽然新功能发布速度不及Chrome，但通常会逐步接纳。
若苹果真要“扼杀网络创新”，Safari的功能集将呈现截然不同的面貌。但事实并非如此。
正如我所言，苹果确实存在诸多反竞争行为。我并非对应用商店的操作视而不见。只是我不认为单一浏览器引擎政策源于此动机，或对竞争格局产生显著影响——毕竟苹果始终在持续维护Safari作为现代浏览器的定位。
这绝对是现实。Safari毫无疑问是最差劲的浏览器，其体验常被拿来与微软旧版IE浏览器相提并论。不必轻信我的评价，众多评论已对此有过详尽论述…
https://www.google.com/search?q=safari+is+the+new+ie
苹果故意不开放许多仅限原生应用使用的API(其他浏览器都实现了这些功能)，其目的就是迫使开发者创建原生应用才能使用这些API，从而让苹果能够强制开发者上交通过应用产生的消费额的分成。他们无法强制开发者分摊通过网页浏览器产生的购买分成，因此刻意削弱Safari浏览器引擎性能，同时强制所有其他浏览器使用该引擎。若你仍看不清这种做法的恶劣性，说明你已被现实扭曲场蒙蔽了双眼。
美国司法部起诉苹果的文件中对此有明确阐述，其中还列举了其他诸多反竞争行为。
微软因将IE浏览器捆绑Windows系统而遭反垄断诉讼败诉。苹果同样将Safari捆绑iOS系统，却禁止任何非Safari引擎的浏览器运行。试想若微软禁止其他浏览器安装在Windows系统上会如何？苹果滥用市场支配地位的反竞争行为，是时候接受法律审判了。
以下是司法部起诉苹果的完整文件：
https://www.justice.gov/archives/opa/media/1344546/dl?inline
我怀疑这可能源于反垄断担忧，但Safari其实没那么糟糕。看看Interop 2025大会：https://wpt.fyi/interop-2025
其功能通常相当完善。支持WebGPU，支持PWA安装后的网页通知API，功能相当丰富。我主要不满的是PWA安装流程过于复杂，但相关API至今仍未正式推出。(或许要等到2027年？[0])
> 苹果故意拒绝实现许多仅限原生应用使用的API(其他浏览器均已支持)
能否举例说明？
[0]: https://blogs.windows.com/msedgedev/2025/11/24/the-web-insta…
Safari绝对是最糟糕的浏览器，尤其在iOS平台。苹果还坚持自成体系，无视行业标准，导致我必须实际持有iPhone才能调试其平台特有的问题，特别是触控交互相关的缺陷。
>能否举例说明？
Web蓝牙API及其他众多功能。我们的产品本可使用蓝牙，却被迫绕过苹果Safari的限制改用WiFi，导致电池消耗更快。我们不愿为iOS单独开发应用(这需要投入资金开发和维护)，否则苹果还会通过应用抽成来勒索我们。蓝牙本是更优方案，但Wi-Fi虽操作繁琐仍可使用。所以苹果粉丝们抱歉了，你们必须用Wi-Fi连接我们的产品——这都是苹果的“合理”要求。
等美国司法部终于迫使苹果开放iOS浏览器限制时，我定要开瓶香槟庆祝。
https://www.justice.gov/archives/opa/media/1344546/dl?inline
个人感觉Safari至少不再是死水一潭，确实推出了一些新功能。比两年前强多了，四年前简直是场灾难。
但各种怪癖依然存在，让Safari根本无法正常使用。若不安装PWA，存储空间会以惊人速度被清空。即便安装了PWA，存储空间依然会以惊人速度被清空。通知功能存在严重不可靠的投递问题，且必须安装PWA才能正常工作。虽然功能上已比以往更趋近于标准，但基础功能仍遭受严重破坏。苹果宣称“用户安全无虞”实属令人惊叹的双重话术(其隐含的第二层含义是：用户被牢牢困在苹果的生态圈里无处可逃)。
值得注意的是，互操作性会议参与者每年通过全体一致同意的方式决定工作方向。若苹果缺席会议且拒绝达成任何合作共识，针对其反垄断诉讼的证据链将更具说服力。恕我戴上锡箔帽说句实话：出席会议也赋予苹果某种话语权，使其能影响哪些功能不被纳入开发计划。
不，这根本不是事实。
Interop 2025仅涵盖部分网页功能，但苹果对每轮纳入的功能拥有否决权且频繁行使。这无法反映普遍的互操作性状况。Safari每年起步时表现最差，改进速度也最慢。
他们对通知功能的实现存在缺陷，仅部分网站能正常工作——即便这些网站在Chrome、Firefox甚至小众浏览器上运行完美。即使将网站添加到主屏幕也无济于事。
>> 苹果故意拒绝实现大量仅限原生应用使用的API(其他浏览器均已支持)
>能否举例说明？
Web蓝牙、Web USB、Web NFC、Web串行端口…
当然，苹果会照例上演那套说辞，声称这是为了维护隐私与安全，从而保持可否认性。他们完全可以轻松实现该功能，并默认将其禁用，让用户自主选择启用或保持禁用状态。任何对苹果行为动机的充分分析都必须提及苹果的利益冲突，因为苹果必然会排斥那些可能削弱“原生”应用价值的技术——多年来苹果对原生应用征收的税费从未受到挑战。
> Web蓝牙、Web USB、Web NFC、Web串行接口
仅限Chrome的非标准方案。需注意Firefox同样反对这些方案。
> 任何对苹果行为与动机的充分分析都必须提及苹果的利益冲突
我尚未见过任何充分分析能摆脱这种假设：Chrome推出的任何功能——抱歉，是发布的任何功能——都立即成为必须被所有人立即实现的标准。
你说的没错，Firefox确实反对某些具体实现方案，而谷歌也常仓促推出功能。但这丝毫不会削弱苹果的利益冲突本质——有时他们的论点恰巧与现实吻合，就像坏钟一天也会准两次。苹果采用诸多双重标准：例如允许原生应用访问硬件功能(此时恰好收取30%分成)，却禁止网页应用实现同等功能(此时分文不取)。若隐私是唯一考量，他们本应致力于制定安全标准，但实际却彻底封锁该功能，确保应用商店的竞争对手始终受限且处于劣势，从而保障应用商店的收入不受威胁。
> 你说得对，Firefox也反对当前某些具体实现方案，而谷歌确实常仓促推出功能。但这丝毫不能削弱苹果的利益冲突本质。
有趣的是，你既认同Firefox反对这些非标准方案，也承认谷歌行事仓促，却立刻转而声称“不不不，问题出在苹果身上，Safari(以及由此延伸的Firefox)必须绝对支持Chrome的这些非标准功能”。
其余煽动性言论皆无关紧要。
顺带一提，当火狐最终妥协并实现其曾反对的WebMIDI时，他们立刻遭遇了利用WebMIDI进行的追踪/指纹识别企图——而Chrome对此根本毫不在意。
>有趣的是，你既认同火狐反对这些非标准规范，又指责谷歌行事仓促。转头却又说“不不不，苹果才该负责，Safari(以及Firefox)必须照搬Chrome的非标准功能”。
我承认事实有何可笑？这本是理性之人的应有态度，你试试看。真正可笑的是你如此篡改歪曲我的论点。我从未主张“必须实现Chrome的非标准功能”，而是提出更细致的论点：苹果的利益冲突促使他们拒绝采用竞争技术整套功能，而非协助制定安全标准，这暴露了其恶意动机。这种反竞争策略对苹果至关重要——通过系统性扼杀潜在竞争者，使其在萌芽阶段便无法成长，从而为苹果攫取数十亿应用税创造了条件。
>顺带一提，当火狐最终妥协并实现其曾反对的WebMIDI时，他们立刻遭遇了利用该协议进行追踪/指纹识别的攻击——而Chrome对此根本毫不在意。
那又如何？正如原生应用赋予用户某些可能存在弊端的自由，网络应用也应享有_平等权利_，在公平的竞技场上竞争。选择权和自由权应属于用户，而非苹果的财务部门。这些都不能赋予苹果用企业双重话术维护其反竞争策略的权利。而你如此专注于细节却未能把握更广泛的论点，从而为苹果的反竞争行为摇旗呐喊，这暴露了明显的偏见。
> 苹果的利益冲突正驱使他们拒绝采用竞争技术的完整功能集，而非协助制定安全标准
这简直就是“所有人必须立即照搬Chrome推出的任何功能”。你甚至不愿承认Safari和Firefox团队基于相同理由共同拒绝了这一前提。
不，是“他们必须为Chrome推出的这些功能制定更完善的标准”。
> 选择权和自由度应属于用户，而非苹果财务部门。
有趣的是，在你回应的段落里我根本没提过苹果。
而你如此过度关注细节，却未能把握更广泛的论点
根本不存在更广泛的论点。你直接将Firefox斥为无关紧要[1]，认定Chrome推出的任何功能都是好的，还假设苹果既是完全受金钱驱动的恶劣行为者，又必须照搬Chrome的任何方案(打着“应致力于实现安全标准”的幌子)。
[1] 他们对这些Chrome功能的立场与苹果完全一致https://mozilla.github.io/standards-positions/
>这根本就是“所有人必须立即照搬Chrome的任何垃圾方案”。你甚至不承认Safari和Firefox团队基于相同理由全盘否决该前提的事实。
这既不符合事实，更谈不上“根本就是”。我已明确指出问题不在于拒绝当前具体实现方案，而在于全面抵制功能以剥夺竞争技术平等权利，而非协助制定安全标准。这正是苹果怀有恶意动机——为维护其应用商店抽成渠道而扼杀竞争技术的证据。你始终拒绝理解这一点，转而歪曲事实转移视线。
>不存在更广泛的论点。
有，正是你刻意回避和转移注意力的那个论点，因为它彻底驳斥了你的偏颇论调。
>你直接将火狐浏览器视为无关紧要[1][1]其实火狐对这些Chrome功能的立场与苹果完全一致https://mozilla.github.io/standards-positions/
我没有。你纯属无中生有，还刻意忽略我回应开头就承认了这点：“你说的没错，Firefox当前版本也反对某些具体实现方案，谷歌确实常仓促推出功能。但这丝毫不会削弱苹果的利益冲突问题，有时他们的论点恰巧符合现实，就像坏掉的钟一天也会准两次。” " https://news.ycombinator.com/item?id=46457938
>并断言苹果既是唯利是图的恶劣行为者，又必须照搬Chrome的所有方案
根本不存在这种假设，事实是苹果存在利益冲突，这种冲突表现为反竞争行为——我已提供书面证据佐证。我从未声称苹果“必须采纳Chrome的所有方案”，这是严重的歪曲，尽管我已多次驳斥，你仍固执地重复这种谬论。你在此事上的偏见再明显不过，只因你执意歪曲任何反驳苹果宣传叙事的证据，所以面对相反证据仍盲目重复那些陈词滥调。
> 你纯属无中生有，还刻意忽略我回应开头已承认该事实： "你说的没错，Firefox当前版本也反对某些具体实现方案，谷歌也常仓促推出功能。但这丝毫不能削弱苹果的利益冲突问题
经验法则是’但’字之前的话都不重要。苹果反对Chrome功能的立场不仅得到Mozilla呼应，更是被几乎原封不动地复述。
然而你完全无视这些事实，转而宣称’苹果既存在利益冲突又行为恶劣，因此必须为这些功能制定更安全的标准’。你甚至未曾设想过三大浏览器厂商中有两家出于相同原因反对这些功能的可能性。不，既然Chrome已推出这些功能，苹果就必须(以某种形式)实现它们——只因苹果’行为恶劣’之类的理由。
> 根本不存在这种假设，
“拒绝功能以剥夺竞争技术平等权利，而非协助制定安全标准。”没错。“无论代价多大、理由如何，Chrome推出的功能都必须被实现。”
> 仅因苹果存在利益冲突，并表现为反竞争行为
这与Chrome专属的非标准功能毫无关联。Chrome需要这些功能。但安全设计与实现的责任在Chrome方。无论决策引发多少煽动性言论，苹果和Mozilla都不欠Chrome任何义务。苹果与Safari在多次讨论中都指出了相关问题，Chrome却置若罔闻。
Safari确实存在诸多问题，但这些问题绝非源于拒绝支持Chrome向世界倾倒的那些垃圾功能——那些被Chrome冠以“标准”之名的玩意儿。
说到“剥夺竞争技术平等权利”。你知道WebSQL曾由Chrome实现并获得Safari认可，却因Mozilla反对而夭折吗？Mozilla是在“剥夺竞争技术平等权利”吗？或者，或许，他们只是基于合理担忧促使技术方案重新审视？
除了“但原生应用”和对苹果的抨击外，你甚至无法对Mozilla和苹果的担忧提出有力的反驳(你压根就不了解他们的担忧)。
顺便一提，Mozilla在某硬件API上已作出让步：https://news.ycombinator.com/item?id=33995022(可惜该推特账号已被锁定)/ 原文引述： “在Firefox Nightly版本实现该功能仅一天后，就发现了首个WebMIDI指纹识别案例…顺便说一句，Chrome至今仍允许网页开发者在未经用户同意甚至未作通知的情况下枚举已连接的MIDI设备。”
>经验法则是“但书前的论述皆不重要”。苹果反对Chrome功能的立场不仅得到Mozilla呼应，更被几乎原封不动地复述。然而你完全无视这些事实，转而宣称“苹果居心不良且存在利益冲突，因此必然致力于制定更安全的标准”。你甚至没花一秒钟思考过：三大浏览器厂商中有两家反对这些功能，可能出于相同原因。不，既然Chrome实现了这些功能，他们就必须(以某种形式)跟进——全因苹果太坏之类的理由。
你像个无法处理新信息的机器人般不断重复相同论点，完全不理解这些论点已被多次驳斥，这种行为简直荒谬至极。你执意将细致的论点扭曲成粗暴的歪曲，只因这能维持你的幻觉——仿佛你那些阴险的苹果宣传，不是在粉饰苹果每项决策背后都存在的利益冲突。
>这与Chrome专属非标准毫无关联。Chrome主动要求这些标准，其安全设计与实施责任在Chrome自身。无论决策引发多少煽动性言论，苹果和Mozilla都不欠Chrome任何东西。苹果和Safari在多次讨论中都指出了相关问题，Chrome却置若罔闻。
你对这件事的框架设定荒谬至极，是你把技术讨论扭曲成某种团队对抗——试图通过假装这是谷歌对阵苹果/Mozilla来抬高论调，而事实证明Mozilla接受了提案的新版本，这点你自己都承认过！这彻底推翻了你的虚假叙事——事实证明，Mozilla对当前方案的暂缓采纳绝非永恒拒绝，这与苹果的动机截然不同。苹果并非出于(伪)隐私考量，而是害怕失去应用商店的统治地位和收入来源。然而你却暗中借此炮制反竞争的苹果辩护论，通过编造“谷歌对阵A&M”的剧本来淡化苹果的利益冲突。
>Safari确实存在诸多问题，但这些问题绝非源于拒绝支持Chrome向世界倾倒的那些垃圾标准。
错。你甚至懒得对此论点展开论证，因为一旦展开就会暴露你的说法不仅错误，更是赤裸裸的欺骗。你偏颇肤浅的言辞无法替代实质论证。
>说到“剥夺竞争技术平等权利”。你可知WebSQL由Chrome实现并获Safari认可，却因Mozilla反对而夭折？莫非Mozilla“剥夺了竞争技术平等权利”？抑或——或许——他们提出合理质疑促使方案重构？
这纯属无关紧要的误导。并非每个功能都直接关系到竞争技术平等权的建立，但当苹果意识到某项功能可能威胁其应用商店的霸权时，他们就会采取相应行动。这些事实既未削弱苹果的利益冲突，反而暴露了你如何持续以恶意论调淡化苹果的利益冲突。无论你如何努力，终将徒劳。苹果从利益冲突中赚取数十亿美元，只要这种冲突存在，人们就有权揭露它如何毒化苹果在相关决策中的动机。
>你甚至无法对Mozilla和苹果的担忧提出合理反驳(你压根不清楚他们的担忧所在)，除了“但原生应用”和对苹果的抨击之外。
你的论调如此空洞脱离现实，简直像在和一个失去上下文理解能力的LLM机器人争论，它完全忘记我早已反复驳斥过那个特定论点。你自己也承认过，Mozilla最初拒绝过某些具体方案，后来却又接受了。仅此一点就足以推翻你整个偏颇的叙事。你整套说辞不过是不断重复那套陈词滥调，却始终无法跳出固有框架，完全无力消化那些已然推翻论点的证据——正因如此，你才未能意识到自己鼓吹苹果的宣传是多么空洞且误入歧途。
>顺便一提，这里是Mozilla在某硬件API上让步的实例：https://news.ycombinator.com/item?id=33995022(可惜该推特账号已被锁定)/ 原文引述： “Firefox Nightly刚发布实现方案次日，就发现了首个WebMIDI指纹识别案例…顺便说，Chrome至今仍允许开发者在未经用户同意甚至未作提示的情况下枚举连接的MIDI设备。”
太神奇了，这正是我上面提到的情况。我发誓，你简直像个机器人，无论自己的论点被驳斥多少次，都固执地不断重复那些已被证伪的观点。最后，你甚至没意识到自己热情分享的那个案例和先例——以为能佐证你的论点——实际上却在削弱并否定它。真棒。
这根本就是“所有人必须立即停止任何损害苹果利润的行为”
苹果如今对网络标准拥有否决权。若他们不滥用权力，也不禁止其他浏览器引擎登陆iOS，本不会有问题。他们滥用权力伤害除苹果外的所有人，司法部已注意到这一点。
你说Firefox未实现苹果拒绝的API作为论据，但Opera等浏览器确实实现了这些API，这完全推翻了你的论点。
当年微软发明XMLHTTPRequest时，若苹果当时就掌控网络标准话语权，假设性而言，网络可能至今仍停留在“Web 1.0”阶段。
但如今苹果能阻碍浏览器技术进步，司法部很可能证明其滥用市场地位损害所有网民利益——只为让应用商店多赚几美元。
这道理本不该如此难以理解。
Chrome的功能是否实用？是否开放？若对用户有害(例如新增广告追踪功能)，或因专有技术导致授权成本高昂、难以逆向工程，那另当别论。但若非如此，苹果始终拒绝采用这些标准(或提供替代方案)，要么是愚蠢的“非我发明症”作祟，要么就是贪婪使然。
> 若对用户不利(例如新增广告追踪功能)
是
> 但若非如此，那么拒绝采纳这些标准(或提供替代方案)的行为，要么是苹果愚蠢的“非我发明症”作祟，要么就是贪婪使然。
需注意火狐浏览器对这些Chrome专属功能的立场与苹果完全一致：https://mozilla.github.io/standards-positions/
火狐浏览器从谷歌获得巨额资金支持。或许协议中包含不实现某些功能的条款，因为这会与Chrome形成竞争。我并不清楚具体情况，也不在乎Firefox做了什么或没做什么。我只在乎苹果不允许其他浏览器使用自己的浏览器引擎。Opera移动版同样实现了我需要的API(在Android平台)。就连微软Edge都支持这些API。Firefox若要效仿苹果变得无能，我也不在乎。
“任何不遵从谷歌指令的浏览器，背后必定存在恶意势力操纵——这种阴谋论论调除了锡箔纸阴谋论外我实在难以形容”，这种论调远不如你想象中站得住脚
我真的不在乎浏览器实现什么功能。我只在乎苹果禁止其他浏览器在iOS上使用自有引擎。仅此而已，而这已引起司法部注意——这也是苹果遭司法部起诉的众多原因之一。
只要苹果不允许其他浏览器引擎登陆iOS，他们就如同贪婪的暴君。
> 我真的不在乎浏览器实现什么功能或不实现什么功能。
哦，你当然在乎。在乎到为火狐浏览器专门制定合同条款。
只是非常遗憾，Safari如今陷入进退两难的境地(完全是苹果自找的)，毕竟它本是唯一能抵御“Chrome吐出什么就是新标准”的知名网页引擎。
>> 我真的不在乎浏览器实现什么功能或不实现什么功能。哦，你当然在乎。你甚至为火狐浏览器专门制定了合同条款。
你竟如此固执地坚持令人厌烦的立场，拒绝理解他人提出的最显而易见的论点，实在令人难以置信。你不能仅仅抽离他论述中的某一句子来解读。关键在于，他不在乎浏览器是否实现特定功能，这与要求苹果停止反竞争商业行为密切相关——苹果的错误决策本应仅影响Safari浏览器，而非阻碍整个网络的发展。
>Safari如今陷入进退两难的境地(纯粹是苹果自找的)实在令人遗憾，毕竟它本是唯一能抵御“Chrome吐出什么就是新标准”的知名网页引擎。
这读起来像苹果付费发布的#广告，试图将他们的敌对行为包装成可怜的苹果与谷歌进行“英勇”斗争。但现实是苹果纯粹基于利益冲突行事，请别再兜售这种粉饰苹果的叙事。苹果是资本主义社会中的企业，其存在意义无非是最大化股东价值。你现在不在r/apple版块，别忘了。
你是指像你这样的恶意分子吧？明知铁证如山且苹果自身记录都证实了利益冲突，却执意抹黑批评者为“阴谋论者”来粉饰苹果？你为苹果反竞争商业行为辩护的欺骗性言论，远不如你自以为的那般有说服力。
> 你指的是像你这样的恶意行为者
够了。你违反了HN社区准则。此处禁止人身攻击。
https://news.ycombinator.com/newsguidelines.html
没错，够了otterley。你违反了HN社区准则。此处禁止使用马甲账号。
你和你的第三方苹果公关同事也需要降低协同行动的明显度(包括时机、风格和措辞)。
https://gizmodo.com/apple-lobby-app-developers-1849554671
https://news.ycombinator.com/newsguidelines.html
> 通过将批评者污蔑为“阴谋论者”
@lepton明明这样写道：“或许协议中包含不实现某些功能的条款，因为这些功能会与Chrome形成竞争”——这分明是在指火狐浏览器。根本无需污蔑。
> 你为苹果反竞争商业行为辩护的欺骗性言论
我根本没提苹果的商业行为。我讨论的只是Chrome专属的非标准功能——这些被HN用户伪装成标准，并要求所有人立即实现的东西
>我的意思是，@lepton明确写道：“或许协议中包含不实现某些功能的条款，因为这些功能会与Chrome形成竞争”——这指的是Firefox。无需抹黑。
那你本该更具体说明，但这根本算不上阴谋论。这完全是合理推测。因此你急于将其斥为“阴谋论”的行为，实质上才是抹黑。
>我根本没提苹果的商业行为。我讨论的纯粹是一堆Chrome专属的非标准功能——这些被HN用户伪装成标准，并宣称所有人都必须立即实现。
你对Chrome开发团队的恶毒攻击和污言秽语，始终在竭力为苹果的行为开脱，同时公然忽视并淡化其明显的利益冲突。更甚者，你必须停止这种恶劣的歪曲——所谓“HN用户假装这些是标准并要求所有人立即实现”的论调纯属捏造，你却屡屡强加于人，尽管本帖中已有多人多次指出你的谬误。
> 但这仍与阴谋论毫无关联。这完全是合理存在的潜在论点
老兄，这根本是在宣称谷歌和火狐存在实质性阴谋来削弱火狐。现实中这种说法荒谬至极——谷歌Chrome市场份额本就居高不下，他们需要火狐作为有效竞争者来规避反垄断风险。所谓通过合同(或幕后交易)扼杀火狐的想法纯属幻想——这根本就是阴谋论。因为一旦曝光将面临巨大的法律和财务风险。所以当某件事是真正的阴谋论时，将其点名批评是正确的。
> 你对Chrome开发团队的抨击和污言秽语…必须停止这些恶劣的歪曲…
我正在用Ctrl+F搜索troupo的评论，但没看到类似内容。他们的观点完全合理：Firefox同样未实现这些功能，因此苹果的举动完全可以合理解释为出于相同正当理由。
另一方面，你却在说些：
> 苹果将维持惯用的把戏，声称这是为了隐私和安全
> 你在这件事上的偏见再明显不过，因为你执着于歪曲任何反驳苹果宣传叙事的证据
> 你像个无法处理新信息的机器人般重复相同论点，毫无新意，简直荒谬至极
> 这才是你维持幻觉的唯一方式——将你卑劣的苹果宣传包装成对苹果利益冲突的粉饰，而这种冲突正是其每项决策的动机
> 你的言论如此空洞，与现实脱节
> 你竟能如此固执地保持讨厌劲儿，实在不可思议
> 这简直像苹果付费投放的#广告
看来是你在苹果行为中编造阴谋论——“驱动他们每项决策”——并用你自己的“檄文”攻击他人。而使用极其侮辱性不当言辞的正是你。你的评论充斥着不符合HN社区氛围的恶劣语气，这大概就是它们频遭负评的原因。或许该反思这种互动方式是否妥当？不妨重温HN社区准则？
你为何要切换主账号来为小号辩护？你用同样不讲理的风格写作，拒绝理解简单陈述。
>我不知道啊兄弟。这分明在宣称谷歌和火狐存在阴谋让火狐变差。实际上这是荒谬的论调——谷歌Chrome市场份额已如此之高，他们需要火狐作为有效竞争者来规避反垄断风险。所谓通过合同(或幕后交易)故意削弱火狐的说法纯属幻想——根本就是阴谋论。一旦曝光将面临巨大法律和财务风险。所以当某事确实属于阴谋论时，指出来是正确的。
阴谋的定义是“团体秘密策划实施非法或有害行为”。而谷歌与Mozilla均为上市公司，他那句"或许协议部分条款要求不实现某些功能，因为这会与Chrome竞争。_我其实不清楚_，也不在乎火狐浏览器做了什么或没做什么。"这番表述与你扭曲后构造的稻草人论点根本风马牛不相及——你此刻正对着空气挥拳的，恰是你用小号惯用的谬误辩论手法。
>我正在用Ctrl+F搜索troupo的评论，完全找不到类似内容。他们的观点完全合理：既然Firefox同样未实现这些功能，那么苹果的举动完全可能出于相同正当理由。
真有意思，原来你觉得自己用小号提出的“论点”竟是“完全合理”——谁能想到呢。
>看来是你自己在苹果行为中幻想阴谋论——“这驱动着他们每个决策”
你再次未能正确理解并运用“阴谋论”这个词，因为我所有陈述都基于公开可验证的事实。急于将这些事实污蔑为阴谋论，恰恰是你用小号一直在做的事。所以你不得不切换主号假装中立，但又一次失败了。
这些观察也得到众多科技界人士的认同：
infrequently.org/2025/09/apples-antitrust-playbook
ericmigi.com/blog/apple-restricts-pebble-from-being-awesome-with-iphones
就连美国政府本身也观察并记录了苹果的反竞争商业行为，司法部甚至为此起诉了苹果：
"司法部起诉苹果垄断智能手机市场——苹果广泛排他性行为阻碍美国用户更换手机，削弱应用程序、产品及服务的创新能力，并给开发者、企业和消费者造成巨大成本：https://www.justice.gov/archives/opa/pr/justice-department-s…
你心知肚明，使用“阴谋论”一词实属抹黑行为，但作为苹果的忠实宣传者，你显然更热衷于用欺骗性言论操纵舆论，并通过小号扮演角色。
> 而你才是那个使用极其侮辱性且不当言论的人。你的评论似乎充斥着不符合HN社区氛围的语气，这大概就是我看到许多评论被点踩的原因。或许你该思考这种互动方式是否妥当，不妨重新阅读HN社区准则？
你在转移话题，使用侮辱性不当言论的正是你本人，还用小号扮演“中立”第三方。请先照着自己的建议重读HN指南。至于“负分”？尽管你用主号和小号双重打分，我在这条帖子的净正分反而增加了，说明你偏颇的分析又失败了。你骗不了任何人。
> 为何要切换主号来为小号辩护？
老兄，若你认为两个观点相似的账号必然是同一人，那你的现实认知已然扭曲。事实并非如此。
但请尽情幻想吧。既然你抱持这种心态，想必阴谋论在你眼中无处不在…
>老兄，若你认为两个观点相似的账号就必须是同一人，那你的现实认知可真是扭曲了。
我依据的是确凿证据——通过分析论点、行文风格、时间节点等高度指向傀儡账号的特征作出判断。与你不同，我既能论证观点又能支撑论点，而你却忙着为小号的人格辩护。
>但随你想象吧。既然你抱有这种心态，阴谋论大概无处不在…
这正是你主号和小号惯用的修辞手法。当你无法承受压倒性的反证时，便急于将人和事实污蔑为“阴谋论”——这正是你为苹果辩护的论点在事实重压下崩塌的体现。正因如此，你根本懒得讨论我提供的证据：那些彻底粉碎你虚假叙事的证据，你干脆选择视而不见。
> 正因如此，你连讨论我提供的证据都懒得费心
我不会与指控我拥有其他账号的人争论。若想在HN进行有建设性的讨论，建议你重新审视自己的讨论方式。
>我不会和那些指控我拥有多个账号的人争论。若想在HN进行有建设性的讨论，建议你重新审视自己的讨论方式。
那你就别再用小号了，很简单。况且你根本不参与讨论，只是无视所有不利于苹果公关叙事的观点，然后不断重复那些已被驳斥的陈词滥调直到令人作呕。你根本没资格教导他人何为建设性讨论，因为你表现得就像苹果第三方游说部门的成员：https://gizmodo.com/apple-lobby-app-developers-1849554671
你居然直接贴出谷歌搜索结果链接来证明自己观点正确？真是深入的调查啊。我坚决不同意Safari和IE属于同一级别；你有什么替代方案？难道谷歌要垄断整个浏览器市场？
我绝不认同因畏惧唯一竞争对手(另一家垄断企业)就纵容某垄断公司反竞争行为。两者都是消费者权益的威胁。
我贴那个链接并非作为“研究”，而是证明不止我一人称Safari为“新版IE”。相关讨论早已铺天盖地，你认为谷歌搜索毫无意义，并不代表我的论点站不住脚——况且若你真要“研究”，我敢打赌你首选的仍是谷歌搜索。成千上万的人都写过这话题，去看看他们的观点吧，指责Safari的人可不止我一个。
>坚决反对将Safari与IE相提并论；
这破浏览器简直垃圾，苹果总按自己的方式实现功能，尤其在触控交互方面。我不得不买真iPhone来调试苹果的实现问题。Safari他妈的烂透了，就是这么个事实，你那挑衅的评论根本推翻不了。
>那你有什么替代方案？难道谷歌垄断整个浏览器市场？
我不在乎他们是否垄断。我只想要iOS上替代Safari的选择。这要求有错吗？？
https://www.justice.gov/archives/opa/media/1344546/dl?inline
> 所以必须用真iPhone调试苹果实现的问题。Safari简直烂透了
你照样得调试。即便允许其他浏览器，Safari也不会消失。
“Safari 简直烂透了” 不能作为苹果存在反竞争行为的论据。Chrome 也有很多糟糕之处，Firefox 同样如此。没有完美的产品。
我当然需要调试，但我开发的是符合标准的产品，而非苹果那些怪异的触摸事件实现及其他诸多特性。因此调试网页浏览器本就不该需要苹果硬件。我无法在安卓或其他平台安装Safari，所以如果某个bug仅在Safari中出现，我就必须购买苹果硬件。我宁可不让苹果赚到一分钱——他们早已欺负过我们，我们甚至发起集体诉讼并胜诉(2011款MBP事件)。所以不，我绝不愿为修复他们愚蠢的专有漏洞去买一部天价手机。Chrome、Firefox、Opera等众多移动浏览器都能完美运行。
>Chrome也有诸多缺陷，Firefox同样如此。世上没有完美的产品。
谷歌并未阻止苹果为安卓提供Safari浏览器，只是苹果无法通过谷歌应用商店获利——就像他们能通过原生应用向iOS开发者勒索一样。
“Chrome也很烂”纯属主观评价。我从未遇到过问题，倒想听听你觉得Chrome哪里糟糕。Firefox嘛，以前用过一阵子，现在很少用了。我会在那里修复漏洞，而且修复起来既简单又免费。但苹果的Safari可没这么好对付。
苹果以前确实开发过Windows版Safari，但体验糟糕透顶，他们发现无法从中获利，于是直接停更了。所以他们完全有能力为其他平台开发Safari，却宁愿逼迫开发者购买iPhone。去他妈的。
iPhone用户们，恕我直言，在我开发的领域里你们永远是二等公民——这要怪就怪苹果，直到他们允许其他浏览器引擎为止。
你的观点相当特立独行。作为开发者，我从未听闻有人抱怨Safari因漏洞更多而难以开发。当我多次遇到Safari、Chrome和Firefox的JavaScript API差异时，这些差异大多源于规范描述不足导致的实现差异。我不会认定Chrome才是正确实现而Safari存在漏洞。听起来你只是优先针对Chrome开发。
没错，测试Safari需要苹果硬件。若连为业务采购廉价二手苹果设备都嫌麻烦，这更说明了你的商业决策问题。要求苹果必须在其他平台提供浏览器的想法在我看来相当荒谬。
你就像在抱怨想开发Linux版微软Word插件，却因微软不售Linux版Office而被迫安装Windows系统。这算什么？开发者理应在目标用户使用的平台上开发和测试。若连这基本现实都无法接受，或许就不该涉足软件开发。
>作为开发者，我从未听闻有人抱怨Safari因漏洞更多而更难开发。
那你根本没关注过相关讨论。
关于Safari是史上最差浏览器的文章多如牛毛。
https://www.google.com/search?q=safari+is+the+worst+browser
这绝非个别现象，而是主流共识。你选择视而不见，并不代表问题不存在。
>若连为业务测试购置廉价二手苹果设备都嫌麻烦，这恰恰暴露了你商业决策的短见。
我本不该为调试苹果垃圾浏览器支付分文。
>要求苹果必须在其他平台提供浏览器的想法在我看来相当荒谬。
我从未说他们有义务，只是指出他们曾尝试过，却惨败收场，无法盈利，最终打包回家。他们本可且曾在其他平台提供Safari。如今他们不这么做了，去他妈的苹果，我对他们的所作所为毫无兴趣，正如苹果对开发者毫无兴趣一样。
>你听起来像个…
你活脱脱就是个苹果粉，评论区里似乎还有不少和你一样被洗脑的同类。
你描述的完全不准确，我只希望苹果允许其他浏览器引擎登陆iOS，别当反竞争的混蛋。仅此而已。司法部也这么认为，所以你在此为苹果的暴政辩护是站不住脚的。
>你还能指望什么？开发者当然要在目标用户所在的平台上开发和测试。若连这基本现实都无法接受，或许就不该从事软件开发。
我预计苹果会采取恶意反竞争手段，禁止其他浏览器使用其自有浏览器引擎。一旦他们这么做，我就不再对此多言。在此之前，苹果才是混蛋。不是我，不是其他浏览器厂商，只有苹果及其辩护者。
我不禁怀疑贵公司管理层是否也像你这样鄙视客户。
我就是公司管理层，根本不在乎你怎么看。滚开。
> 但别只听我一人的说法，许多人都写过相关文章…
你是说Chrome成了新版IE？
https://google.com/search?q=chrome+is+the+new+ie
我真心好奇：无论是作为用户还是开发者，苹果在浏览器引擎政策上的行为和决策对你造成了什么影响？它阻碍了你实现什么目标？
具体而言，我所在的公司有一款本可使用蓝牙的产品，但Safari永远不会实现Web蓝牙API——而Chrome在安卓平台早已支持该功能。因此我们只能改用Wi-Fi方案(产品同时支持蓝牙和Wi-Fi)，这导致手机电量消耗更快。
不，我们不愿开发专属iOS应用——苹果不仅会抽取应用内销售额分成，还需支付开发特权费，甚至强制购买苹果硬件才能开发。
因此我们选择Wi-Fi方案，通过单一代码库维护跨平台的网络应用，但必须依赖Wi-Fi连接。若苹果允许Chrome使用自有浏览器引擎，我们只需告知用户安装Chrome即可与设备交互。如此既无需向苹果支付任何费用，也不该被迫支付。
苹果故意不开放某些API接口，以此迫使开发者为其应用商店创建应用，从而从应用产生的额外销售额中抽成。司法部起诉书里都写得清清楚楚，你为什么不读一读？？
https://www.justice.gov/archives/opa/media/1344546/dl?inline
> 苹果故意不实现某些API，以此迫使开发者为其应用商店创建应用，从而通过应用获取额外销售收入。
那么为什么Firefox也不支持Web Bluetooth API？你怎么能断定Safari不支持就是为了应用商店？
现实情况是Web Bluetooth API只是个草案。尚未获得批准，未进入正式标准流程。Firefox甚至无意实现该API，原因在于其涉及的安全隐私问题以及未获批准的事实。
但你继续认定这全是反竞争行为吧…
> 司法部起诉书里都写得清清楚楚，你为什么不读一读？
我刚用Ctrl+F搜索了“蓝牙”，所有内容都与智能手表相关，与Web API毫无关联。文件中仅两次提及Safari，且均未涉及标准问题。“Web标准”一词根本不存在。这份88页的文件里，你所指的内容根本找不到明确依据。希望你能理解，我不会花整个下午去通读全文。
我对Firefox的做法毫不在意。他们从谷歌那里赚得盆满钵满，谁知道他们这么做的动机是什么。Opera浏览器也实现了相同的API，但同样无法在iOS上运行——因为苹果这帮混蛋强迫Opera也必须使用Safari。
>未列入正式标准轨道。
真巧啊，苹果居然有权决定什么算“正式标准轨道”，而且他们对任何可能损害自家应用业务的提案都投了反对票。
>但你继续假装这全是反竞争行为吧…
好吧…苹果确实反竞争，而且一直如此。他们禁止在非苹果硬件上安装自家操作系统，明明技术上完全可行。其封闭生态以反竞争著称——禁止任何浏览器使用自有引擎并强制使用Safari，这绝对是反竞争行为。
知道吗？去他妈的读读美国司法部对苹果的反垄断诉讼吧，里面详细列举了苹果反竞争的诸多手段：
https://www.justice.gov/archives/opa/media/1344546/dl?inline
但我敢打赌你不会去读。
你似乎完全偏离了讨论重点。我最初就指出苹果在诸多领域存在反竞争行为。
但这并非当前讨论的核心。我强调的是在这个具体领域，其行为似乎并不构成反竞争。
所以我不明白你为何执意推送这份PDF。它对这个特定领域没有任何论述。我已经查证过了。
如果你对火狐浏览器的表现毫不在意，那显然你并非真心实意地参与这场讨论。你拒绝接受证据或反驳观点，只是对苹果抱有条件反射式的偏见。好吧，随你便。但我不会再浪费时间和那些对最显而易见的反驳观点“漠不关心”的人纠缠。
遗憾的是，这里许多人带着固执的偏见进入讨论。他们的观点早已凝固——非黑即白，非友即敌——只顾着发泄抱怨。除了自己偏好的方案外，他们根本不愿考虑任何解决方案。
>你似乎完全偏离主题了。我开篇就指出苹果在诸多领域存在反竞争行为。>但这并非讨论重点。我强调的是，在此特定领域，其行为似乎并不构成反竞争。
真不知要脑子多有问题，才能为苹果强迫iOS所有浏览器使用Safari的行为开脱，声称这不反竞争。你这种行为实在令人费解——你显然并非愚钝，只是不惜一切代价为苹果的明显滥用行为开脱。
>所以我不明白你为何执着推送这份PDF。它根本没提及这个具体领域，我已经查过了。
无需逐条罗列每项技术的具体细节，这些细节本就该在法庭上呈现。它与苹果在Safari浏览器中的操作完全相关，这正是其滥用行为的又一例证。苹果已在欧盟和日本因相同问题败诉，在美国也必将落败。
>若你对Firefox的做法漠不关心，那显然你并非以诚意参与这场讨论。
Opera等浏览器确实实现了与Chrome相同的API。因此你关于Firefox的论点完全无关紧要。
> 你的脑子到底要损坏到什么程度
够了。此类行为在此处绝不容忍。
https://news.ycombinator.com/newsguidelines.html
起诉书并未指控苹果通过削弱Safari功能来诱导开发者转向应用开发。恕我直言，你读过起诉书吗？
再者，贵公司何必自断生路？若蓝牙功能是客户必需(而非可有可无的“锦上添花”)，为何不竭尽全力提供应用程序？
你读过吗？ 以下是部分相关条款：
https://www.justice.gov/archives/opa/media/1344546/dl?inline
面对竞争威胁时，苹果并未通过降低手机售价或提升开发者收益来应对，而是通过在应用商店指南和开发者协议中设置一系列变幻莫测的规则与限制来应对。这些措施使苹果得以收取更高费用、扼杀创新、提供安全性降低或体验退化的服务，并限制竞争对手的发展空间。苹果已在多项技术、产品及服务领域部署此策略，涵盖超级应用、短信服务、智能手表、数字钱包等众多领域。
9. 苹果通过合同限制网络压制创新，其执行手段包括：掌控应用分发渠道与“应用审核”流程，以及拒绝开放应用与iPhone操作系统间的关键连接点(即应用程序接口，简称API)。苹果能实施这些限制，源于其作为产品创造者(如开发者)与用户之间中介的特殊地位。
16. 苹果以隐私保护、安全保障和消费者偏好为幌子，为其反竞争行为辩护。事实上，该公司投入数十亿美元进行营销和品牌建设，刻意塑造“唯有苹果能保障消费者隐私与安全利益”的自我标榜。当符合自身财务利益时，苹果便会选择性地牺牲隐私与安全——例如降低短信安全性、为政府及特定企业提供访问更私密安全的应用商店版本的权限，或在存在更私密选项的情况下，每年收取数十亿美元将谷歌设为默认搜索引擎。归根结底，苹果将隐私与安全作为弹性盾牌，可随意伸缩以服务其财务与商业利益。
43. 开发者无法通过创建网络应用——即使用标准编程语言为网络内容开发、通过互联网提供的应用——来规避苹果对应用分发和创建的控制。许多iPhone用户不会主动寻找或不知如何获取网络应用，导致网络应用仅占应用使用量的极小部分。苹果公司承认网络应用对开发者而言并非原生应用的理想替代方案。正如某位苹果高管所言：“开发者无法在网络上赚取丰厚利润。”尽管如此，苹果仍能控制网络应用的功能，因为其强制要求iPhone上的所有网络浏览器使用WebKit——这款苹果自主研发的浏览器引擎正是第三方浏览器显示网页内容的核心软件组件。
60. 多年来，苹果拒绝用户使用超级应用，因其认为这类应用会“从根本上破坏”现有应用分发与开发模式，并最终威胁苹果的垄断地位。苹果担忧超级应用的普及将导致“iPhone需求下降”，故通过掌控应用分发与开发渠道，实质禁止开发者推出超级应用，而非通过产品优势竞争。
仅引用投诉书更长的段落，并不能更好地支持你最初的主张。
我们结束了。
>再说，贵公司为何要自断鼻梁以报复自己？
这似乎是在责怪受害者。苹果才是这里的暴君。
>若蓝牙功能是客户必需(而非可有可无的附加项)，为何不费心开发应用满足需求？
因为这意味着必须雇佣iOS开发者并承担全部开发成本，而苹果随后会通过应用内购买抽成榨取利润。或者我得亲自编程——可我每天已工作18小时。去他妈的。绝无可能。只要苹果继续将其他浏览器视为二等公民并封杀其他浏览器引擎，苹果用户在我眼中永远是二等公民。开发iOS应用并非通往财富的捷径，所以苹果用户就得忍受更笨拙的WiFi体验。这就是现实。
> https://www.google.com/search?q=safari+is+the+new+ie
这当然是胡说八道
— 引文开始 —
指控Safari因缺乏关键功能支持而阻碍网页开发并非新鲜事，但同样站不住脚。十五年前IE确实拖累了网络发展，因为开发者不得不迁就其过时的技术栈——“最佳浏览效果需使用IE”之类的标语比比皆是。但你可曾见过“最佳浏览效果需使用Safari”的提示？没有吧。如今另一款浏览器占据了开发者心中的特殊地位。
…尽管Chrome并非行业标准，却被众多开发者奉为圭臬。
https://www.quirksmode.org/blog/archives/2021/08/breaking_th…
— 引文结束 —
Safari就是现代版的IE。过去十年PWA未能普及，纯粹是Safari的错。
苹果禁止替代引擎并持续阻碍重大网络技术发展的唯一原因，就是反竞争行为。
不，我认为Chrome才是现代版IE。它占据压倒性市场份额，导致开发者常直接忽略其他浏览器，或最多将其视为次要平台——这与当年IE霸权时期如出一辙。
老实说我对此很纠结。Safari(尤其是移动版Safari)堪称阻止网络沦为Chrome垄断的唯一屏障。虽然我渴望在iPhone上看到Safari替代引擎，但更担心的是：一旦出现替代方案，浏览器兼容性层面的“开放网络”将彻底终结。商业网页开发者极其懒惰，他们的产品经理同样如此。从那刻起，他们会认定网络仅需适配Chrome，对其他浏览器彻底置之不理。
IE6消亡时，对网页开发者而言固然是解脱——他们迅速删除了所有兼容性代码——但另一方面，这却加速了浏览器垄断，使网络生态更趋恶化。
Chrome如同当年的IE——它成为所有开发者测试的唯一目标，也是企业默认采用的浏览器。而Safari则像IE的晚期版本，拒绝跟进竞争对手添加的任何新功能或现代标准。尽管苹果的动机似乎比微软更具战略性。苹果憎恶网络是因为无法有效实施收费站模式，而我认为微软自2001年后便不再重视IE的投入。
> Safari就是现代版的IE。
那不是事实。它甚至在大多数计算机上都无法使用。IE的问题在于微软不遵循网络标准并滥用其垄断地位；而Safari作为整体市场份额较小的浏览器，在标准兼容性方面表现良好。
> PWA在过去十年未能普及纯粹是由于Safari的原因。
那么为什么PWA在Windows和Android上不流行？毕竟Safari对这些平台没有影响？
>那么为什么PWA在Windows和Android上不流行？毕竟Safari对这些平台没有影响？
谁说的？
"PWA在这些平台确实已流行起来。我在微软负责Microsoft Store(Windows应用商店)，同时参与Edge团队工作，并运营PWABuilder.com——该平台将PWA发布至应用商店。微软应用商店中最受欢迎的应用中就有许多PWA：Netflix、TikTok、Adobe Creative Cloud、Disney+等众多应用。
要在Windows设备上查看商店中的PWA列表，可运行以下地址：ms-windows-store://assoc/?Tags=AppExtension-microsoft.store.edgePWA" – https://news.ycombinator.com/item?id=46457849
> Safari在整体市场份额中属于小众浏览器，且基本符合标准规范。
虽然官方宣称兼容，但实际使用中Safari存在大量实现缺陷，开发者需耗费大量时间进行兼容性修复和调试。
它还是最后一款与操作系统捆绑的非常青浏览器，因此更新最慢，进一步加剧了这种影响。
> 那为什么PWA在Windows和Android上不流行？毕竟Safari不影响这些平台？
我个人认为，即使在Android上体验有所改善，PWA依然不够便捷。
若抱怨仅止于此，我认为Safari表现尚可。这与即将到来的IE根本不可同日而语，也说明PWA本身存在问题，与苹果无关。
我经历过IE时代，Safari确实带着挥之不去的IE痕迹。
IE有很多浏览器功能，官方说是支持的，但实际根本没法正常用。
我在Safari上遇到过表单、zIndex、SVG、背景和localStorage的问题。这些都是我认为应该永远正常工作的基本浏览器功能。
当然它没IE那么糟糕，但Safari明显远远落后于Chrome和Firefox。
有趣的是，那些“苹果永不犯错”的股东和“无论如何都要贬低PWA”的群体，竟奇妙地达成共识，不断重复那些早已被讨论到令人厌烦的论点——即便在本帖中亦是如此。任何技术都有其固有问题，与苹果无关，但当全球最大企业之一持续进行破坏时，这无疑雪上加霜。
我并非否认苹果存在阴险动机，但你对乔布斯当年言论的解读未免过度(或不足？)了。
回溯初版iPhone发布时的言论(以现在视角审视)，显然源于他们尚未准备好开放任何原生API。
“往你身上撒尿却说下雨了”正是乔布斯惯用的现实扭曲场营销手段，绝非他真心相信下雨的证明。
> 持相反观点者纯属天真
此言不当。理性分歧无需相互侮辱。
若你确有证据证明苹果刻意延缓Safari核心功能或网页标准支持，以期增加应用销量，请务必提出。
https://www.google.com/search?q=safari+is+the+new+ie
只需阅读Gemini提供的摘要快速掌握核心，再查阅相关多篇报道即可。请别回头说证据不充分——这不过是人们对苹果十余年来反复持续行为的合理推测罢了。
听着，我承认Safari很糟糕，但无论有没有AI摘要功能(我认为那根本不是Gemini，只是个廉价笨拙的模型，被要求总结几个热门结果)，用搜索链接来辩论根本站不住脚。我完全可以贴个“Safari拥有顶尖技术”的搜索结果链接，同样毫无价值。
需要提供证据的是你，而非某个大型语言模型。必须拿出确凿事实和意图证据，而非仅引用主观观点。
既然你声称确知某事，人们自然有理由期待你具备专业知识和数据佐证。若你闯进厨房自称大厨，最好带着锋利的刀具，而非刀具的照片。
说真的，你指望人们点击谷歌搜索链接去看赞同自己观点的人——然后还去读大型语言模型说什么？？何时起HN成了垃圾场，人们都不愿自己做研究或思考了？
依我看，大概是十年前吧。人们对某件事了解越少，就越固执己见且自信满满。不过这不仅限于HN，而是人类普遍的心理状态。
如果浏览器F的续航比浏览器S差，用户自然会发现并自行调整。若差距显著，这本是显而易见的；而细微差异也应通过续航工具和电脑媒体的评测体现出来。
安全性方面，沙盒机制本应将危害限制在浏览器内部，若未能实现则不应归咎于浏览器本身。或许可以限制密码填充等功能的访问权限，或设计API接口来降低影响。
标准化？在iOS强制使用Safari却拒绝在主流平台(Android和Windows)提供，这标准实在够离谱。嵌入式浏览引擎或许有其存在价值，但依我之见，这本该是应用开发者的选择权。
> 若浏览器F的续航表现逊于浏览器S，用户自会察觉并自行调整。
遗憾的是，某浏览器的制造商同时掌控着多个主流网络平台，不仅频繁犯下破坏浏览器兼容性的“错误”，还定期发布会“遗忘”用户浏览器选择的应用程序。
个人而言，我更希望苹果允许搭载完整广告拦截功能的浏览器引擎。但我也担忧，一旦放开限制，近乎垄断的浏览器市场将彻底沦为绝对垄断。
若非Safari的独占地位，我们早已生活在百分百“本网站专为Chrome打造”的世界。人们似乎忘了IE时代的糟糕体验。
若非iOS(及其更富裕的用户群体)，开发者绝不会浪费一秒确保网站跨平台运行。
在IE4-5版本短暂创新期之前，我们正处于“为网景浏览器开发”的时代。但人们为IE开发仅因以下特定原因痛苦：1. 目标IE版本仅限Windows系统(Mac版IE差异巨大，对针对Windows IE的网站毫无参考价值)
IE完全停止了实用界面与网页标准功能的开发，意味着需要兼容性的开发者只能困守在停滞的浏览器中
基于第2点，网页开发者在采用HTML5、<video>标签等技术时自然束手束脚。用户不得不频繁切换浏览器——用Firefox访问新潮网站，用IE处理银行、学校、政府等重要事务。
我认为上述情况在Chromium上均不成立。其开发持续推进，新增网页标准的速度远超其他浏览器，且基本覆盖所有平台(除苹果禁用地区)。需说明的是，我并不希望谷歌完全掌控它——毕竟即便没有Chrome，谷歌的规模也已过于庞大……但坦白说，这绝非IE式的困境。
Safari的续航表现长期优于Chrome，但人们仍坚持在MacBook上安装Chrome。
确实。Chrome的市场占有率和发展势头极其难以撼动，除非风扇噪音大到像在最高画质运行《赛博朋克2077》那样，否则非技术圈用户通常不会将特定程序与糟糕的电池续航联系起来。
这就像绝大多数开车的人不会在意CVT变速箱和自动变速箱的驾驶差异——除非其中一种性能严重落后。对把汽车/电脑/手机当作家电的人来说，车辆要么能开动，要么不能开动，区别仅止于此。
> 人们会自行摸索适应
不会的。只有HN用户会。普通人不会。
> 从安全角度看，沙盒机制应能将危害限制在浏览器内
问题在于，任意代码执行会大幅扩大风险。你所谓的“应该”根本不起作用。
> 标准化？在iOS强制使用Safari却不支持主流平台？
咦？苹果可是遵循网页标准的。为什么非得让Safari登陆安卓和Windows？Safari本身不是标准，网页标准才是。
>> 人们会自行摸索并适应
> 不会的。只有HN用户会。普通人不会。
当然会，苹果已经让操作变得非常简单。
要查看iOS应用的耗电情况，请前往“设置” > ‘电池’，您将看到过去24小时或10天内各应用的耗电明细，其中包含使用时长和后台活动记录。这有助于识别耗电大户应用，并通过管理“后台应用刷新”等设置来延长电池续航。
没错，用户能轻松识别耗电大户，操作也相当简单——除非你认为苹果的用户界面设计糟糕到让用户看不懂？
>问题在于，任意代码执行会大幅扩大风险。你的“应该”二字已说明一切。
若这成为网页浏览器的隐患，那么应用商店里所有应用都面临同样风险。网页浏览器应用本身并无特殊性使其比其他应用更危险。JavaScript早已实现高度沙盒化，且针对Safari的漏洞利用案例比比皆是。将问题归咎于其他浏览器，无异于指责受害者(苹果的反竞争行为)。
>咦？苹果遵循网页标准。为什么它必须在安卓和Windows上提供Safari？Safari不是标准，网页标准才是。
既然网页标准是标准，那就让其他网页浏览器登陆iOS吧。
苹果禁止其他浏览器引擎在Safari上运行的真正原因，是为了迫使开发者创建原生应用，从而从应用内的任何购买中抽成。苹果反竞争行为的问题已在美国司法部起诉书中阐明：
https://www.justice.gov/archives/opa/media/1344546/dl?inline
苹果明确表示，其对第三方浏览引擎的安全担忧源于即时编译技术带来的难以控制的威胁(即时编译需要将非文本内存页设为可执行)。苹果禁止其他应用使用此类技术，因此在该立场上保持一致。
当iPhone进入锁定模式时，苹果甚至会禁用Safari浏览器自身的JIT功能——尽管这会显著降低性能——以此进一步强化设备安全性。
对此你有反驳意见吗？
这只是他们的托辞。JavaScript被应用于几乎所有现存的网页浏览器，覆盖数十亿设备，并不存在苹果所宣称的安全风险。事实就是如此。苹果自家浏览器存在诸多其他漏洞，允许远程代码执行，但JavaScript通常不在此列——无论在任何浏览器、任何平台，过去十余年皆是如此。
苹果应用商店里恶意应用比比皆是。所谓即时编译的借口，不过是苹果公司为“控制竞争对手在用户付费购买的硬件设备上运行程序”的遮羞布。这种滥用行为正遭美国司法部起诉。请直接阅读诉状，免得我再回复你的评论：
https://www.justice.gov/archives/opa/media/1344546/dl?inline
首先，你是安全专家吗？若是，请出示资质证明。苹果雇佣了业内顶尖的软硬件安全专家(Cellebrite可作证——他们破解iPhone的能力远逊于市面上其他手机)。若苹果认为向应用程序开放即时编译功能存在风险，我选择相信他们。而你除了空口无凭的断言外，毫无反驳证据。
其次，我已明确告知：诉讼文件中从未指控苹果通过限制Safari功能来扩张应用业务。若您持不同观点，请提供诉状相关段落作为依据。
第三，您从未回应过我的任何评论。这完全是您自己的选择。
>首先，您是安全专家吗？如果是，请出示您的专业资质证明。
好一个转移话题的把戏。我才不跟你玩这套。
>苹果雇佣了业内顶尖的软硬件安全专家。
但Safari照样被黑客攻破。
摘自司法部起诉书：
16. 苹果以隐私保护、安全保障和消费者偏好为幌子，为其反竞争行为辩护。事实上，该公司斥资数十亿美元进行营销和品牌推广，宣扬“唯有苹果能保障消费者隐私与安全权益”的自利论调。当涉及自身财务利益时，苹果便会选择性地牺牲隐私与安全——例如降低短信安全性、为政府及特定企业提供访问更私密安全的应用商店版本的权限，或在存在更私密选项的情况下，每年收取数十亿美元将谷歌设为默认搜索引擎。归根结底，苹果将隐私与安全作为弹性盾牌，可随意伸缩以服务其财务与商业利益。
https://www.justice.gov/archives/opa/media/1344546/dl?inline
>如果他们认为向应用程序分配即时编译能力存在风险，我选择相信他们。而你除了空洞的断言外，根本拿不出任何反驳证据。
你显然被现实扭曲场影响了，这点毋庸置疑——和教徒根本无法进行理性对话。祝你愉快。
身为具备联邦反垄断诉讼解读者经验的执业律师，我必须指出：第16项指控并非具体指控苹果蓄意限制Safari功能以引导开发者转向应用开发。该段落实为描述性叙述，旨在刻画苹果的整体行为模式。该段落指控苹果自利自保，但对美国企业而言这终究不足为奇，且本身并不违法。
> 然而Safari仍遭黑客入侵
这简直是移动目标。
迄今所有浏览器都存在安全漏洞，当发现漏洞影响用户时，各大厂商都会及时修复。指望苹果——或者说任何开发商——保持零漏洞记录是不现实的。更何况，提升整体安全性的关键在于深度防御，要求一个为客户安全着想的厂商故意关闭已知漏洞的防御机制，本身就不合理。
我并非苹果教徒。苹果有很多地方我不喜欢，而且没有公司是完美的。无论如何，此处禁止人身攻击，当讨论堕落至此等低谷，我便退出。谁的论点更具说服力，且由读者自行判断。
>我是一名具备联邦反垄断投诉解读经验的执业律师
若属实，请出示资质证明。但你不会这么做。
>苹果雇佣了业内顶尖的软硬件安全专家。
16. 苹果以隐私保护、安全保障和消费者偏好为幌子，为其反竞争行为辩护。事实上，它斥资数十亿进行营销和品牌建设，宣传“唯有苹果能守护消费者隐私与安全利益”这一自利论调。
我已提供司法部诉讼文件中明确指出苹果安全立场纯属虚张声势且具有反竞争性质的段落。你似乎认为苹果是安全领域的绝对王者，但其实他们根本差得远。我不相信你是律师，正如我不相信你是安全专家。
> 你似乎认为苹果在安全领域绝对顶尖，但其实相去甚远。
反复强调这种观点直到令人厌烦也无法使其更接近事实。我已提供Cellebrite作为证据，你的证据呢？(不，持续曝出的安全漏洞不足以证明。安全性的最佳衡量标准是成功漏洞利用的范围及造成的危害程度。)
> 若真如此，请出示你的专业资质。但你做不到。
欢迎你来揭穿我的谎言。发邮件给我，我就把加州律师执照寄给你。otterley@otterley.org
> 你对此有何反驳？
人们应当有权在自己花大价钱购买的设备上运行所需软件。句号。
https://www.justice.gov/archives/opa/media/1344546/dl?inline
这从来都不是法律规定。设备是硬件与软件的组合体。设备制造商允许你在限制条件下安装软件，这属于特权而非权利。某些制造商(如汽车和医疗设备厂商)往往根本不提供此类特权。
尽管如此，你有权坚持自己的信念——这恰恰是整个讨论的核心所在。没问题，直接说出来就好。但若将这种诉求扭曲成阴谋论，声称苹果故意削弱浏览器功能来填补应用业务缺口，就有些牵强附会了。你不需要反派角色，你的诉求本身就足够了。
没错。从架构层面看，Safari确实比Chrome安全性更低。沙盒化功能推送耗时更久，至今未修复SLAP和FLOP漏洞，仍未实现真正的站点隔离。漏洞修复周期漫长，且屡屡流于表面、错误修复，导致需要二次补丁。
别再摆出苹果粉的居高临下姿态了。他们不需要以“用户利益”为名实施绝对控制，更无权如此行事。
> 至今仍未修复SLAP和FLOP漏洞。至今仍未推出真正的站点隔离机制。
这些事实虽有意思，终究是转移视线的幌子。在缺乏苹果为浏览器引擎授权所要求的严格审核机制下，为其他浏览器引擎启用即时编译(JIT)技术，如何能带来更安全的结果？
够了，别再摆出苹果粉的居高临下姿态。他们不需要以“为用户好”为名实施绝对控制，更无权这么做。
当然，你大可选择替代方案。若偏爱安卓，尽管用吧！
所谓“审核机制”毫无意义，因为其他引擎注定永远不会存在——这是设计使然。
由于苹果的限制，我被迫使用安全性较低的浏览器，这已彻底推翻你的论点。你对关键问题的巧妙回避，正是讨论苹果话题令人沮丧的根源。这种行为确实带有邪教色彩。
你被迫使用的“安全性较低”浏览器是哪款？原因何在？
你似乎需要更宽广的认知视野和更持久的记忆力。所谓安全性较低的浏览器正是Safari。
请勿替他人发言。
这种质询方式是刻意为之。我回应的对象声称自己“被迫”使用“安全性较低”的浏览器，却忽视了Android等替代方案的存在。我正等待更多细节，但预料不会有：这类对话最终往往归结为“我其实没被强迫做任何事；只是希望苹果让我鱼与熊掌兼得”的坦白——同时他们厚颜无耻地认为自己比领域专家更懂风险，因而刻意忽视潜在威胁。
别告诉我该怎么做。
你完全忽略了关键线索，所以我才说明背景。
>我回复的对象声称自己被迫使用“安全性较低”的浏览器，尽管存在安卓等替代方案。
现在你却在故作姿态。所以你现在似乎认为安卓拥有最顶尖的安全团队？之前你明明说是苹果。
可你却不断为苹果辩护，明明他们才是暴君，正是他们被司法部起诉——注意谷歌从未因安卓相关行为被司法部起诉？只有苹果因iOS和应用商店的行径遭到起诉。
我并非主张安卓比iOS更安全。两者都在持续提升安全性，经验教训促使防御工事不断完善。
但这并非重点。关键在于当事人声称自己“被迫”使用“安全性较低”的浏览器却未作解释。“被迫”暗示别无选择，而事实上存在替代方案。“被迫”与“对我而言不够便利”并非同义词。
> 注意谷歌从未因安卓相关行为被司法部起诉？唯独苹果因iOS系统及应用商店的操作遭到诉讼。
反垄断诉讼并非如你谬称的那样，是针对苹果为私利故意阻碍Safari浏览器的指控。司法部从未就此提出具体指控。(他们拥有顶尖律师团队，若有丝毫证据支持该指控绝不会遗漏。)核心在于苹果坚持将应用商店作为第三方应用唯一分发渠道，尤其聚焦其抽成比例，以及与第三方设备的整合问题。况且现阶段仍属指控阶段——这些主张尚待司法审查。完整真相尚未揭晓。
正如多数争议的核心，关键在于利益分配。若抽成比例仅为10%而非30%，Epic Games根本不会起诉苹果。众多评论者指出(我亦认同)苹果拒绝谈判实属自毁长城。
> 没错，用户完全能轻松识别耗电大户，除非你认为苹果的用户界面糟糕到让用户看不懂？
能看到并不代表用户会采取行动。我敢保证，普通用户的耗电榜单大概是Instagram/TikTok/Facebook/Twitter，而他们至今还没因耗电问题卸载过任何一个…
那又怎样？应用占用资源本就是常识，某些应用更耗电也绝非什么惊天发现。如果某个愚蠢用户的电池耗电速度超出预期，或许有人会提醒他。或许不会。或许他只会买个移动电源之类的东西来延长手机续航。我真的不在乎，但以这种借口将其他浏览器引擎锁在平台之外，根本站不住脚。苹果的行为就是反竞争，简单明了，无可辩驳。
https://www.justice.gov/archives/opa/media/1344546/dl?inline
> 前往设置 > 电池，即可查看应用耗电明细
你觉得有多少用户会去查看这个功能？甚至知道这个功能的存在？
> 如果这对网页浏览器构成问题，那么应用商店里的所有应用都面临同样问题
并非如此，应用商店禁止任意代码执行。
> 网页浏览器应用本身并无独特之处，使其比其他应用更具风险性。
确实存在——JavaScript。
> JavaScript本身已具备高度沙盒化特性。
…这是Safari实现的。若允许任何开发者在其浏览器中编写专属JavaScript解释器，这种特性便不复存在。
> 既然网页标准是标准，就该允许其他浏览器登陆iOS平台。
这完全是牵强附会。
>你觉得有多少用户会去检查这个选项？甚至知道它存在？
这无关紧要。功能本身存在即可。若用户连这都搞不懂，那他们面临的问题绝非智能手机所能解决。
>不，应用商店禁止任意代码执行。
你是说网页浏览器里的JavaScript解释器？笑死。难道Safari就能这么做？所以只有苹果能允许自家应用这么干？你这逻辑怕是没想透。苹果的规则纯属人为制定，旨在排挤竞争对手，逼迫开发者编写原生应用，好让苹果通过抽取原生应用内购分成来敲诈开发者。
>有啊——JavaScript。
这简直是你能提出的最愚蠢论点。JavaScript早已实现严格沙盒化并具备长期安全性。Safari曾出现的远程代码执行漏洞与JavaScript毫无关联，所以你把责任推给别处也白费力气。
>…由Safari实现。但若允许任何开发者在自家浏览器中编写JavaScript解释器，情况就不同了。
我推荐用户使用的是谷歌浏览器，而非H@ck0rbR0Ws3R，正是因为它支持我们公司产品所需的API(至少在安卓平台如此)。
好了蒂姆·苹果，司法部正找上门来。等他们敲门时你尽可解释这些，他们肯定会来的。
网页浏览器是苹果掌控用户设备时唯一的漏洞。虽然安全问题确实存在争议，但认为苹果对此毫不知情、其操作动机并非保护应用商店利益，这种想法未免太天真。
既然如此，他们为何不干脆放弃Safari，转用内置uBlock Origin的Firefox？
广告技术是安全与性能的巨大消耗源，允许广告存在并使其难以屏蔽，正是重大安全漏洞与性能缺陷的根源
这是否意味着iOS终于能迎来支持uBlock Origin的“真正”火狐浏览器？
苹果公司将(基本)遵守法律条文，但会继续竭尽所能地强烈抵制。繁琐的要求、任意的限制、过度严苛的执行，最重要的是功能受限且无法修复漏洞的糟糕API。
要在iOS上推出优质完整的浏览器引擎，仅靠开发者远远不够。你还需要一支律师团队来威胁和起诉苹果，迫使其放宽政策限制并修复API。
我怀疑Mozilla或谷歌是否愿意投入大量开发者年限和律师年限，在如此恶劣的环境中完整移植整个引擎的所有功能并妥善维护——仅仅为了日本市场。预计会出现业余级别的移植版本，但长期实用性存疑。除非其他国家效仿。
> 仅仅为了日本市场
欧盟不也一样吗？
欧盟是否也要求第三方引擎能全局替换应用中的网页视图？还是仅要求独立浏览器应用可使用替代引擎？
> 欧盟是否也要求第三方引擎能全局替换应用中的系统网页视图？
是的。
嗯，仔细查看日本要求后发现，它似乎并不允许全局替换网页视图——这与我的预期及Android的允许方式不同。欧盟要求同样如此。它们仅允许单个应用通过将完整引擎嵌入应用的方式，以应用为单位嵌入替代引擎。日本页面还包含“浏览器引擎维护方开发的应用”这一限制条款，若严格解读(我预计苹果会如此)，则禁止非谷歌或Mozilla开发的应用嵌入Chromium或Gecko引擎。
考虑到iOS网页浏览大量依赖WebView，这无疑是重大限制。若欧盟和日本市场同时存在，谷歌或许会为Chrome单独移植Chromium引擎，但仍需观望。实际上Chromium开发是开源的，因此谷歌是否进行实质性移植工作应该很容易看出来。
> 欧盟要求也没有规定
错误，法律明确规定“独立网页浏览器以及集成或嵌入在软件中的网页浏览器”均在适用范围内。
你指的是苹果公司选择的具体实现方式。欧盟尚未对Safari浏览器启动合规调查，但我预计他们迟早会这么做。
我认为欧盟法规未必认定苹果的实现方式违法。但希望他们能认定。
大概不会，至少不会来自Mozilla自身。他们抱怨要求繁琐，且为不同地区维护不同应用程序难度太大。
https://www.theverge.com/2024/1/26/24052067/mozilla-apple-io…
唉，恶意的合规 🙁
目前Safari有uBlock Origin Lite可用：
https://github.com/uBlockOrigin/uBOL-home?tab=readme-ov-file
(效果很棒)
大概不会，毕竟欧盟地区苹果设备早前就实施了相同规则，至今仍未出现第三方浏览器引擎。
不过现在Safari可以使用uBlock Origin Lite，或者其他众多广告拦截器。
其实在Kagi的Orion iOS浏览器里能用完整版uBlock Origin。
补充说明：iOS版Safari已支持uBlock Origin Lite。iOS版Firefox随时可实现同等功能，且其本身已内置部分追踪拦截和内容屏蔽机制。
作为近期从安卓转投iOS的用户，我必须指出iOS版Safari上的uBlock Origin Lite，不过是安卓版Firefox上原版uBlock Origin的拙劣仿制品。
确实如此！我知道你只是用这个词，并非别有深意，但为澄清“仿制品”一词，uBO lite并非山寨品，而是uBO和Raymond Hill官方推出的产品：详见https://github.com/uBlockOrigin/uBOL-home
它和1Blocker比起来如何？我在Safari里用1Blocker，外出时还会连VPN切换回家庭网络，这样就能用NextDNS屏蔽大量应用内广告。
有没有什么主流网站对你来说无法正常使用？
欧盟地区可能早就有先例了，所以火狐和谷歌不推出自有引擎(至少目前)肯定有其考量。
uBO lite在iOS/Safari上运行得相当不错。
没有。苹果成功将规则复杂化，导致一年多过去欧盟仍未出现第三方浏览器引擎。
独立二进制文件的要求使其完全无法实现，因此他们仍在故意违法。该规定禁止任何可能导致浏览器采用替代引擎的行为。他们强制规定不得与同一开发者的其他应用共享登录状态，尽管自己却违反该规定(Safari同步默认开启，且默认不加密)。真有意思。他们还强制要求阻止第三方Cookie——这虽好，但由操作系统强制执行完全不合时宜。最可笑的是：
> 优先快速解决已报告漏洞[…] 多数漏洞应在30天内修复，但复杂漏洞可能需要更长时间。
苹果并未遵守此规定。
2026年应当是所有科技爱好者彻底抛弃苹果(和谷歌)的年份，转而运行免费安卓系统(Graphene、Lineage或其他变体)或Linux手机。
当前苹果和谷歌设备不过是强制监控的工具。
说教劝诫毫无意义。当替代方案更优时，人们自然会转向石墨烯和Linux。
强制监控问题在多数人对个人设备的抱怨清单中排名靠后。
让“技术控”抛弃苹果等品牌，对主流用户的使用习惯毫无影响。
例如我用Kobo阅读器搭建了相当流畅的Calibre-Web自动化系统，不仅更换了Kobo的商店界面，还能实现精选书架的无缝空中同步。但即便如此，我仍难以说服妻子放弃亚马逊Kindle转投这个系统。只要出现任何操作障碍，普通用户(抱歉亲爱的)就会立刻失去兴趣。
我用Boox电子书做了同样配置，亚马逊就算付钱我也不愿回头。Calibre简直是天赐之物。
这种设计完全脱离现实——绝大多数非极端运动参与者根本不会这样生活。
遗憾的是，我对手机与笔记本的深度联动依赖太深，无法割舍任何一方
我没有苹果设备可作对比，但KDE Connect应该能完全本地实现类似功能。若苹果所谓的“深度集成”依赖于设计上就侵犯隐私的云端组件(即便苹果承诺不查看流经其服务器的数据)，我也不会感到意外。
苹果生态中多数跨设备功能实际上通过点对点蓝牙和WiFi实现，无需互联网连接甚至共享WiFi网络即可运行。Mac和iDevice的WiFi硬件正是为此设计，能够同时维持与其他设备的点对点连接及WiFi网络连接，无需像许多商用WiFi网卡那样频繁切换。
遗憾的是苹果设备的集成度相当薄弱。当应用程序不在前台时，KDE Connect 无法保持活动状态。这可能是打包问题，但从 Fedora 进行配对时也相当不稳定。
听起来虽荒谬，但Windows通过手机链接连接iPhone的体验竟几乎媲美苹果原生生态——我甚至能在电脑上拨打电话和发送短信。虽然设置流程不如苹果流畅(但向导设计得相当出色)，整体运行基本稳定。
> KDE Connect在应用程序非前台时无法保持活动状态。
看来这要归功于苹果。
https://github.com/KDE/kdeconnect-ios?tab=readme-ov-file#kno…
KDE Connect在iOS端虽实用，但体验糟糕透顶。
就我所见，Linux手机至今仍是垃圾。
移动端的Linux发展，恐怕比90年代桌面端的Linux还要落后。
我不认为它们很糟糕，但存在两大问题：(i) 缺乏旗舰级硬件，(ii) 应用兼容性。问题(ii)已通过Waydroid得到很大程度缓解。目前在现代Pixel设备上运行Graphene仍是最优解——兼顾自由度与可用性(>99%安卓应用兼容性，完全脱离谷歌生态)。
> 2026年应是所有科技爱好者彻底抛弃苹果(和谷歌)的转折点
为何？我虽是科技爱好者，却对手机运行替代浏览器引擎毫无兴趣。按你的标准，我算“错误”吗？
巨大优势：能将任何网站转为应用运行(大幅降低开发成本，终于能用PWA取代Electron框架)、应用价格降低30%(免除苹果税)、广告拦截功能，以及WebKit引擎获得真正竞争后带来的性能提升。
个人认为Graphene的用户体验远逊于iOS
我持不同意见。过去用过iPhone，反而觉得Graphene极简界面令人耳目一新。这就像把Arch系统上的KDE与Windows 11或macOS对比——没有任何干扰元素，操作系统回归本真，成为管理和启动应用的平台。
这确实因人而异。我曾在备用安卓设备(旧款Pixel 3XL)上安装Graphene系统，与原生ROM或主流AOSP分支(如LineageOS或Pixel Experience)相比，体验相当糟糕。实在无法想象把它装在主力设备上使用。
Linux同样如此，无论采用知名桌面环境、极简平铺窗口管理器还是中间形态，其粗糙边缘、细微割伤和怪癖仍过于频繁，难以成为我的主力桌面系统。
重点在用户体验而非界面设计。典型例子就是笔记本复制内容粘贴到手机——在苹果设备上轻而易举。
所谓简单是指有时运行流畅，有时却毫无征兆地出错——至少我的使用体验如此。
除非蓝牙关闭，否则它对我而言始终完美无瑕。
通过蓝牙或WiFi的KDE Connect似乎是理想方案，证明技术上完全可行。我不清楚苹果设备如何处理这类功能，但确实不想依赖云端连接。
根据我的使用体验，KDE Connect比Continuity剪贴板更可靠。
所以你的文件在运行Linux的笔记本上，只需简单操作就能传到iOS手机？
这个有时会失效。我老婆经常抱怨
Tailscale Drop更优，且支持跨设备操作。
Tailscale Drop比直接在iOS设备上复制粘贴复杂得多。后者根本无需设置，操作就是这么简单——这只是单一操作场景的例子。
https://tailscale.com/kb/1106/taildrop
看看这些步骤，笑死。iDevice直接复制粘贴文件或文本就搞定，无需任何配置。
如何从Mac复制到安卓设备？
这听起来像是夸大其词。我从未用过Tailscale，但看了文档：
安装：安装Tailscale客户端
共享：点击共享菜单选择Tailscale
这是测试版功能，目前还需手动开启开关。
你不必相信我。我每天都在用。不知道你为何这么敏感哈哈——这只是个人观点。顺便说，我无需任何操作就能实现(笔记本剪贴板到手机)
至于苹果端：
安装：无需操作
共享：Cmd+C/Cmd+V
Graphen拥有自由与隐私保障。
可惜我更偏爱流畅的动画效果。
能否详细说明iPhone如何成为大规模监控工具？
例如：
https://en.wikipedia.org/wiki/PRISM
https://sneak.berlin/20201112/your-computer-isnt-yours/
https://www.cbsnews.com/news/apple-siri-lawsuit-settlement-i…
2026年理应是技术圈人士最后意识到谷歌/苹果已被美联储掌控的年份。若你拖到2027或2028年才转向，恐怕为时已晚。
尤其针对苹果，我常看到人们担忧：若开放其生态系统，用户将失去最亲民的科技公司之一。这不仅是“若苹果允许替代浏览器，Chrome必胜”的简单逻辑(这或许成立)，更在于：
* 若苹果允许第三方应用商店，整个iOS生态将腐朽溃烂，被恶意软件淹没——此观点在苹果诉Epic案中被反复提及
* 若苹果无法管控用户手机数据，隐私权将荡然无存——这正是苹果诉Facebook案中关于数据收集授权的焦点争议
这些担忧确实有理——苹果在生态系统中确实扮演着“仁慈的独裁者”角色。但除了“苹果掌控其硬件上所有软件”和“一旦苹果失去用户体验控制权就会更糟”这两极，难道不该存在中间选项吗？我们需要更多科技公司，在两极之间提供更多选择。市场需要更强的竞争，若无法实现，难道不该通过监管更好地保护用户和开发者？这种局面总让人感觉像是在“两害相权取其轻”——要么选择硬件封闭的企业，要么忍受软件层面的用户剥削。倘若微软禁止第三方浏览器引擎，评论区早该暴动。苹果对用户的态度确实更优。
赋予企业锁死硬件的权力绝非良策，当苹果终将反噬用户时，这种做法不仅行不通，更会形成可怕的法律先例。天知道约翰迪尔和无数掠夺性硬件公司正垂涎于用户无法掌控自己购买的硬件，而Meta和微软则热衷于让用户丧失对运行软件及数据收集的控制权。我们不能仅仅在两家企业中选择相对较不恶劣的那家。
奇怪的是人们从未将这些论点提炼到最基本的逻辑层面。
苹果直接决定着iOS上任何创新的形态、速度乃至存续，进而影响所有涉及手机或面向手机的创新。他们不仅拥有“权力”——即说“是”或“否”的决定权——更通过根本性的系统封锁确保：除非苹果预先设想并设计支持该功能的操作系统，否则任何创新都无从诞生。
当Windows 1.0问世时，浏览器尚不存在。但它们终究诞生了。若换作iOS系统，网络功能将不复存在，即时编译技术(JIT)亦无从谈起(我明白该技术后来才出现，请稍安勿躁)，Firefox/Gecko浏览器更不可能诞生并修复网络生态。过去数十年最重要的技术演进，将完全由苹果单方面掌控。除非苹果亲自发明并植入iOS，否则这些技术根本无从诞生——包括基础操作系统功能：文件与文件系统、资源共享、屏幕投射、设备互联。苹果不创造，它们就不存在；苹果不改变，它们就不会变。
就拿文件同步这种基础功能而言。苹果强迫Dropbox、GDrive、OneDrive接入其糟糕且漏洞百出的后端系统。这些服务不得不为此削减核心功能。除非苹果允许，否则这些功能永远无法恢复。任何假想的新功能，也唯有当苹果(而非其他任何公司)构思并添加时才会存在。
这合理吗？
> iOS 的封闭程度如此之深，除非苹果公司主动构想并设计操作系统来支持，否则任何创新都无从谈起。
没有哪个平台能像 VisionOS 这样凸显你提到的这个问题。
它一片荒芜。不仅因为付费应用缺乏用户基础(这固然令人痛心)，更因缺乏开发接口，且无法直接破解私有API或硬件…这些限制永远不会改变。Vision Pro应用商店充斥着半吊子的“空间计算”消费类应用(哇，我能把股票行情贴在墙上！但必须戴着笨重的护目镜才能看清！真酷！)“展厅”类纯消费应用(多为产品3D模型)以及媒体消费应用。现有游戏都相当乏味，更无法体验任何为VR开发的经典游戏——因为A.它们永远过不了应用审核，B.只能搭配PSVR控制器使用，导致我现有的Index控制器完全闲置。
Vision Pro必须像Mac那样开放。当前问题空间定义模糊，硬件蕴含大量有趣应用场景，却被限制性强的App Store规则束缚。iPad模式之所以成功，是因为2010年它能借iPhone的上升势头发展。而当下，在创新空间狭小的僵化应用市场中，搭载潜力远逊的设备，App Store限制如同抽尽空气般窒息了整个生态。苹果的铁腕控制令整台设备窒息——他们坚信自己有权独占设备上诞生的所有好点子，更有权抽取设备上所有经济交易15-30%的分成。这根本就是个生来就被阉割的平台——抛开定价、配置、重量等所有因素不谈。优质应用无从谈起，因为你根本无法开发想象中想要的应用。天啊，直到visionOS 2.0才允许访问主摄像头，还得通过“企业应用”API/权限才能实现。
苹果的桎梏已将其扼杀。这不过是台能戴在脸上的高级电视机。作为电视确实出色，当作真实电脑的外接显示器也勉强可用。
难道替代方案是安卓吗？
这款设备至今仍无法在美国上市简直荒谬。苹果明明已为欧盟和日本市场承担了实施成本，却偏偏拒绝美国用户使用…大概是出于恶意吧？太可恶了。
这让我想起曾要求某在线学习平台(可能是Udacity？)删除我的账户，对方竟回复： “不行，我们只为欧洲用户提供此服务。”仿佛他们费尽心思搭建了完善的数据删除机制，却对地理位置不符合的用户…直接拒绝执行。
> 他们已为欧盟和日本市场承担了实施成本，却拒绝向美国用户开放…
若你所指的“这个”是“一套复杂到让第三方永远不敢推出浏览器的规则”……
实际上他们根本没推出任何实质内容，欧盟至今仍没有第三方浏览器引擎可用
> 美国用户至今无法使用该功能简直荒谬至极。
坦白说，我怀疑苹果刻意如此操作，旨在让替代方案在物流和法律层面成为噩梦，从而压制其应用商店的竞争对手。
通过制定各国不同的规则、不同的收费结构等，苹果基本上在法律允许范围内，让替代方案变得尽可能麻烦和痛苦。
美国用户无法获得这些功能是故意的，这使得“iOS上的替代方案”这个概念相较于直接使用应用商店变得极其不便。
苹果既没捐款给特朗普就职典礼，也没送他金玻璃镇纸，更没资助他拆除东翼大楼——这些举动绝非为了迫使苹果在美国开放应用商店。
日本是否决定推行真正的竞争法？
是时候强制苹果在全球执行了。这项改革早已刻不容缓。
我认同“执行竞争法”的立场，但在当前语境下，若天真地强制执行，只会让主导浏览器引擎Blink在移动生态中根深蒂固。
部分开发者会欣喜若狂，但同样有人担忧这将催生单一文化生态。
在Mac上并未如此。Safari在非技术人群中依然受欢迎
它在技术倾向的Mac/iOS圈子中也保持着人气，因为相比Chrome(及其衍生浏览器)和Firefox，它更省电。部分用户虽有意转换浏览器，但由于谷歌和Mozilla对自家浏览器耗电问题并不在意，相较于WebKit(例如在GNOME Web中同样高效，证明这并非纯粹的原生优势)，两者投入的优化资源都相对有限。
这是因为苹果在操作系统层面为Safari额外添加了两条腿，而通过操纵这种比较方式，可以说是在其他浏览器腿上同时砍了一刀。
你认为这种情况在哪些方面具有实质性影响？我这么问是因为从未听说过Chrome或Firefox会因平台限制而受到能效方面的抑制。
这段论述亟需加上醒目的“需要引用来源”标记。
核心逻辑在于：一旦开发者能向所有用户宣告“我们只支持Chrome，请直接安装Chrome”，Safari的支持者就会逐渐消失。
遗憾的是，除非苹果在全球范围内开放浏览器支持，否则我们无从验证这种论断是否成立。
苹果禁止iOS平台使用其他浏览器引擎，是因为他们能从应用商店内购中抽取高达30%的分成。若开发者能通过功能完备的网页浏览器实现相同功能，便无需开发原生iOS应用，这将直接削减苹果的应用收入。因此苹果刻意削弱Safari功能，使其缺乏蓝牙等高级浏览器API及应用可用的其他接口，迫使开发者创建应用程序，从而让苹果能够从中抽取应用内购买分成。
这与用户不再使用Safari导致苹果感到遗憾毫无关系。虽然技术上可在iOS安装其他浏览器，但底层浏览引擎仍强制使用Safari——该引擎缺乏其他浏览器可实现的众多API，从而削弱了开发原生应用的必要性。这种局面纯粹源于苹果的反竞争贪婪。欧盟、日本及美国司法部已注意到此问题，目前仅欧盟和日本采取了强制苹果整改的措施。
以下是司法部起诉书全文，其中列举了苹果诸多其他反竞争行为。
https://www.justice.gov/archives/opa/media/1344546/dl?inline
除推测外，你有什么证据证明苹果如此动机？Safari渲染引擎缺少哪些标准功能，导致其浏览器性能不足，以致开发者被迫转而开发应用？
具体而言，我公司产品本可使用蓝牙功能，但Safari始终拒绝实现Web蓝牙API，而Chrome在安卓平台早已支持该功能。因此我们只能改用Wi-Fi方案(产品同时支持蓝牙和Wi-Fi)，这导致手机电量消耗更快。
我们绝不愿为iOS开发专属应用——苹果不仅会抽取应用销售额分成，还要求我们为开发权支付费用，甚至强制购买苹果硬件设备。
因此我们选择Wi-Fi方案，通过单一代码库维护的网页应用即可兼容Android和iOS系统——但必须依赖Wi-Fi连接。若苹果允许Chrome使用自有浏览器引擎，我们只需建议用户安装Chrome即可与设备交互，这样既无需向苹果支付任何费用，也不应被迫支付。
苹果刻意不开放某些API接口，就是为了迫使开发者为其应用商店创建应用，从而通过应用内的额外销售抽成牟利。司法部起诉书里都写得清清楚楚，你们为什么不读一读？
https://www.justice.gov/archives/opa/media/1344546/dl?inline
我们已在其他讨论串回应此事，请另行查阅。
WebXR十年未获支持，他们自然掌控着自家AR市场。
这体验和安卓平台相比如何？
“单一文化”的威胁从未如此微弱。WPT.FYI正朝着渐近完美的兼容性和行为标准迈进。而真正的网络——那些长尾网站——过于混乱，任何实体都无法掌控，无论其浏览器市场份额多大。Chrome可以随意设计API，但无法强迫网站采用。若有人在Safari上无法访问某些WebMIDI网站，那他们无权抱怨——毕竟他们从一开始就不该让这类网站存在。
这根本不足以成为维护iOS浏览器禁令的正当理由。
禁止竞争绝不可能促进竞争。
例如看到Firefox搭载自有引擎进入该领域会是件好事。
若我正确理解“浏览器引擎管理方”的资质要求，这是否意味着只有谷歌和Mozilla能获得“嵌入式浏览器引擎许可”？连微软似乎也被排除在外——毕竟Edge引擎基于Blink。其他小型浏览器引擎更会因基础网页功能要求而被淘汰。
这简直毫无包容性可言。
标题具有误导性。“允许”需要加引号——他们竭尽全力确保这在实际中不会改变任何情况。去他妈的苹果。
能否详细说明？除了“日本”要求外，其他似乎都合理？
我猜这些要求相当苛刻，但如今对浏览器而言都算基本门槛(比如Firefox或Chrome应该都能满足)。
他们不可能用“苹果被迫允许替代方案…”当标题
他们才是允许替代方案的方，因为他们是守门人。他们掌握着“钥匙”
为何仅限日本？似乎是日本方面迫使他们这么做的。
美国司法部正以多项指控对苹果提起反垄断诉讼，其中包括在iOS系统上封锁除自家Safari浏览器外的所有浏览引擎。
https://www.justice.gov/archives/opa/media/1344546/dl?inline
如今“蒂姆·苹果”向现任掌门人授予了毫无意义的金质奖杯，谁知道诉讼能否继续推进。
该法案适用于欧盟和日本，基本上涵盖所有抵制苹果反竞争行为的地区。
https://developer.apple.com/documentation/bundleresources/en…
没错，日本新法规强制要求他们这么做。
对于许多每日访问Hacker News的读者而言，这并非新闻：
• (4年前) 日本迫使苹果略微放宽对“阅读器”应用的限制 — https://news.ycombinator.com/item?id=28387094
• (3年前) 日本敦促苹果和谷歌允许旁加载应用——https://news.ycombinator.com/item?id=36393809
• (3年前) 日本将开放苹果和谷歌应用商店竞争——https://news.ycombinator.com/item?id=36368735
• (3年前) 日本将开放苹果和谷歌主导的手机应用市场竞争 — https://news.ycombinator.com/item?id=36370398
• (3年前) 苹果日本因免税政策滥用遭追缴9800万美元税款 — https://news.ycombinator.com/item?id=34156235
• (2年前) 日本将严打苹果和谷歌应用商店垄断行为 — https://news.ycombinator.com/item?id=38773429
• (2年前) 日本迫使苹果和谷歌开放移动平台——https://news.ycombinator.com/item?id=40666651
• (2年前) 日本立法遏制苹果、谷歌应用霸权 — https://news.ycombinator.com/item?id=40671162
• (5个月前) 日本要求苹果必须在12月前解除浏览器引擎禁令 — https://news.ycombinator.com/item?id=44810061
• (5个月前) 日本法律将要求苹果允许非WebKit浏览器登陆iPhone — https://news.ycombinator.com/item?id=44826077
• (15天前) 苹果宣布在日本调整iOS政策 — https://news.ycombinator.com/item?id=46307858
• (14天前) 苹果与谷歌回应日本新手机法案，包括降低应用费用 — https://news.ycombinator.com/item?id=46310074
…更多内容请见：https://hn.algolia.com/?q=japan+apple
苹果竟不惜大费周章，只为在个别强制要求其妥协的地区开特例，实在令人惊叹。
本该出台真正的消费者保护法，现在却只得到这种残羹冷炙，实在令人失望。为何不允许用户在电脑上安装制造商未授权的软件？偏偏只针对浏览器和“应用商店”？
资本主义使然。
真好奇究竟是哪些技术细节让其他地区难以启用这项功能。
根本不存在。苹果压根没装模作样。
真希望能有个支持触控笔涂鸦的浏览器。
这会变成怪兽大杂烩
那冲之鸟岛、竹岛、尖阁诸岛的居民能用这个替代浏览器吗？
不能，但满洲人可以
[已删除]
iOS用户最爱苹果为他们精选软件。
>iOS用户喜欢苹果为他们精选软件。
https://en.wiktionary.org/wiki/cuck_chair
希望借助人工智能，我们能拥有除Chrome和Firefox之外的浏览器引擎。
我全力支持隐私保护和替代应用商店，但开放浏览器引擎竞争并非我所乐见。
如今每部手机都将预装两种引擎(Chrome必然会捆绑在至少一款应用中)。两者都与大型科技公司捆绑，且功能集几乎相同。
现阶段我看不出对终端用户有何益处。新的CSS垃圾功能？晦涩的Web API？还是专有DRM？代价却是网站又将出现“仅限Chrome”或“仅限Safari”的标识——仿佛回到了1999年。
这是苹果，用户心知肚明，他们恰恰希望iPhone不是PC。
似乎所有人都认为这是好事。除了“这是垄断”的论调外，能否给出更深入的解释？如果引擎是免费的，且要求其性能基本匹配所有桌面浏览器引擎，这就不构成垄断。
我并不觉得苹果在这方面逼得我走投无路。