Start from the iOS 26 baseline

Treat Liquid Glass as an iOS 26 and Xcode 26 migration project first. Rebuild the app with the iOS 26 SDK, inspect what you get automatically from standard SwiftUI controls, and only then ask Codex to redesign the custom parts that still look too flat, too heavy, or too detached from system chrome.

If the app still supports earlier iOS versions, make that constraint explicit up front. The SwiftUI Liquid Glass skill in the Build iOS Apps plugin should gate new glass-only APIs with #available(iOS 26, *) and keep a fallback path that still reads well on older devices.

Leverage the iOS plugin

Use the Build iOS Apps plugin when you want Codex to combine SwiftUI UI changes with simulator-backed verification. For Liquid Glass work, the useful move is to ask Codex to audit one flow, migrate a small set of surfaces, launch the result on an iOS 26 simulator, and capture screenshots before expanding the scope.

That plugin includes a SwiftUI Liquid Glass skill with a simple set of defaults worth carrying into your prompt:

• Prefer native glassEffect, GlassEffectContainer, glass button styles, and glassEffectID transitions over custom blur views.
• Apply .glassEffect(...) after layout and visual modifiers so the material wraps the final shape you actually want.
• Wrap related glass elements in GlassEffectContainer when multiple surfaces appear together.
• Use .interactive() only on buttons, chips, and controls that actually respond to touch.
• Keep corner shapes, tinting, and spacing consistent across the feature instead of mixing one-off glass treatments.
• Preserve a non-glass fallback for pre-iOS 26 targets.

To learn more about installing plugins and skills, see our plugins and skills docs.

Watch the WWDC sessions

These WWDC25 sessions are a good reference set before you ask Codex to refactor a real production flow:

• Meet Liquid Glass
• Get to know the new design system
• Build a SwiftUI app with the new design
• Build a UIKit app with the new design
• What’s new in SwiftUI

Prompt a migration plan, then a slice

Liquid Glass migrations go better when Codex separates “where should glass appear?” from “write all the code now.” Ask for a quick audit first, then let the agent implement one self-contained slice with simulator verification.

Practical tips

Do not glass everything

Liquid Glass should create a clear control layer above content, not turn every card into a glowing panel. Ask Codex to remove decorative backgrounds that fight system materials, preserve plain content where readability matters most, and reserve tinting for semantic emphasis or primary actions.

Start with one high-traffic flow

A tab root, detail screen, sheet, search surface, or onboarding flow is usually a better first migration target than a full app-wide sweep. That keeps review easier and makes it clear which Liquid Glass decisions should become reusable component patterns.

Review fallback behavior deliberately

If your deployment target is below iOS 26, ask Codex to show the fallback implementation alongside the Liquid Glass version. That review step catches accidental API availability regressions and avoids shipping a migration that only works on the latest simulator.