苹果公司拥有一个私有CSS属性，可为网页内容添加液态玻璃特效
苹果若不用这项技术，自然不会开发它。具体应用在何处？我们不得而知。但它必定存在于某个角落。我们从未察觉其具体位置的事实，恰恰说明我们在日常使用iOS时，早已在不知不觉中与WebViews进行了交互。
我有个极其无聊的夏日爱好：研究WebKit Github仓库的变更日志。为什么？因为我的工作很大一部分是在移动应用中处理WebView，而我喜欢提前了解iOS新版本的动态。既然蒂姆·库克尚未在WWDC上宣布“最后一项功能…WKWebView将支持Service Worker，前提是你在Info.plist的WKAppBoundDomains数组中添加正确条目”(说真的，他_应该_这么做)，手动研究就成了日常工作。
因此当WWDC落幕次日，我注意到一个名为：
液态玻璃是2025年WWDC的重磅成果，堪称iOS 7摒弃拟物化设计后iOS界面最大的变革。但这些都是原生UI，与WebView有何关联？
在PR上下文中稍作探索，发现了一个非常有趣的细节：苹果拥有一个名为-apple-visual-effect的自定义CSS属性。该属性不仅支持在iOS 26中使用液态玻璃效果(通过-apple-system-glass-material等值实现)，所有版本还支持使用标准材质，例如-apple-system-blur-material-thin等值。
确实有效，但无法实现
在你像我一样打开Safari开始编辑CSS之前，我有个坏消息：它在网页上无法生效——这本应如此。但更糟的是，在使用WKWebView的应用中它也默认失效，必须通过WKPreferences中的useSystemAppearance设置进行切换… 该设置为私有属性 。因此若使用该功能，就别指望通过App Store审核了。
我仍想尝试实现该功能，于是通过修改代码将useSystemAppearance设为true，并将CSS设置为：
.toolbar {
border-radius: 50%;
-apple-visual-effect: -apple-system-glass-material;
height: 75px;
width: 450px;
}看哪，竟成功了！
苹果公司那位将此设为CSS属性的决策者堪称天才——这使得根据Liquid Glass支持状态提供不同样式规则变得异常简单：
.toolbar {
border-radius: 50%;
height: 75px;
width: 450px;
background: rgba(204, 204, 204, 0.7);
}
@supports (-apple-visual-effect: -apple-system-glass-material) {
background: transparent;
-apple-visual-effect: -apple-system-glass-material
}谁在乎呢？
这虽是个有趣的冷知识，但苹果公司以外的任何人都无法使用它。那又如何？无关紧要。除非它暗示了某种理论——姑且称之为阿拉斯泰尔的宏伟理论 假发式应用内网页视图理论(感谢Hacker News上graypegg的重新命名)。整个行业对WebView的评价都不太好。但我想说的是：应用内WebView声名狼藉的主要原因，在于那些无缝集成的WebView往往不被察觉。
苹果若不用这项技术，自然不会开发它。具体应用在何处？我们不得而知。但它必定存在于某个角落。我们从未察觉其具体位置的事实，恰恰说明我们在日常使用iOS时，早已在不知不觉中与WebViews进行了交互。
值得深思！
仅向自家程序提供操作系统功能，这显然是反竞争行为。利用你在一个市场(手机/手机操作系统)的特权地位，在另一个市场(智能手机应用)中获得竞争优势，同时剥夺竞争对手的同等机会——这简直是教科书式的案例。
本想对苹果感到愤慨，但实在做不到。试着读读WinAPI文档，数数那些“保留”参数的数量就知道了。操作系统开发者随时都在构建仅供内部使用的功能。
诚然，这只是界面微调，我不认为必须保密，但他们大概只是不想永远维护这个功能。
关键区别在于_对竞争对手的刻意封锁_。WinAPI或许标注着大量“请勿使用谢谢”的功能，但微软从未阻止你发布使用这些功能的程序。
过去确实如此，但如今他们绝对这么干了 🙁
耗费大量时间复现某些功能，最终才发现Windows对特定API的调用存在应用白名单机制。
据我所知，仅PPL、禁用Defender和杀毒软件注册这三类API采用此类锁定机制，且均非微软专属——只需注册反恶意软件开发者计划并签署保密协议即可。
“请关闭Windows Defender，我是杀毒软件”这个API就是典型(且完全合理的)例子。
是吗？我在EDR产品领域工作了十年，Windows内部专家们总在讨论那些未公开的API参数
这并非关键区别——Windows当然可能拥有仅供内部使用的专属API。问题在于：当某些特殊内部API仅限Office使用而Lotus等无法调用，或仅限Edge浏览器使用而Firefox/Chrome等无法调用时——
抱歉，确实如此。需要澄清的是：这涉及将某市场产品的功能特性，刻意对其他市场的竞争对手进行封锁。
这并非限制，只是此类应用无法进入AppStore。软件分发渠道众多，苹果仍会提供联合签名或授权服务(如需)，只是不在AppStore内。
这似乎是种不必要且不合理的贸易壁垒。既无技术限制也无用户体验理由排除此类应用。
争议点不在此处；真正的争议在于这会形成某种“仅存在单一方法且被刻意保留”的假象，而事实并非如此。
我认为这很合理。真正该批评苹果的是其对网络标准的缓慢响应。当然可以辩称他们选择优先处理这类功能，但这种理由站不住脚。
即便如此，他们仍在努力改进。Safari在支持我真正需要的功能方面，正逐渐超越Firefox。
真正值得对苹果感到恼火的是其缓慢的网页标准实施速度。
如今Safari已支持HTML5日期选择器(自iOS 14.1起——五年前的事)，这更像是梗而非事实依据。除非你认为谷歌在Chrome中加入某项功能就自动使其成为“标准”。
我手头有一份Safari和Firefox支持但Chrome不支持的网页标准清单(可惜存放在当前无法访问的设备上)。这份清单对我至关重要：我负责的网站中有100%用户使用Safari(约800人)，另一网站则以安卓用户为主(约70%)。因此我需要一份功能对照速查表。
>>真正该对苹果感到恼火的是其缓慢的网页标准实施速度.
>如今Safari已支持HTML5日期选择器(自iOS 14.1起——五年前的事)，这更像是网络梗而非事实依据
苹果公司强迫 iOS 上的所有浏览器使用 Safari 浏览器引擎，他们故意不执行其他浏览器引擎早已拥有的 API，从而使 Safari 浏览器引擎步履蹒跚，这样苹果公司就可以强迫开发者为 iOS 开发原生应用程序，这样苹果公司就可以从中提取 30%(或他们今天决定的任何比例)的收入，而网络应用程序则无法做到这一点。这是苹果被司法部起诉违反反垄断法的众多原因之一，也是他们被欧盟起诉并败诉的原因之一。
https://www.justice.gov/archives/opa/media/1344546/dl
也许 5 年前确实如此，但现在他们加快了开发速度，对标准的支持也相当不错，比 FF 还好。同样，不算 Chrome 浏览器的 “EEE ”非标准 API，它们在很大程度上都能快速实现大多数现代 API。虽然 Chrome 浏览器在 Safari 拥有的一些以设计为重点的标准方面落后于 Safari，但缺少一些 PWA 标准也是合理的。
点击此处：
https://caniuse.com/?compare=chrome+143,safari+26.0&compareC…
请注意不支持的 Safari API，绝大多数都不符合网络标准。
也许你应该读一读司法部对苹果公司的诉讼。很明显，苹果公司被起诉的原因之一(在众多原因中)就是我所描述的滥用商业惯例。
苹果在 iOS 上强制使用 Safari 浏览器是今天的事，而不是 5 年前的事(但这也是 5 年前的事，自从有了 iOS 网页视图之后)。如果苹果不想实现它，那么他们就不应该强迫其他浏览器制造商使用他们步履蹒跚的浏览器引擎。
相对私有谬误。
"蒂米逃脱了惩罚。我也应该逍遥法外"。-小学生
在上世纪 90/00 年代，美国和欧盟对微软提起的反垄断诉讼中，DOS/Windows 中的私有/秘密 API 占据了重要位置。
> Windows 中的私有/秘密 API 是 90 年代/00 年代美国和欧盟针对微软的反垄断诉讼的一个重要部分。
这很重要，因为微软当时占据了 95% 的操作系统市场，并利用其垄断地位接管了网络，即使在与美国政府签署了体面的法令之后也是如此。
编辑：或许可以说，苹果公司在某一个或某几个领域是垄断者？
目前的网络垄断者(谷歌)恰好是在美国对微软的反垄断诉讼做出判决两个月后(1998 年 7 月至 9 月)成立的。
两周前美国对谷歌的诉讼结果也是如此。
> 也许可以说，苹果公司在一个或少数几个领域是垄断者？
我不认为这种说法可信。苹果在美国的智能手机市场份额充其量也就 55%，在其他大多数国家则要低得多。
请记住，垄断本身并不违法，违法的是利用垄断使竞争对手处于不利地位，尤其是在新兴市场，而这正是微软案的关键所在。
我不认为有任何法律依据表明苹果公司创造了一种只有他们自己才能使用的私人功能–目前–会给他们带来不公平的市场优势。
如果苹果在未来发布的 iOS 26 中将其作为一项公共功能，我也不会感到惊讶。
苹果迫使 iOS 上的所有浏览器都使用 Safari 浏览器引擎，他们故意不使用其他浏览器引擎早已拥有的 API，从而使 Safari 浏览器引擎步履蹒跚，这样苹果就可以迫使开发者为 iOS 开发原生应用程序，这样苹果就可以从中获取 30%(或他们今天决定的任何比例)的收入，而网络应用程序则无法做到这一点。这是苹果被司法部起诉违反反垄断法的众多原因之一，也是他们被欧盟起诉并败诉的原因之一。
https://www.justice.gov/archives/opa/media/1344546/dl
微软不会因为你使用这些软件而惩罚你。
等等，那么所有非标准 CSS 属性都是 “反竞争 ”的吗？这似乎有些夸张。
谷歌的“-webkit-tap-highlight-color ”也是反竞争的吗？我们是否应该禁止目前这种在提供专有 CSS 属性的同时，有时还提出将其标准化的做法？
我真的很难把这理解为合法的投诉。
如果你在应用中使用了这种 CSS 液体玻璃效果，苹果会将其拒之于 App Store 门外。
如果苹果在他们的应用程序中使用了这种 CSS 液体玻璃效果，它就能很好地通过 App Store 的审核。
你现在明白问题所在了吗？
iOS 有很多私有 API，这个也不例外。它在 WebKit 中实现的事实只是个幌子。
你没有回答你所回复评论的要点。
所以，当谷歌在网络浏览器引擎中创建自我服务的 API 时，它就是反消费者的，是在扼杀自由网络。
但当苹果在网页浏览器引擎中创建为自己服务的 API 时，这不过是另一种私人权利，是障眼法，是他们作为 Safari 所有者的权利。
我想，这位女士抗议得太多了。
不同的是，谷歌目前处于更加主导的地位，每一个使用 Chrome 浏览器专用 API 的开发者都进一步巩固了谷歌的主导地位。在浏览器领域，苹果是长期落后的亚军，影响力要小得多。
这个特定的 API 似乎也仅限于嵌入式网页视图(在 Safari 中无法使用)，因此与 Chrome 浏览器中的 WebUSB 等 API 不同，它对开放网络没有任何影响。
>它可以顺利通过应用商店的审核。
你有证据证明这种说法吗？有可能苹果公司或第三方开发者都无法使用它通过应用商店发布应用程序。
苹果公司为什么要为其第一方应用程序通过 App Store 审核流程？
因为维护一个摄取管道比维护两个管道更省钱。
而且，即使是手动流程，创建一条 “如果来自苹果，自动批准 ”的规则基本上也是免费的。
让应用程序包通过该流程的自动部分可能仍然有用。像 “未使用私有 API ”这样的检查对于避免意外的反竞争行为非常重要。在大型组织中工作，沟通是很困难的，因此防止出错的自动检查很重要。
如果您在应用程序中使用这种 CSS 液体玻璃效果，苹果会将其拒之于 App Store 门外。
需要引用。
博客文章对此进行了推测，但没有证据。
给您：
> 苹果应用程序审核指南》： 2.5.1 应用程序只能使用公共 API，且必须在当前操作系统上运行。
https://developer.apple.com/app-store/review/guidelines/
要启用 CSS 属性，必须在 webview 上启用以下(私有)字段。否则(根据作者的说法)，它将被忽略： https://github.com/WebKit/WebKit/blob/613c42873c56e2b2073f91…
如果你对苹果公司的规则和做法一无所知，请不要对此感到厌恶。苹果公司为 App Store 制定了开发者指南，其中规定不能使用私有 API！
除了他们自己写的内容，他们不会发布任何 “证明”。他们对规则的解释和执行都是随心所欲。
私人 API 在这里： https://github.com/WebKit/WebKit/blob/613c42873c56e2b2073f91… 它位于 WKWebView 上，与他们禁止访问的其他私有 API 相似
苹果公司绝对会拒绝使用私有 API 的应用程序。下面就是一个有名的案例，他们开始拒绝 Electron 应用程序使用私有 API： https://9to5mac.com/2019/11/04/electron-app-rejections/你可以坐等苹果公布证据，证明这种新的私有 API 与其他 API 无异，但你不应该去打扰别人，要求他们为你举证，因为他们不会对这种特定的 API 做出澄清，而且已经有了他们如何断然处理的先例。你也不应该散布虚假的信心，认为由于缺乏符合你自己标准的 “证据”，使用这些 API 是没有问题的，因为这不仅会导致应用程序被移除，还会威胁到开发者账户的终止。(即使这种情况很少发生)。
我知道这可能会让人感到困惑：他们不会始终如一地这样做，而且他们会随心所欲地改变执行方式。即使不是自动执行，如果他们要寻找惩罚的理由，他们也可以而且已经 “手工 ”仔细检查过了。这是一种责任。
你真的认为 CSS 选择器是一个私有 API？这要么是我对 CSS 和 API 之间的区别产生了天马行空的误解，要么就是我完全读错了你的帖子。但我又重读了几遍，似乎就是这个意思？
CSS 并不是问题所在，问题是 CSS 只能通过私有平台代码启用，而任何应用程序都无法获得批准。
您是点击了我的链接还是阅读了文章？私有 API 是 WKWebView 属性。
您可以在您的网站或 PWA 上使用 `-webkit-tap-highlight-color`，并以任何方式发布。只是它无法在 Firefox 等非 Webkit 浏览器中使用。
苹果的做法和文章中提到的一样： 他们有一个只有他们才能使用的 CSS 属性，您不能把它放到您的 PWA 中，它将无法工作(无论使用何种浏览器)。
他们刚刚在内部发布了这一功能。我们不知道他们对此有何计划。反正网络不会广泛地突然采用这样的功能。苹果很有可能正在研究如何让第三方开发者通过 safari 使用该功能。
这只是小题大做。
这个例子不好，因为“-webkit-tap-highlight-color ”最初来自苹果，而非谷歌。
我可以在 Windows、Linux 和 Mac 上安装 Chrome 浏览器，所以我给他们放行。更何况那已经是过去式了。
但你无法在 iOS 上安装 Chrome 浏览器引擎，因为苹果强迫谷歌使用 Safari 网页浏览器引擎，以及任何其他非 Safari 的 iOS 网页浏览器–它们在引擎盖下都被迫使用 Safari。
看来这里已经失去了逻辑。我想说的是，谷歌多年前使用非标准功能的事实，并没有迫使用户选择特定的平台，而这正是用户抱怨的地方。每个浏览器都有自己的特色。至于 “真正的 ”Chrome 浏览器是否可以在 iOS 上使用，以及苹果公司如何介入这个问题，则完全无关紧要。
我不确定这是否属于法律意义上的 “明显反竞争”。在美国，有关反竞争行为的法律是《谢尔曼法》和《克莱顿法》。对于反竞争行为，法院采用 “本身 ”规则和 “合理规则”。“本身 ”规则涵盖法律中明确列出的反竞争行为(如操纵价格)。
这种行为并不在 “本身 ”反竞争行为之列，因此需要用 “合理规则 ”来处理。这就需要有人证明对竞争造成了实际损害，而这种损害是由该行为的非法性质直接造成的，并且没有得到某种有利于竞争的利益的补偿，也没有限制性较小的替代办法。
我不明白 CSS 属性如何能达到对竞争造成实际损害的标准，尤其是因为如果你想自己制作液态玻璃 css，没有人会阻止你(据我所知)。
你对限制性更强的计算机硬件有何看法？例如，电子游戏机要求所有代码都必须经过加密签名，这意味着第三方未经游戏机制造商许可，不得发布任何软件。
我猜他们也不喜欢这样。
苹果做了很多坏事，而且很多比这更糟糕，但这并不意味着指出这件事也很糟糕就不公平了。
归根结底，“供应商可以用你的电脑做你自己做不了的事”。
>这一切最终都归结为 “供应商可以用你的电脑做你自己做不了的事情”。
甚至不是这样。一个游戏机厂商在 TPM 的帮助下锁定了一切，从而不与作弊者打交道，这可以说是没问题的。如果游戏机厂商同时也是游戏开发商，却对所有非自家开发的游戏设定 FPS 上限，那就是滥用自己在一个市场的垄断地位，在另一个市场上获取不公平的优势。
我也普遍反对这种做法。我同意穆罗梅克的回答，我认为在游戏机厂商不偏爱其第一方游戏的情况下，这种做法不一定是反竞争的，但在实践中，这三家厂商当然都这么做了。由于存在一个蓬勃发展的开放市场(PC 游戏)，这种情况得到了一定程度的缓解。
更广泛地说，不是基于反垄断的理由，而是基于产权的理由，我反对各种 DRM。首先，规避任何和所有 DRM/反复制措施都应该是合法的。其次，剥夺下一个拥有者的财产权，以便在产品售出后对其实施所有权控制，这应该是非法的。
如果我买了一台电脑，但什么也没做，只是在上面安装了一个键盘记录rootkit，然后把它卖给了别人，我理所当然要冒着坐牢的风险。“恶意软件是产品的一部分 ”不是一个有效的借口。DRM 也是恶意软件。如果发现现有法律不完善，就需要制定更具体的法律。
但目前还没有证据表明它被第一方程序使用，例如 GarageBand、Pages 或 Mail.app。
也很有可能是：a)根本没有使用，私有 API 只是用于内部测试，直到准备好公开；和/或 b)被某些不与第三方应用程序竞争的操作系统组件使用(例如设置面板中的某处)。
虽然我在理论上同意你的说法，但一些外观造型可能是你能想到的最不重要、最琐碎的例子了……我真的无法为_这个_问题而激动。
只有当你认为让用户界面文本无法阅读是一种优势的时候。
我不认为这是一种 “改进”，但拥有符合用户期望的图形用户界面无疑是一种商业优势。
的确，这扼杀了利用网络技术实现的糟糕设置面板的创新性。
我认为公司可以越过这样一条界线：使用锁定的外观设置使应用程序看起来像是来自公司。
例如，如果手机边缘有一个发光的灯，只有在使用股票应用程序和公司应用程序时才会亮起，而为了安全起见，这标志着某个应用程序属于某家公司，这也是可以的。
我不认为设计/外观是一项功能。YMD。
反竞争是坏事，统一标准是好事。
看看 m3/4 macs，它们都是疯狂的机器，因为连硬件都是统一的。
统一是什么意思？Strix Halo 就是 “统一”。M 系列平台并不是唯一的统一平台。
公开这个 CSS 扩展会对平台的统一性产生什么影响？
根据 Chrome 浏览器的其他主题，我们确实需要确保苹果保持对 iOS 浏览器的独家垄断，以防止这些事情发生。对不对？对不对？
Safari 浏览器中没有这个功能。
人们真的认为苹果是 “好人 ”吗？
技术始终是一门生意。这条评论所引出的是那些把首选技术选择视为某种道德游戏的人。其实不然。从来都不是。相信这种东西太幼稚了。
不想使用那些看起来像是为吸引 2-8 岁儿童而设计的东西就是道德问题？
嘿，别再欺负万亿美元的公司了！他们是我最喜欢的公司，他们的行为毋庸置疑 >:(
这篇文章不是说他们添加了一个新的 css 元素，但其实并不局限于苹果应用程序，只是还没有出现在文档中。
不，上面说是受限的。你需要在 webview 上设置一个私有属性才能启用它。如果您与私有 API 进行交互，您的应用程序将在审核中被拒绝。
我明白，虽然只是猜测(在苹果工作多年)，但这似乎是一个即将被记录在案的 “功能”。
这怎么会带来优势？
在 Electron/Tauri 和 React Native 应用程序中，这不是应该很容易实现吗？
Electron 不使用 WebKit，所以肯定不行。不清楚 Tauri 桌面应用的情况，但你如何在 Tauri 移动应用和 React Native 应用中使用它？
哇，TIL。Chromium 显然在 2013 年分叉了 WebKit。
因此，如果您想使用能利用这一点的网络视图，基本上需要一个带有网络视图的本地 swift 应用程序才能访问。
即使你能获得它，你也无法在 App Store 上发布它，因为它需要权限。
React Native / Expo 应用程序可以通过实际的底层本地ui 元素获得液态玻璃。
苹果是如何阻止三星为 Android 开发应用程序的？你在读什么教科书？
HN 拥有世界上最多的业余律师在线人群之一，他们的一些法律意见是最不正确的。这是众多例子中的一个。
苹果公司在自己的网页和应用程序上与谁竞争？一些闪闪发光的反思(顺便说一句，也可以通过自己编写效果图来实现)能给他们带来多少竞争优势？这一定是个很大很明显的问题，否则不可能是违法的，但我想不出来。
如果你指的是 “反竞争”，而不是垄断，那么，每家公司都会这么做。
谷歌或任何开源地图产品。实际上，如果我们以美国国会众议院批准的 DOJ 诉 MSFT 同意令为先例，任何不能使用这一私有 API 组件的应用程序都将成为受影响方。
我是一个反垄断方面的书呆子–自从我十几岁时为了从有趣的案件中获取文件而创建了第一个 PACER 账户以来，已经有 20 多年的时间了……
人们所说的 “反竞争 ”或 “垄断 ”95% 都与法律无关。人们不知道这些词的法律定义，只是凭感觉乱用。
然而，这是一个非常非常明显的违反先例的案例。如果我们看看微软的终审判决https://www.justice.gov/atr/case-document/final-judgment-133，可以看到 F(1)(a)、H(2)(b)，虽然这些规定并没有适用于苹果公司，但如果我处于市场支配地位，我就会超级小心像无文档 API 这样的任性限制，以及模仿被视为可对类似市场支配力量进行制裁的活动模式的行为。
这是一种比第三方更容易让基于网络视图的应用程序看起来更 “原生 ”的方式。如果你试用第三方应用时，发现它在视觉上的集成度不如类似的第一方应用，那么后者就会因此获得竞争优势。
> 苹果在自己的网页和应用程序上与谁竞争？
与其他所有使用网页视图的应用。
> 没有提到垄断
当然是垄断。Safari 仍然 “享有特权”，是强制默认浏览器。苹果公司保证，要做出一个替代方案是非常困难和昂贵的。因此，对任何类型的第一方功能进行限制都是大忌。
我喜欢 “阿拉斯泰尔的应用内网页视图大理论”：
应用程序中的网络视图之所以名声如此之差，主要原因是你没有注意到无缝集成的网络视图。
我认为另一个分歧在于
– 走过网络视图之路的人，他们知道要做好网络视图有多难
– 被告知可以简单地将网络应用程序打包成本地应用程序的人
你大概能猜到哪一类人更多
这可能正是添加这个功能的原因。要判断某人是否使用了第三方用户界面工具包，最简单的方法就是开始调整系统主题，看看应用程序是否正确遵循了某些缩放/颜色变化。
在这种情况下，苹果提供的某些应用程序子集没有遵循主题，他们通过添加一个私有 css 属性来解决这个问题。
与之相比，其他一些操作系统供应商可能会移除大部分主题控件，这样他们就不必继续修复散落在其产品组合中的一大堆半成品废弃工具包了。
如果你能说出_一个无缝集成的 webview，我就承认。也许普通人不会意识到这一点，但我想我们会在这里看到很多关于它的文章。“但 Foo 是作为网络视图实现的，所以它是可以做到的”，这将是对每一个网络视图辩论的标准反驳。
"所有的假发看起来都很假。我从来没见过看不出来是假的"。
“The Toupée Theory of In-App Webviews ”非常完美。我可能会在帖子里改一下。
顺便说一句，我认为个人署名给人一种很好的感觉。
“Alastair's Toupee 的应用内 WebView 理论”？
完全同意兄弟姐妹的评论，你应该拥有它！这让我想起了那句话，哈哈。
你的 OP 写得真好！请继续保持。
谢谢！我希望能继续沿着这条路走下去，写出一些关于如何真正实现应用内无缝网络视图的想法，但是……时间问题。
与此同时(嘿，这已经是一个自我宣传的主题了)，我上一次写的是关于 WKWebView 在使用硬件加速 CSS 变换时生成的本地视图：
https://alastair.is/learning-about-what-happens-when-you-use…
读起来很不错！谢谢！
运行
还有一个推论是，你不会注意到那些并不突出但感觉不对的网络视图。比如，有人提到 MacOS 中的设置应用可能会使用它们，因为图标加载速度不够快。
我不禁有些感慨。苹果公司曾经疯狂地追求完美。想想最初在 Mac 上设计圆角屏幕时的心态吧。这太疯狂了，我很钦佩。
> 苹果曾经疯狂地追求完美。
我觉得这更多是品牌叙事/神话。MacOS在任何时期都存在缺陷。
说得没错。我从小就喜欢Mac电脑，但尽管有些人对80、90年代的经典macOS怀有玫瑰色滤镜般的怀念，每当我在杂乱笨拙又狭小的Chooser界面操作时，总会忍不住感到刺痛般的痛苦。
> 显然苹果若不用这项功能就不会开发它。具体在哪？我们完全没头绪。
若要猜测，可能藏在设置应用里的iCloud选项中，也可能在App Store/音乐/电视应用的账户页面(点击右上角头像进入)。许多页面都隐藏着伪装成原生应用的网页视图，主要用于加载iTunes后台服务的内容(通常长按链接会弹出网页预览就是破绽)。它很可能也用于“技巧”应用内的用户指南。
至少我会从这些地方着手寻找。
> 显然苹果若不用此功能就不会开发它。具体用在何处？我们无从知晓。但它必定存在于某个角落。我们从未察觉其确切位置的事实，恰恰说明我们在日常使用iOS时，早已在不知不觉中与WebView交互。
这点让我印象深刻。我从未怀疑过WebView的存在，现在也想不出具体应用场景。
我常怀疑设置中的某些内容(尤其是账户/iCloud部分)是网页视图，仅凭它们的加载方式就能判断(例如图标在页面打开后短暂延迟才出现)。
没错，设置应用的这些部分正是通过嵌入React Web的网页视图构建的：
https://news.ycombinator.com/item?id=30648424
原来如此，难怪它们体验糟糕，经常崩溃却不显示错误信息也无法修复
点击“保存到iCloud”部分的某些菜单项时，它们没有设置应用其他部分常见的灰色选中效果。
App Store应用似乎大量使用了WebView。
并非如此。苹果几年前曾大张旗鼓地宣传过这项技术转型。
邮件和日历应用都使用WebView作为基础框架。
我猜他们会在Apple.com网站上采用类似方案，就像早期iOS系统用backdrop-filter模拟磨砂玻璃效果那样。
根据帖子描述，Safari浏览器中并不存在这种现象
我相当确定Apple Music大量使用了WebView。
实际上并非如此。它曾经使用过，但后来被重写了。如果你想验证，可以使用辅助功能检查器应用查看UI元素的类名。
我觉得可能还是会。我经常在笔记本上用它，偶尔网络出点幺蛾子时，整个视图面板就会用那种经典的无CSS Times New Roman字体提示内部服务器错误。你有这个问题的出处吗？
我敢肯定像Apple Store应用和App Store部分功能这样调用网页视图的应用有很多。这很可能是其设计初衷。新闻、音乐、游戏等应用的部分功能也可能采用类似机制。
发现得真棒！
苹果的新玻璃界面似乎招致不少批评，但我…反而有点喜欢？它让操作系统重新有了个性，不再只是扁平乏味的界面。现在点击目标的大小一目了然，按钮终于再次与文字形成视觉区分。我认为这是值得欢迎的改变，绝非单纯怀旧——它确实提升了实用性。
我提前安装了iOS 26测试版，以便在正式版发布前测试我维护的网站。虽然存在零星问题，但系统重塑个性的整体方向值得肯定。普通用户会爱上它。
我欣赏玻璃质感效果和美学设计，但许多应用的功能性不如从前。原本触手可及的按钮如今深藏于菜单中，更难寻觅。
这始终取决于可发现性的难度。例如设计Apple Watch这类设备时，可用空间极其有限，因此要么压缩内容，要么通过手势或菜单实现其他功能，只展示最重要内容。
移动应用减少直接可见的UI元素并非全然不利。像iOS相机按钮滑动功能这类新UX概念的难点在于其新颖性——用户无法立即熟悉操作，且不同系统功能并未统一采用该设计。
对Liquid Glass的批判或许应推迟一两年。变革总是伴随风险，需要时间全面铺开，更需生态系统广泛接纳。
我在Safari浏览器注意到书签图标操作从单击变为双击。所幸可通过设置切换标签页布局(具体含义不明)恢复原状
我怀疑普通用户普遍不会喜欢它，主要原因在于只有技术宅才会认为操作系统需要“个性”。大众思维模式截然不同——对多数人而言，系统只是实现目的的工具，任何偏离此本质的设计，充其量只是最初几天的新奇玩意儿。
我最讨厌液态玻璃设计的一点，就是苹果在所有原生应用中新增的底部标签栏。Apple Music的改动尤为糟糕——现在要在搜索界面和其余四个标签页(主页、新歌、电台、音乐库)之间切换，必须额外多点一次。点击搜索后，还得再次点击搜索框才能调出键盘。所有交互都配有极其复杂且迟缓的动画效果：例如在主页点击“库”标签时，标签栏会滑出一个气泡状动画，膨胀至超出标签栏边界，同时呈现中间标签与底层内容——这种毫无意义的视觉干扰极其分散注意力。在最新版本中，无论开启“降低透明度”还是“减少动态效果”，都对这些动画毫无影响。
事实上，苹果自家应用似乎都忘了“减少透明度”和“减少动态效果”这两项辅助功能的存在，即便启用了这些功能，实现效果也敷衍了事。例如，启用“减少动态效果”后，点击Apple Music中的专辑会触发更微妙的动画(良好)；点击返回按钮时同样采用这种微妙动画(良好)；但从左侧滑动返回时，却会使用关闭该功能时才会出现的繁复多余动画。Apple Podcasts同样存在此问题。据我观察，iMessage完全无视“减少动态效果”设置，界面毫无变化；而其实现“减少透明度”的方式也与众不同——并非像其他应用那样降低透明度，而是给所有透明元素都覆盖了一层纯黑背景。iOS系统中此类案例不胜枚举，距离正式发布仅剩数日； 例如Apple Notes或Apple News的汉堡菜单[…]在“减少动态效果”下本应减少动画，却毫无变化；当键盘按钮失效时(如Apple News→搜索→空搜索框)，Enter键会以错误的灰色显示且几乎不可辨识——仅当启用“减少透明度”时才会出现此问题，类似案例不胜枚举。
> 似乎只有技术宅才会认为操作系统应该具备“个性”
我不太确定。情况甚至可能恰恰相反。技术人员和设计师为我们带来了扁平化界面美学、Material UI、Windows Metro设计等。技术人员对设计和美学的挑剔程度也远超普通人。技术人员和设计师曾嘲笑Windows XP，但相比“枯燥”的前代设计，大多数普通用户认为它“可爱”且“有趣”。就用户界面而言，这无疑是过去30年最令人难忘的版本。经历多年扁平化设计后，这个iOS版本或许会成为类似的里程碑。
不过你提到的bug/瑕疵确实值得关注，我也注意到某些用户体验改动令人存疑。这是iOS多年来的首次全面界面重构，相信这些问题会随着时间逐步完善。
我不这么认为。大众往往因新事物而欣喜雀跃，因为他们相信新事物必然优于旧物。即便操作系统只是表面翻新，掩盖了数十年的陈腐(如Windows 11)，人们仍会为炫酷的视觉革新所吸引。
> 现在点击目标的大小一目了然，按钮终于能与文字视觉区分开来了
标准很高啊
确实如此，但苹果是自作自受。他们最初的扁平化界面也因此招致诸多批评，尤其来自关注无障碍设计的群体。
算我一个，我完全同意“这设计简直糟糕透顶！”的观点，还有“苹果你们到底在想什么？！”的质疑。
简直不堪入目。
或许他们暂时不希望用户使用这个功能？
我敢肯定他们清楚，随着最新操作系统的发布，很多人会立刻想用这个功能，也许他们想先在内部测试公开使用的情况？
这个帖子里确实有些毫无根据的指控。也许他们是对的？也许他们是错的？
> 显然苹果若不用这项功能就不会开发它。在哪里？我们无从知晓。但他们必定在某个地方使用着。
为什么他们必须在某个地方使用？普通软件里废弃代码和功能的数量简直离谱。他们可能已经改了五次方向，这个CSS属性在第二次版本出现，到第四次就弃用了…
但愿这种液态果冻效果别成为潮流
无论你爱恨液态玻璃效果，从“UI边框包裹应用内容”到“UI覆盖应用内容”的范式转变似乎代表未来。这种设计与AR技术高度契合，更能根据不同屏幕尺寸分离UI布局与内容呈现。
我对这个初始方案持中立态度(优缺点并存)。但我认为这种设计思路终将被普遍采用。好消息是，覆盖式UI模型并非必须透明——部分界面可能采用不透明设计，但仍会保持悬浮效果。
我不认同。
首先，增强现实技术目前充其量只是理想状态。数十年的失败尝试已证明其局限性。
其次，在内容上叠加半透明UI反而会加剧界面与内容的割裂感。
二十年前Windows Aero就尝试过这种设计，虽然视觉效果炫酷，最终还是被弃用了。
https://en.m.wikipedia.org/wiki/Windows_Aero
VR仍属理想阶段，但AR已悄然渗透各领域。每当你在餐桌看到菜单二维码时，其实正在体验某种AR：手机呈现的画面与你肉眼所见截然不同。游戏领域虽有尝试，但似乎只是昙花一现的潮流，如同3D电视。
我明白，这几乎算不上AR…但尽管我热衷追踪尖端科技，总体而言我庆幸这类技术正缓慢推进。
二维码根本不属于增强现实范畴。“QR”仅是一种数据编码格式，它并未以任何形式增强现实。
二维码在AR中的唯一相关应用是偶尔作为锚点使用，但二维码本身并非AR技术，它仅仅是锚点载体。AR领域使用的锚点类型多种多样，并非都依赖二维码。
当你用手机对准二维码时，若看到其中弹出3D物体，这同样不属于二维码实现AR——那是二维码编码的数据，手机根据数据执行相应操作。同样地，一个标识也能触发AR设备执行相同操作，任何被AR程序识别的标记都可实现此功能。二维码之所以便捷，在于其能编码多种数据类型，扫描程序可据此对二维码中的数据内容作出响应。
> 似乎预示着未来
请务必提供依据。缺乏上下文支撑，这不过是空想推测。
苹果确实对AR未来投入颇深。但用户并不买账——ARKit集成寥寥无几，《精灵宝可梦GO》已成过气潮流，Vision Pro的失败程度堪称苹果当代产品之最。苹果更像是苦苦等待传球而非主动出击。而整个行业似乎乐于忽视AR领域，转而投资英伟达等非苹果股票。与此同时，苹果放弃了在Khronos等联盟中的股份，表明其缺乏参与新软件标准制定的意愿。
面对如此多的阻碍，我实在不明白你怎么会得出“强迫用户接受AR是优选方案”的结论。
“似乎”表示推测
年轻一代痴迷于Aero/Glass界面及那个时代的审美。这必然成为潮流——即便不是出于怀旧，也因为苹果开创了先河，而整个行业除了“照搬苹果设计”外已丧失所有创新力。
作为Aero主题的拥趸，我希望谷歌能推出自己的Aero风格主题来模仿苹果设计。
虽然希望苹果能改进可读性与对比度等细节，但比起Windows 8时代单调的扁平化设计，任何改进我都欣然接受。
天啊，我竟没意识到Windows Vista如今已近二十年历史。它和Windows 7在我心中依然充满“现代感”。
真希望别搞那么多弹跳抖动效果。这让界面从玻璃质感变成了凝胶状的黏糊糊东西。
同感——虽然希望不会，但基本确定会跟风。苹果这么干了，其他公司肯定会跳上同一辆车。
已经有了
> 你得在WKPreferences里切换一个叫useSystemAppearance的设置…而且这是私有设置。所以要是用了，就跟App Store审核说再见吧。
这是真的吗？我对iOS开发知之甚少，但我发誓记得看过某个应用的反编译视频，它利用各种内部API实现了动态主屏幕小部件。
这种做法绝对过不了App Store审核。
要看具体实现方式。
想到的是youtube.com/watch?v=NdJ_y1c_j_I 这种效果？
这是继圆角和超大内边距后最丑陋的设计潮流。只能祈祷它终将消失不再作祟。
说真的，为什么不干脆把它作为CSS属性加入Safari？
我敢肯定会有大量网站试图复刻液态玻璃效果，而这种实现方式会吃掉你笔记本一半的CPU资源。
正如文章所言，若将其纳入CSS规范，根据浏览器支持情况灵活切换样式将变得极其简单。况且其他浏览器也常有“非标准”操作。
我并非痴迷液态玻璃效果并要求无处不在，但比起在Safari上看到定制版——那种未经优化的卡顿粗糙版本，我更希望看到标准液态玻璃效果的全面应用。
> 说真的，为什么不直接把它作为CSS属性添加到Safari里？
未来可能会有，但目前仍在讨论API或实现方案。
有趣的是，使用WebView是实现许多功能的常见捷径，即便是原生应用偶尔也会出于便利(有时是必要性)而嵌入WebView(你可能甚至不会察觉)。
苹果自身就面临着同样的情况，他们为自己开发了折中方案，却同时要求第三方开发者不得采用相同的折中方案——若想获得液态玻璃效果，就必须使用苹果的原生UI。..
Liquid Glass图标效果糟糕透顶，在iOS上更是漏洞百出。
这和Codepen演示的效果有何区别？
https://codepen.io/GreggOD/pen/xLbboZ
两者都是玻璃质感效果。若想了解差异，建议观看WWDC专题“探索液态玻璃”。
Mapbox真是款精美的软件。
“液态玻璃”……你指的是Windows 7在2007年左右实现的效果？
不，Windows 7当时确实实现了玻璃质感，而这只是带营销噱头的模糊效果。
色差可不是模糊
这似乎不止是模糊，还存在折射等光学效果。但本质上仍是营销噱头的模糊效果。
不，Mac OS X早在2001年左右就实现了。
液态玻璃效果究竟是什么样？
> 苹果公司那位决定将此设为CSS属性的家伙堪称天才，因为这让根据Liquid Glass支持情况提供不同规则变得异常简单
这哪里是天才？创造了没人需要的东西，还搞了个专属CSS属性在认证应用里强制使用。天才？我只觉得这是卑劣伎俩。
根据CSS规范，他们本可实现许多功能，却偏要耗费人力搞这种破玩意儿。没错，他们是商业机构，自有权处置资金。但我讨厌他们的选择。
> 创造无人问津之物
其实是他们的UI团队要求的，目前仅限内部使用，作为最新UI风格的一部分。
现阶段这类功能简直像是在逼老款设备用户升级——让旧机型连基础UI操作都卡顿，从而迫使用户换新机。
给那些搞不懂“液态玻璃效果”是什么鬼的人科普：这是苹果UI采用的一种磨砂玻璃质感。
这玩意儿被吹捧得像切片面包问世以来最伟大的发明。谷歌搜索相关信息时，感觉自己闯入了平行宇宙。
小演示：https://youtube.com/shorts/-2KaGU8G_vE
Windows 7十五年前就做到了
Windows 7的设计更有个性。
Windows 7围绕其构建的设计语言中，透明效果从未成为核心卖点。
这很明智。对比度才是关键，尤其在消费级硬件上——毕竟年迈的奶奶可能视力不佳。吸引用户并非Vista或Yosemite的玻璃特效，而是高对比度UI元素与拟物化设计(而液态玻璃效果兼具这两者)。
> 应用内网页视图饱受诟病的主因在于：那些无缝集成的网页视图反而令人浑然不觉。
我推测 iOS/macOS 应用商店应用及音乐应用，其动态布局内容很大程度上依赖于这类无缝网页视图。
他们是否提供了防止模态框被Safari工具栏截断的CSS特性？
他们想用USD和<model>标签实现的功能同样糟糕。
> 应用程序中WebView声名狼藉的主因在于：那些无缝集成的WebView往往不被察觉
确实如此，十年前我注意到这个问题后就退出移动应用开发领域，彻底删除了相关经历转投其他开发领域
不过这类需求居然还存在着，令人惊讶。但涉及手机端时，我发现现有替代方案已足够完善
> 但是我的建议是：应用程序中的网络视图之所以名声如此之差，主要原因是你没有注意到无缝集成的网络视图。
集成是一回事。
更重要的是资源消耗： 以 Steam 为例，它总是从我宝贵的 RAM 中抽取 300MB 用于两个在任何地方都不需要的网络视图进程，而早期版本实际上提供了一个标志来禁止网络视图启动。在安卓系统上，使用 WebView 的应用程序通常会导致所有其他应用程序 OOM，或者在最糟糕的情况下，应用程序本身也会从自己的 Web 视图中 OOM，当 Web 视图的任何用途完成后，会产生非常奇怪的副作用。
永远不为本地开发应用程序的又一个理由