適配 Apple Liquid Glass 視覺體系
說明如何把 SwiftUI app 遷移到 Liquid Glass，並用小步審計和驗證降低重設計風險。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| Liquid Glass | 液態玻璃 | Apple 的一套視覺設計體系。 |
| 視覺適配 | visual adaptation | 把介面改造成符合該體系的過程。 |
| 設計規範 | design spec | 適配時要遵循的視覺規則。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你把介面適配到 Apple Liquid Glass 視覺體系的任務規劃好。
你是 Apple Liquid Glass 視覺適配規劃顧問，幫我把介面適配任務拆成可交給 Codex 的步驟。
【角色】
你瞭解 Liquid Glass 視覺體系的關注點，能把視覺適配拆成有邊界、可驗證的小任務，知道哪些要人把關視覺效果。
【輸入】
- 我的應用平臺和技術堆疊：___
- 要適配的介面範圍：___
- 現有視覺風格和差距：___
- 設計稿或參考：___
【工作流程】
1. 把適配範圍拆成小批介面
2. 每批給 Codex 明確的視覺目標和約束
3. 標出需人工對照設計稿驗收的部分
4. 給從實現到視覺驗收的閉環
【輸出規範】
▌一、適配範圍的分批
▌二、每批的視覺目標與約束
▌三、需人工視覺驗收的部分
▌四、實現到驗收的閉環
【硬約束】
- 視覺效果由人對照設計稿把關，Codex 做實現
- 小批推進，每批可回復
- 不臆測設計意圖，規範不清先確認
- 改動在真機 / 模擬器實際驗證
- 不確定的設計規範標註需查官方文件把現有 SwiftUI app 遷移到 Liquid Glass，不應該從“整體重設計”開始。更穩的方式是把它當成 iOS 26 + Xcode 26 migration：先審計一個高流量 flow，再用 native Liquid Glass APIs 替換 custom blur/material stacks，併為早於 iOS 26 的裝置保留 fallback。
平臺視覺遷移必須以目前 Apple SDK、deployment target 和官方 API 文件為準。不要在舊 Xcode、舊 simulator 或未驗證裝置上直接把 visual migration 寫進生產路徑。
官方頁面：https://developers.openai.com/codex/use-cases/ios-liquid-glass
適合什麼任務
| 場景 | Codex 應該做什麼 |
|---|---|
| 現有 SwiftUI app 需要實際 iOS 26 Liquid Glass 遷移計劃 | 審計現有 UI，先遷移一個 flow |
| app 裡有 custom cards、sheets、tab bars、toolbars、action buttons | 判斷哪些應變成 native Liquid Glass，哪些應保持 plain content |
| app 仍支援舊 iOS 版本 | 使用 #available(iOS 26, *) gate 新 API，並保留非 glass fallback |
使用的能力
| 能力 | 用法 | 連結 |
|---|---|---|
build-ios-apps | 使用 SwiftUI Liquid Glass、SwiftUI UI patterns 和 simulator debugging skills，現代化 iOS screens，並在 iOS 26 simulators 上驗證 | https://github.com/openai/plugins/tree/main/plugins/build-ios-apps |
相關官方說明：
- Codex plugins：https://developers.openai.com/codex/plugins
- Agent skills：https://developers.openai.com/codex/skills
起始提示詞
請使用 Build iOS Apps plugin 和其中的 SwiftUI Liquid Glass skill，把這個 app 中一個高流量 flow 遷移到 Liquid Glass。
約束：
- 把它當作 iOS 26 + Xcode 26 migration 處理，但要用 `#available(iOS 26, *)` 為更早 deployment targets 保留 non-glass fallback。
- 先 audit 這個 flow。指出哪些 custom backgrounds、blur stacks、chips、buttons、sheets 和 toolbars 應該變成 native Liquid Glass，也指出哪些 surfaces 應該保持 plain content。
- 優先使用 system controls 和 native APIs，例如 `glassEffect`、`GlassEffectContainer`、`glassEffectID`、`.buttonStyle(.glass)` 和 `.buttonStyle(.glassProminent)`，不要用 custom blurs 重造。只有當真實 morphing transition 能改善 flow 時，才結合 `@Namespace` 使用 `glassEffectID`。
- 在 layout 和 visual modifiers 之後應用 `glassEffect`，保持 shapes 一致，只在真正響應 touch 的 controls 上使用 `.interactive()`。
- 使用 XcodeBuildMCP 在 iOS 26 simulator 上 build 和 run，為遷移後的 flow 捕獲 screenshots，並明確說明使用了哪個 scheme、simulator 和 checks。
交付：
- 這個 flow 的簡潔 migration plan
- 已實現的 Liquid Glass slice
- pre-iOS 26 devices 上的 fallback behavior
- 使用過的 simulator validation steps 和 screenshots這個 prompt 先要求 audit，再要求實現一個 self-contained slice，並強制寫清楚 simulator validation。
推薦技術面
| 需要 | 推薦預設值 | 原因 |
|---|---|---|
| Liquid Glass UI APIs | SwiftUI + glassEffect、GlassEffectContainer、glass button styles | 優先使用 native APIs，移除 custom blur layers |
| Platform baseline | iOS 26 and Xcode 26 | Liquid Glass 隨 iOS 26 SDK 提供，Codex 應使用 Xcode 26 編譯並顯式新增舊系統 fallback |
| Simulator validation | XcodeBuildMCP | visual migration 需要 build、launch、screenshot 和 log inspection |
從 iOS 26 Baseline 開始
先用 iOS 26 SDK 重新 build app，看看 standard SwiftUI controls 自動獲得了什麼效果。只有 custom parts 仍然過平、過重或脫離 system chrome 時，再讓 Codex 遷移。
如果 app deployment target 低於 iOS 26，prompt 裡必須提前寫明。SwiftUI Liquid Glass skill 應該用 #available(iOS 26, *) 保護 glass-only APIs，並保留在舊裝置上仍可讀的 fallback path。
使用 iOS Plugin
Liquid Glass 任務裡，Build iOS Apps plugin 的實用模式是：
- 審計一個 flow。
- 遷移一小組 surfaces。
- 在 iOS 26 simulator 上 launch。
- 截圖後再擴大 scope。
預設規則可以直接寫進 prompt：
- 優先使用 native
glassEffect、GlassEffectContainer、glass button styles 和glassEffectIDtransitions，不用 custom blur views 重造材質系統。 .glassEffect(...)放在 layout 和 visual modifiers 後面，讓 material 包住最終 shape。- 多個相關 glass surfaces 一起出現時，用
GlassEffectContainer包起來。 .interactive()只用於真的響應 touch 的 buttons、chips、controls。- corner shapes、tinting、spacing 在 feature 內保持一致。
- pre-iOS 26 targets 保留 non-glass fallback。
WWDC 參考
開始遷移真實 production flow 前，先看這些 WWDC25 session：
- 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
實用建議
不要把所有東西都玻璃化
Liquid Glass 應該在內容上方形成清楚的 control layer，而不是把每張 card 都變成發光面板。閱讀優先的 content 應保持 plain；tinting 留給 semantic emphasis 或 primary actions。
先做一個高流量 Flow
tab root、detail screen、sheet、search surface 或 onboarding flow 通常比全 app sweep 更適合第一輪遷移。這樣 review 更容易，也更容易沉澱 reusable component patterns。
有意 review fallback
如果 deployment target 低於 iOS 26，讓 Codex 同時展示 Liquid Glass version 和 fallback implementation。這樣能提前發現 API availability regression。