原文核对：2026-10-13 · 中文正文 · 英文提示词与演示
场景定位
审计 iPhone、iPad UI，用原生 Liquid Glass 替换自定义模糊和材质层，并通过 iOS 26 可用性检查与模拟器验证安全迁移。
- 难度
- 高级
- 时间跨度
- 1 小时
适合用于
- 需要实际 iOS 26 迁移计划的现有 SwiftUI 应用。
- 希望逐块审计并迁移卡片、sheet、标签栏、工具栏和操作按钮的团队。
- 仍支持旧 iOS、需要 #available(iOS 26, *) 回退的应用。
相关工具
结合 SwiftUI Liquid Glass、UI patterns 和模拟器调试技能，现代化页面并在 iOS 26 模拟器上验证。
Build iOS Apps ↗起步提示词
英文原文 · 可复制后按实际材料修改
Use the Build iOS Apps plugin and its SwiftUI Liquid Glass skill to migrate one high-traffic flow in this app to Liquid Glass.
Constraints:
- Treat this as an iOS 26 + Xcode 26 migration, but preserve a non-glass fallback for earlier deployment targets with `#available(iOS 26, *)`.
- Audit the flow first. Call out custom backgrounds, blur stacks, chips, buttons, sheets, and toolbars that should become native Liquid Glass and call out surfaces that should stay plain content.
- Prefer system controls and native APIs like `glassEffect`, `GlassEffectContainer`, `glassEffectID`, `.buttonStyle(.glass)`, and `.buttonStyle(.glassProminent)` over custom blurs. Use `glassEffectID` with `@Namespace` only when a real morphing transition improves the flow.
- Apply `glassEffect` after layout and visual modifiers, keep shapes consistent, and use `.interactive()` only on controls that actually respond to touch.
- Use XcodeBuildMCP to build and run on an iOS 26 simulator, capture screenshots for the migrated flow, and mention exactly which scheme, simulator, and checks you used.
Deliver:
- a concise migration plan for the flow
- the implemented Liquid Glass slice
- the fallback behavior for pre-iOS 26 devices
- the simulator validation steps and screenshots you used从 iOS 26 基线开始
先将其视为 iOS 26、Xcode 26 迁移：用新 SDK 重建，检查标准 SwiftUI 控件自动带来的变化，再调整仍显平坦、厚重或脱离系统界面的自定义部分。
提前说明旧版本支持要求。Build iOS Apps 中的 SwiftUI Liquid Glass 技能应为新 API 加上 #available(iOS 26, *)，保留旧设备清晰可读的回退。
使用 iOS 插件
用 Build iOS Apps 将 UI 修改与模拟器验证结合：先审计一个流程、迁移少量界面，在 iOS 26 模拟器运行并截图，再扩大范围。
插件中的 Liquid Glass 技能有以下默认建议：
- 优先使用原生 glassEffect、GlassEffectContainer、玻璃按钮样式和 glassEffectID 转场。
- 在布局与视觉修饰符之后应用 .glassEffect(...)，使材质包裹最终形状。
- 相关玻璃元素同时出现时，用 GlassEffectContainer 包裹。
- 只给真正响应触摸的按钮、标签和控件加 .interactive()。
- 在功能内统一圆角、着色和间距。
- 为 iOS 26 之前的目标保留非玻璃回退。
参考 WWDC 课程
重构生产流程前，可参考这些 WWDC25 课程：
- 认识 Liquid Glass（Meet Liquid Glass）。
- 了解新设计系统（Get to know the new design system）。
- 用新设计构建 SwiftUI 应用。
- 用新设计构建 UIKit 应用。
- SwiftUI 新功能（What’s new in SwiftUI）。
先计划，再实现一块
先决定哪些位置适合玻璃效果，再写代码。要求快速审计，然后实现一个独立切片并在模拟器验证。
实用建议
不要所有地方都用玻璃
Liquid Glass 应形成内容上方清晰的控制层。删除与系统材质冲突的装饰背景，重点阅读区域保持简洁，着色用于语义强调或主要操作。
从一个高频流程开始
标签页根、详情页、sheet、搜索或入职引导比全应用迁移更易审阅，也便于识别可复用组件模式。
主动检查回退
部署目标低于 iOS 26 时，并排展示回退和玻璃实现，发现 API 可用性回归，避免只在最新模拟器工作。
技术栈
| 需要 | 默认选项 | 用途 |
|---|---|---|
| Liquid Glass UI API | SwiftUI：glassEffect、GlassEffectContainer、玻璃按钮样式SwiftUI ↗ | 优先原生 API，移除自定义模糊层。 |
| 平台基线 | iOS 26 和 Xcode 26 | 使用 iOS 26 SDK 编译，并为旧系统显式回退。 |
| 模拟器验证 | XcodeBuildMCPXcodeBuildMCP ↗ | 通过构建、启动、截图和日志检查多种状态及设备尺寸。 |
展开英文原文对照
Use Codex and the Build iOS Apps plugin to audit existing iPhone and iPad UI, replace custom blur or material stacks with native Liquid Glass, and keep the migration safe with iOS 26 availability checks and simulator-driven validation.
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.