7 added, 120 removed.
Need
Liquid Glass UI APIs
Default options
SwiftUI with glassEffect, GlassEffectContainer, and glass button styles
Why it's needed
These are the native APIs the skill should reach for first, so Codex removes custom blur layers instead of reinventing the material system.
11name: Adopt liquid glass# Adopt liquid glass | Codex use cases
2tagline: Use Codex to migrate an existing SwiftUI app to Liquid Glass with iOS
3 26 APIs and Xcode 26.
4summary: Use Codex and the Build iOS Apps plugin to audit existing iPhone and
5 iPad UI, replace custom blur or material stacks with native Liquid Glass, and
6 keep the migration safe with iOS 26 availability checks and simulator-driven
7 validation.
8skills:
9 - token: build-ios-apps
10 url: https://github.com/openai/plugins/tree/main/plugins/build-ios-apps
11 description: Use the SwiftUI Liquid Glass, SwiftUI UI patterns, and simulator
12 debugging skills to modernize iOS screens, adopt native glass effects, and
13 verify the result on iOS 26 simulators.
14bestFor:
15 - Existing SwiftUI apps that need a practical iOS 26 Liquid Glass migration
16 plan, not a vague redesign brief
17 - Teams that want Codex to audit custom cards, sheets, tab bars, toolbars, and
18 action buttons and then implement the migration slice by slice
19 - Apps that still support older iOS versions and need `#available(iOS 26, *)`
20 fallbacks instead of a one-way visual rewrite
21starterPrompt:
22 title: Migrate One Flow to Liquid Glass
23 body: >-
24 Use the Build iOS Apps plugin and its SwiftUI Liquid Glass skill to migrate
25 one high-traffic flow in this app to Liquid Glass.
26 2
3Need
27 4
285 Constraints:Liquid Glass UI APIs
29 6
307 - Treat this as an iOS 26 + Xcode 26 migration, but preserve a non-glassDefault options
31 fallback for earlier deployment targets with `#available(iOS 26, *)`.
32 8
339 - Audit the flow first. Call out custom backgrounds, blur stacks, chips,[SwiftUI](https://developer.apple.com/documentation/swiftui/) with `glassEffect`, `GlassEffectContainer`, and glass button styles
34 buttons, sheets, and toolbars that should become native Liquid Glass and
35 call out surfaces that should stay plain content.
36 10
3711 - Prefer system controls and native APIs like `glassEffect`,Why it's needed
38 `GlassEffectContainer`, `glassEffectID`, `.buttonStyle(.glass)`, and
39 `.buttonStyle(.glassProminent)` over custom blurs. Use `glassEffectID` with
40 `@Namespace` only when a real morphing transition improves the flow.
41 12
4213 - Apply `glassEffect` after layout and visual modifiers, keep shapesThese are the native APIs the skill should reach for first, so Codex removes custom blur layers instead of reinventing the material system.
43 consistent, and use `.interactive()` only on controls that actually respond
44 to touch.
45 14
46 - Use XcodeBuildMCP to build and run on an iOS 26 simulator, capture
47 screenshots for the migrated flow, and mention exactly which scheme,
48 simulator, and checks you used.
49
50
51 Deliver:
52
53 - a concise migration plan for the flow
54
55 - the implemented Liquid Glass slice
56
57 - the fallback behavior for pre-iOS 26 devices
58
59 - the simulator validation steps and screenshots you used
60relatedLinks:
61 - label: Codex plugins
62 url: /codex/plugins
63 - label: Agent skills
64 url: /codex/skills
65techStack:
66 - need: Liquid Glass UI APIs
67 goodDefault: "[SwiftUI](https://developer.apple.com/documentation/swiftui/) with
68 `glassEffect`, `GlassEffectContainer`, and glass button styles"
69 why: These are the native APIs the skill should reach for first, so Codex
70 removes custom blur layers instead of reinventing the material system.
71 - need: Platform baseline
72 goodDefault: iOS 26 and Xcode 26
73 why: Liquid Glass lands with the iOS 26 SDK. Codex should compile with Xcode 26
74 and add explicit fallbacks for earlier OS support.
75 - need: Simulator validation
76 goodDefault: "[XcodeBuildMCP](https://www.xcodebuildmcp.com/)"
77 why: Build, launch, screenshot, and log inspection matter during a visual
78 migration, especially when reviewing multiple states and device sizes.
79
80## Start from the iOS 26 baseline
81
82Treat 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.
83
84If the app still supports earlier iOS versions, make that constraint explicit up front. The SwiftUI Liquid Glass skill in the [Build iOS Apps plugin](https://github.com/openai/plugins/tree/main/plugins/build-ios-apps) should gate new glass-only APIs with `#available(iOS 26, *)` and keep a fallback path that still reads well on older devices.
85
86## Leverage the iOS plugin
87
88Use the [Build iOS Apps plugin](https://github.com/openai/plugins/tree/main/plugins/build-ios-apps) 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.
89
90That plugin includes a SwiftUI Liquid Glass skill with a simple set of defaults worth carrying into your prompt:
91
92- Prefer native `glassEffect`, `GlassEffectContainer`, glass button styles, and `glassEffectID` transitions over custom blur views.
93- Apply `.glassEffect(...)` after layout and visual modifiers so the material wraps the final shape you actually want.
94- Wrap related glass elements in `GlassEffectContainer` when multiple surfaces appear together.
95- Use `.interactive()` only on buttons, chips, and controls that actually respond to touch.
96- Keep corner shapes, tinting, and spacing consistent across the feature instead of mixing one-off glass treatments.
97- Preserve a non-glass fallback for pre-iOS 26 targets.
98
99To learn more about installing plugins and skills, see our [plugins](https://developers.openai.com/codex/plugins) and [skills](https://developers.openai.com/codex/skills) docs.
100
101## Watch the WWDC sessions
102
103These WWDC25 sessions are a good reference set before you ask Codex to refactor a real production flow:
104
105- [Meet Liquid Glass](https://developer.apple.com/videos/play/wwdc2025/219/)
106- [Get to know the new design system](https://developer.apple.com/videos/play/wwdc2025/356/)
107- [Build a SwiftUI app with the new design](https://developer.apple.com/videos/play/wwdc2025/323/)
108- [Build a UIKit app with the new design](https://developer.apple.com/videos/play/wwdc2025/284/)
109- [What's new in SwiftUI](https://developer.apple.com/videos/play/wwdc2025/256/)
110
111## Prompt a migration plan, then a slice
112
113Liquid 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.
114
115## Practical tips
116
117### Do not glass everything
118
119Liquid 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.
120
121### Start with one high-traffic flow
122
123A 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.
124
125### Review fallback behavior deliberately
126
127If 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.
