Apple introduced Liquid Glass and the Xcode 26 beta at WWDC25. The first iOS 26 and SwiftUI APIs were beta software, so names, availability, behavior, and visual tuning could still change. The useful work is to understand hierarchy and create a reversible experiment—not to promise production pixels from the first seed.

Treat glass as an interaction layer

Liquid Glass is most legible when it separates navigation and controls from the content they operate on. Toolbars, floating actions, tab interfaces, and transient controls are natural candidates. The photograph, document, list, or data visualization underneath should remain the visual subject. A quick hierarchy sketch can expose that distinction before any material or animation code is written.

Applying glass to every list row, card, background, and button removes that distinction. It also creates more transparency and contrast work. Before adding any custom effect, let standard system components adopt the new design through the SDK. NavigationStack, toolbars, sheets, and standard controls already carry platform decisions about shape, motion, and accessibility.

Use a custom glass treatment only when a custom control genuinely occupies the same interaction layer:

struct AddButton: View {
    let action: () -> Void

    var body: some View {
        if #available(iOS 26.0, *) {
            Button(action: action) {
                Label("Add", systemImage: "plus")
                    .padding(.horizontal, 16)
                    .padding(.vertical, 10)
            }
            .glassEffect(.regular.interactive(), in: .capsule)
        } else {
            Button(action: action) {
                Label("Add", systemImage: "plus")
                    .padding(.horizontal, 16)
                    .padding(.vertical, 10)
            }
            .background(.thinMaterial, in: Capsule())
        }
    }
}

The availability branch preserves the same action on older systems. Do not infer support from a device model or parse an operating-system string; use #available. During the beta, keep the new implementation behind a small component boundary so an API change does not spread across every screen.

The exact beta syntax must be checked again against the SDK used to ship the app. A June code sample is a historical example, not a substitute for the final release notes.

Remove old decoration before adding new material

Placing glass over an existing card style often produces duplicate shadows, strokes, corner treatments, and materials. Audit the old surface first. Which decorations compensated for the previous navigation hierarchy? Which communicate a brand or a domain state? Remove redundant chrome, keep meaningful information, and only then evaluate the new material.

This sequence is safer than stacking modifiers until a screenshot looks close to a keynote frame. It also gives the application a cleaner fallback on older systems.

Content behind glass affects contrast. Test over photographs, dense scrolling content, light and dark appearances, Increase Contrast, and Reduce Transparency. Text and symbols must remain distinguishable in the least favorable state, not only over a hand-picked demo background. Color cannot be the only indicator of selection or error.

Use motion to preserve continuity

Morphing material can explain that a control moved, expanded, or joined a group. It should not turn every tap into a performance. Preserve stable identities and avoid changing position, size, color, and hierarchy simultaneously. Enable Reduce Motion and verify that a simpler transition still communicates the state change.

Performance needs device evidence. Several blurred layers over scrolling content with continuous animation may behave differently on a simulator and on supported hardware. Profile frame pacing and energy use with Instruments before deciding how much glass or motion a screen can afford. A new system material should not be described as having zero cost without measurement.

Migrate in a reversible order

A practical beta experiment can follow this order:

  1. Create a branch that remains buildable with the Xcode 26 beta.
  2. Choose a secondary but representative screen.
  3. Adopt system navigation and toolbar behavior before custom effects.
  4. Remove duplicate backgrounds, strokes, and shadows.
  5. Add glass to one custom interaction surface.
  6. Test VoiceOver, the largest Dynamic Type sizes, contrast, Reduce Transparency, and Reduce Motion.
  7. Profile on a real supported device.
  8. Recheck the implementation against each beta and the final SDK before expanding it.

Capture comparison screenshots and accessibility notes for each beta seed, but treat them as migration evidence rather than a permanent design specification. When an SDK changes, update the isolated component and record why the appearance moved. This prevents teams from adding compensating shadows and offsets for a temporary beta behavior that the next seed already corrected.

The first Liquid Glass question is not “which modifier makes this surface shine?” It is “which elements are lasting content, and which controls float above that content?” Once the hierarchy is correct, the material can reinforce it. Without that hierarchy, a SwiftUI redesign may become more translucent while becoming less understandable.