Fidelity notes
How Liquidify reproduces Apple's Liquid Glass design language and how that fidelity is verified.
Liquidify renders Apple's Liquid Glass material — the translucent, optically active surface introduced across Apple's 2025 platforms — as pure CSS and SVG in the browser. The goal is SwiftUI-grade fidelity: a Liquidify control should read as the same material a native app would show, not an approximation dressed up with a blur.
The design language
Liquid Glass is a layered optical material, not a flat colour with transparency.
The @liquidify/glass engine composes it as a four-layer stack — a backdrop frost,
a refracted tint, a specular highlight, and the content plane — so a surface bends
and lights the content behind it the way a physical lens would.
The material comes in three grades, selected through the Material provider or a
component's material axis:
frosted— the most opaque, for surfaces that must stay legible over busy content.regular— the default balance of translucency and legibility.clear— the most transparent, for light chrome over calm backgrounds.
Grouping, elevation, and emphasis are expressed through material and depth, exactly as they are in the native design language. Material is never a substitute for semantics — see Accessibility.
Design intent comes from the HIG
Every component's geometry, motion, and state treatment traces back to Apple's Human Interface Guidelines as the design-intent authority. Sizes, corner radii, control heights, and interaction timing follow the platform vocabulary so a control feels native in proportion and behaviour, not only in surface.
How fidelity is verified
Fidelity is not judged by eye against screenshots pulled from the web. Each component is graded against an authentic reference: the same control rendered by the platform's own Liquid Glass implementation on a device simulator, captured in both light and dark appearance over a demanding diagonal background. Liquidify's render is then compared to that reference for perceptual parity, and the committed visual baselines lock the result so regressions are caught automatically.
That reference material is a private part of the build process. This documentation describes the process abstractly and never ships or embeds the captured frames — the public surface is the component, its behaviour, and the parity it achieves, not the oracle used to reach it.
Progressive rendering
The complete optical path depends on modern CSS and SVG filter support. Browsers that cannot apply the full filter stack still receive the backdrop frost and a static specular treatment, so the material degrades gracefully rather than disappearing. Component semantics, state, and layout never depend on the richer optical path. See Browser support for the declared floors and the fallback posture.