SwiftUI 的成熟訊號：少寫 workaround，多理解 identity、layout 與 system behavior
這場 Group Lab 把 SwiftUI 的常見疑問拉回框架模型：List 大量資料、Xcode modernization skills、Liquid Glass、adaptive containers、GeometryReader、DynamicProperty、conditional branch、AnyView 與自訂 control style。
SwiftUI 不是只靠更多 modifier 解決問題；真正穩定的導入方式，是把資料形狀、view identity、layout proposal、system controls 與效能生命週期一起設計。
這支影片在整理 SwiftUI 開發者最常踩的四種邊界
大量 List 問題需要回到資料形狀
對數千筆資料卡頓的回答不是單一 recipe，而是請開發者提供實際 use case。Apple 想看資料結構、更新模式與為何需要一次呈現那麼多項目。
Xcode skills 是遷移工具，也是可讀的技術指南
UI modernization skills 可在 Xcode agentic workflows 使用，也可匯出到其他 agentic system。它們不只是工具提示，還能作為人類理解 UIKit 遷移的材料。
Liquid Glass 要盡量使用系統容器與 controls
GlassEffectContainer、tab views、sidebar、system controls 會隨系統設計演進取得更新；自行仿造玻璃效果反而容易錯過 free update 與互動細節。
conditional modifier 和 AnyView 會影響 state
把 conditional branch 包在 modifier 裡可能導致上游 view 重建與 state reset；AnyView 可用，但當底層 type 改變時，仍可能需要拆掉重建 hierarchy。
把 SwiftUI 問題拆成可測的四層
先確認資料與 view identity
List、navigation、conditional branch、AnyView 的行為都和 identity 有關。先問資料何時更新、row 如何識別、branch 是否改變 view type。
再看 layout proposal 與容器選擇
GeometryReader 應局部使用；父層給 child 的 size 是 proposal，child 可回報不同尺寸。需要跨元素協調時，優先考慮 custom layout 或 adaptive container。
把 expensive work 提前到 body 前
影片提到 DynamicProperty 的 update 會在 body render 前執行，可用 property wrapper 提前提供 cached value，避免 onAppear 載入造成二次 render。
最後才決定是否自訂 control style
ButtonStyle、control style、swipe actions container 可以保留系統 control 初始化與 accessibility 行為；不要為了外觀重寫整個 control。
Liquid Glass 的實作重點不是「畫出玻璃」
Panel 多次提到 Liquid Glass 的效果和系統 controls、containers、navigation transition 一起運作。若 app 使用系統 tab view、sidebar、buttons 和 controls，未來設計調整會自動取得改進；若自己仿造材質，往往會錯過互動、融合、可讀性與 accessibility 細節。
導入建議：先盤點哪些畫面可以改回系統 component，再針對真正需要品牌化或特殊 layout 的地方使用自訂 style。不要把 Liquid Glass 當成全域 overlay 特效。
Conditional branch 是 SwiftUI state bug 的高風險來源
Panel 對「if modifier」給了很直接的警告：把 conditional 包在 view modifier 裡，看似只是改外觀，但實際可能在很多地方套用不同 branch，導致 layout 重算、view hierarchy 重建，甚至 state reset。AnyView 也是類似判斷：不是不能用，而是要知道底層 concrete type 變更時，SwiftUI 必須拆掉舊 hierarchy。
Navigation 與 modal 要有自己的 presentation model
有開發者問到如何在已存在 modal presentation 時再呈現 full-screen UI。回答的核心是：若 presentation stack 變複雜，資料模型與 navigation model 需要協調。不要只依靠「在某處觸發 fullScreenCover」；應明確追蹤目前 presentation 層級、來源與互斥規則。
遷移與 QA 注意事項
對 SwiftUI 團隊的實務啟發
這場 lab 的共同訊息是：SwiftUI 已經有足夠多成熟 primitive，真正困難的是選擇哪個 primitive 才和資料、平台與系統設計一致。與其靠 workaround 堆 modifier，不如把 view identity、layout proposal、system controls、navigation model 和 performance lifecycle 寫進團隊的 code review checklist。
- 01大量 SwiftUI List 問題要回到資料形狀、更新頻率與 row identity，不是套單一技巧。
- 02Liquid Glass 優先使用系統 components；自己仿造玻璃效果會失去未來系統調整。
- 03Conditional modifier、AnyView 與 presentation stack 都需要明確理解 view identity 與重建成本。
- 04DynamicProperty、custom layout、ButtonStyle 是比 onAppear workaround 和重寫 control 更穩的工具。