Liquid Glass forces redesign of iOS apps, according to updated HIG

Since Apple introduced Liquid Glass in 2025 alongside iOS 26, much of the product teams treated the material as just another visual coat of paint: swap some frosted backgrounds for translucent glass and move on. The Materials page of the Human Interface Guidelines, updated on September 30, 2026, makes clear that it isn't quite like that. The document formalizes a layering model that redefines where each interface element can (and cannot) live, along with a contrast system that no longer accepts fixed color on top of translucent material.

For those who design or maintain iOS apps, this means reviewing depth tokens, contrast tokens, and even the list of components that the design system considers "standard". Ignoring this update won't break the app, but it will make visible the difference between those who followed the guideline and those who just swapped the background color.

Two layers, two different rules

The HIG separates the interface into two layers with distinct functions. The functional layer, which includes tab bars, sidebars, and navigation controls, uses Liquid Glass and floats above the content, allowing it to scroll and appear behind the controls. The content layer, where text and primary information live, uses the standard materials (ultraThin, thin, regular, thick).

The rule most people will forget to apply: the guideline explicitly says not to use Liquid Glass in the content layer, because that creates confusing visual hierarchy. The only exception foreseen is transitory, interactive controls, such as sliders and toggles, which can take on the Liquid Glass appearance only while the person is interacting with them. Beyond that, if an element is competing with the content for attention, it's in the wrong layer.

The complementary guidance is to use the effect sparingly: system components (such as SwiftUI's) already inherit Liquid Glass behavior automatically, and applying the material to custom controls should be restricted to the most important functional elements on the screen. Stacking the effect across several custom controls tends to distract from the content, which is exactly what the material should be highlighting.

Regular or clear: a choice that depends on the background

Liquid Glass has two variants, and choosing the wrong one is the fastest way to lose legibility. The regular variant blurs and adjusts the luminosity of the background content to keep text legible; it's the one most system components use, and the recommended choice for text-heavy screens, such as alerts, sidebars, and popovers. The clear variant is highly translucent and prioritizes visibility of what's behind it, designed for controls over photos and videos.

The detail that often gets overlooked in redesigns: using clear over a light background requires a darkening layer. The HIG recommends a dark layer with 35% opacity when the content behind is bright; if the background is already dark, or if the app uses AVKit's standard playback controls (which already include this layer built in), the extra darkening isn't needed.

Vibrancy: the end of fixed color on top of material

The point that most affects the work of those who maintain color tokens is the recommendation against choosing a material or effect for the color it appears to give the interface. Since system settings change the material's appearance in real time, a fixed color (such as systemGray3 applied directly to an icon) tends to lose contrast depending on the background. The recommended solution is to use the system's vibrant colors, which automatically adjust to the material underneath.

In iOS and iPadOS, the HIG defines vibrancy layers with names that indicate the expected contrast level:

• UIVibrancyEffectStyle.label (standard contrast, highest)
• UIVibrancyEffectStyle.secondaryLabel
• UIVibrancyEffectStyle.tertiaryLabel
• UIVibrancyEffectStyle.quaternaryLabel (lowest contrast; avoid over thin and ultraThin)

For fills there's a similar scale (fill, secondaryFill, tertiaryFill), and separators have a single vibrancy level that works on any material. In practice, this pushes the design system from "text color = fixed hex" to "text color = semantic role", because it's the system, not the static design token, that decides the final rendered value.

The same material, different behaviors per platform

The guideline doesn't treat Liquid Glass as a single component replicated across every platform; each operating system uses the material its own way. In tvOS, for example, elements like buttons and image views adopt Liquid Glass when they gain focus, and the material appears in system experiences such as Control Center. In visionOS, windows use by default a material called _glass_, which isn't configurable and lets light, environment, and physical objects show through the window, with the explicit recommendation to prefer translucency over opaque colors so as not to block the perception of the surrounding space.

In macOS, the system offers standard materials with defined purposes and vibrant versions of all system colors, accessible via NSVisualEffectView.Material, plus two background blending modes (behind window and within window). Anyone maintaining a multiplatform app can't just copy the same set of tokens from iOS to macOS or visionOS: the API is similar, but the semantics of each material change depending on the platform.

What breaks, and when it isn't worth it

Apps with custom chrome in solid colors, fixed navigation bars, or hardcoded palettes are the ones that suffer most from the update: they don't inherit Liquid Glass's automatic behavior and end up visually out of step next to apps that followed the guideline, especially under accessibility settings like reduce transparency or increase contrast, which alter the appearance of both variants of the material.

In short: not every app needs to rush to adopt Liquid Glass everywhere. Strongly branded apps, such as games or experiences with their own visual identity far removed from the system's, can deliberately keep custom chrome in the content layer, as long as they still respect the user's accessibility settings. The problem isn't refusing the material: it's applying it halfway, with the functional layer in Liquid Glass and the content layer still stuck with old colors and materials, because that's when the inconsistency becomes more visible than the complete absence of the effect.