Apple has a private CSS property to add Liquid Glass effects to web content

Original Article ↗ Hacker News Discussion ↗

Where Apple Uses WebViews

  • Several comments point out that parts of iOS and macOS already use hidden webviews: iCloud sections in Settings, parts of App Store / Apple Store / Music / News / TV, some Mail and Calendar content, and various account/profile pages.
  • Some of these areas feel subtly “off” (delayed icon loads, unusual tap highlights), reinforcing the idea that well‑integrated webviews are mostly invisible, while bad ones are noticeable.
  • There is disagreement over how much Apple Music and App Store still rely on webviews; some say they were rewritten natively, others still see server‑error pages and web-like behavior.

Private Liquid Glass CSS & App Store Rules

  • The effect is controlled by a private WKWebView preference (useSystemAppearance); without enabling it via private API, the CSS is ignored.
  • Using private APIs is explicitly banned by App Store guidelines, so third‑party apps can’t legally ship this, even though Apple can use it internally.
  • Some see this as a typical internal-only OS feature that may later be documented; others view it as a deliberate way for Apple’s own webview-based UIs to look more “native” than competitors’.

Is This Anticompetitive? Legal and Policy Debate

  • One side calls this a textbook case of leveraging OS control to advantage first‑party apps, drawing parallels to Microsoft’s past use of secret Windows APIs.
  • Others argue:
    • Private APIs per se are normal; they only become an antitrust issue when tied to monopoly power and actual harm to competition.
    • Apple’s mobile share and the cosmetic nature of this feature make it unlikely to meet legal thresholds under U.S. “rule of reason” standards.
  • A counterargument is that the real harm is cumulative: Apple forbids alternative browser engines on iOS, then withholds capabilities from the only allowed engine.

Safari, Web Standards, and Engine Lock‑In

  • One thread argues Safari’s standards support has largely caught up and is even better than Firefox in places; Chrome is criticized for non‑standard “EEE” APIs.
  • A conflicting thread insists Safari is still “hobbled” by missing modern APIs and, more importantly, that forcing all iOS browsers to use WebKit is the core problem.
  • There’s back‑and‑forth over whether nonstandard APIs (e.g., Chrome-only features) are comparable to Apple’s entirely private, App‑Store‑blocked hooks.

Liquid Glass Aesthetics, UX, and AR Framing

  • Reactions to the new glass look are polarized:
    • Fans like the return of “personality,” clearer button affordances, and nostalgia for Win7/Vista‑style glass.
    • Critics call it unreadable, gelatinous, gaudy, and sometimes buggy or inconsistent with accessibility options (e.g., Reduce Motion/Transparency).
  • Some see the overlay‑on‑content UI as aligned with an AR‑centric future; others dismiss this as conjecture, noting weak AR adoption and Vision Pro struggles.

Webviews’ Reputation, Performance, and Future

  • A “toupee theory” emerges: users only notice bad webviews; seamless ones go unnoticed, so webviews get an unfairly bad reputation.
  • Others point out real drawbacks: heavy RAM usage, OOM issues on Android, and poor behavior from many hybrid apps shipped as shortcuts.
  • Several commenters suggest Apple built this specifically to make its own webview-heavy apps visually match native Liquid Glass, while third parties are pushed toward full native UI.
  • Some hope Apple will eventually expose the CSS property in Safari, to avoid sites re‑implementing the effect in slower, CPU‑heavy ways; whether that will happen is currently unclear.