今天刷到两条关于 SwiftUI 的消息，放在一起挺有意思。
一条是知乎上那个一直没沉的吐槽帖：如何看待 iOS/Swift 开发者吐槽 SwiftUI 发展了七年依旧像半成品？知乎讨论的源头是一篇流传很广的海外长文《SwiftUI After 7 Years》，大意是七年了，它还是那个半成品。另一条是今天出现的：开始有文章认真讨论开源项目 OpenSwiftUI，而且不再是喊口号，是把用途一条条列出来。
一边说"还没做完"，一边社区已经开始自己动手"拆开看"。SwiftUI 的争议，正在从纯吐槽进入动手拆解的阶段。这对每个在生产环境用 SwiftUI 的人都有关系：你印象里的吐槽，可能早就过期了；你以为已经解决的问题，可能今天还在疼。
先说清 OpenSwiftUI 是什么、不是什么
泼盆冷水：OpenSwiftUI 不是"官方 SwiftUI 的免费版"，它是对 SwiftUI 内部实现的开源重做。为什么这事有意义？因为 SwiftUI 发布至今一直是闭源的，它怎么做 diff、什么时候渲染、为什么某个版本布局会塌，开发者全都看不见。苹果不给源码，过去遇到渲染 bug、布局异常、动画卡死，能做的只有看 WWDC session 猜原理，或者在 Xcode 里反复试。知乎专栏开源重做的意义就在于"能看见"：同一套行为有了可以对照的实现，一部分黑盒问题从此可以解释、可以复现。所以社区讨论它时，用途都集中在调试、CI 跨平台测试和教学上，而不是"替代官方"。
中文 Swift 社区追踪这类项目其实很久了，不少人在订的"肘子的 Swift 周报"，四月份就专门讲过 OpenSwiftUI 和类似的 DanceUI。知乎但成熟度要保持冷静：它在推进，能不能扛生产，谁的文章说了都不算，得自己去看仓库和 issue。
吐槽审计：先看过期的
吐槽一："导航一团乱，返回栈没法用。"过期了。iOS 16 的 NavigationStack 和 NavigationSplitView，早就把程序化导航从"往 NavigationView 里塞 binding 然后祈祷"的年代拉了回来。如果你的印象还停在这里，这条吐槽已经过期四年。
吐槽二："状态管理碎片化，@ObservedObject 满天飞。"基本过期。iOS 17 的 @Observable 宏按属性粒度做依赖追踪，以前要小心翼翼地管 ObservableObject、防无效刷新的那些坑，大部分被直接抹平。新项目现在默认就可以从 @Observable 起步。
吐槽三："性能差，列表卡顿。"这条苹果甚至直接回应了：WWDC26 官方新闻稿明确说，今年的 SwiftUI 通过更高效的状态初始化和更快的布局渲染让应用更流畅，而且不需要开发者改一行代码。Apple Newsroom当然前提是你没自己往 ForEach 里塞一堆重量级视图——但"SwiftUI 就是慢"这种全称判断，可以退休了。
吐槽四："控件缺失，啥都要自己封。"半过期。Charts、自定义容器、MeshGradient、缩放转场这几年陆续补齐，今年连可重排容器都有了，要手写的自定义代码又少一截。但"细粒度控制"依旧追不上 UIKit，这就引出下面仍然成立的吐槽。
仍然成立的吐槽，集中在两个字：黑盒
第一是 bug 归因难。SwiftUI 出了问题，你分不清是自己写错了、框架有 bug，还是系统升级带来的行为变化。UIKit 有十几年的堆栈和经验积累，SwiftUI 内部闭源，"同一份代码在不同版本表现不一样"是那个吐槽帖里怨气最大的来源。这个问题到今天没有根本解决——OpenSwiftUI 能火起来，本身就说明这个痛点攒了多深。
第二是细粒度定制的成本。动画、布局、渲染时机，越往深处挖，越容易撞上框架的"隐式行为"。社区常见的妥协是混合开发：SwiftUI 搭骨架，硬骨头用 UIKit 兜底。这本身就说明"纯 SwiftUI"不是所有场景都走得通。
第三是版本碎片。API 一年一批发，你能写到什么程度，取决于最低支持版本定在哪。新特性很香，老设备不能丢，就只能忍着。这不是 SwiftUI 的原罪，但它放大了那种"半成品感"。
那到底谁可以放心用？分三种人说
新项目、最低支持版本能拉到 iOS 16/17 的：放心用。早期那些坑大多已经不存在，开发效率的收益是实打实的。前提是第一天就立好规矩：状态管理用 @Observable，导航用 NavigationStack，复杂场景给 UIKit 留一条后路。
存量项目、交互重、还要顾老系统的：别掀桌子。混合不丢人，SwiftUI 和 UIKit 的互操作本来就是官方一等公民。该换的是那些"吐槽多、改动少"的页面，复杂动画和手势的硬骨头先别动。
跨平台团队的：关注，但别急着押注。开源重实现的理想是跨平台，可它今天能提供的更接近"理解和调试"，不是"一套代码处处运行"。生产上要做跨端，先评估成熟方案。
最后，三个值得盯的信号
一是工具链正在从侧面撬黑盒。Xcode 27 把 agentic coding 做成了核心卖点：开发者可以通过 Model Context Protocol 接入日常工具，连接任何兼容 Agent Client Protocol 的智能体，GitHub 和 Figma 是首批无缝打通的。Apple Newsroom最新的 beta 里，MCP 服务更是已经不用打开 Xcode 也能跑。知乎专栏当 AI 智能体能直接驱动构建和调试，"SwiftUI 又表现奇怪了"这类问题的验证成本会低一大截——黑盒问题可能先被工具链解决一半。
二是 Liquid Glass 会检验你的 UI 代码。它从 iOS 26 开始就是苹果全平台统一的设计语言，这套半透明材质把玻璃的光学质感和流体感揉在一起，随内容和上下文变化。Apple Newsroom今年它还加进了系统级透明度滑杆，用户可以自己调观感。而社区流传的说法是：用 Xcode 27 编译的 App，液态玻璃就是标配，苹果只是给了开发者一年缓冲期。知乎专栏SwiftUI 是这轮视觉换代的第一公民，你的 UI 层代码能不能"换装"，迟早要被新系统考试。
三是开源重实现项目的节奏。OpenSwiftUI 的价值，在于让 SwiftUI 的行为变得可验证、可对照。如果社区持续投入，这本身就是"生态对 SwiftUI 还有信心"的先行指标；反过来，如果它沉寂了，也能说明一些问题。
吐槽归吐槽，清单该更新了。2026 年的 SwiftUI，不能再用 2019 年的印象去判；同样，说"全都修好了"也不负责——黑盒依旧是黑盒。你踩过最狠的是哪条吐槽？或者你遇到过"明明已经修好"却还在坑里的问题？评论区聊聊。
