SwiftUI 7 年后

原文 ↗ Hacker News 讨论 ↗

SwiftUI 发布七年后，许多开发者认为它对简单、声明式界面很强大，但在复杂、性能敏感的应用中不可靠且能力不足，尤其是与 UIKit/AppKit 和更早的 Cocoa 模式相比。评论者把状态管理不透明、布局脆弱、API 缺失或不稳定，以及与不断演进的 Swift 语言特性紧密耦合，视为核心问题；少数人则表示在最新 OS 版本上体验良好，并认为只要接受其权衡，它就“够用”。这场争论进一步延伸到对 Apple 软件方向、每年破坏性变更成本的担忧，以及 Flutter、Kotlin Multiplatform，甚至经典的基于 Objective-C 的技术栈是否如今提供了更可持续的路径。

SwiftUI 的价值主张与现实

  • 许多人认为 SwiftUI 非常适合简单的、偏“表层”的 UI：列表、表单、基础 CRUD、简单管理工具，以及视觉效果（模糊、遮罩、Metal 驱动视图）。
  • 对于复杂应用（大量列表、自定义布局、复杂导航、精细的 macOS 窗口管理、精确动画），人们反映存在性能问题、布局脆弱，以及大量回退到 UIKit/AppKit 的“逃生通道”。
  • 有人将它称为“新手陷阱”：演示很容易，真实项目很难。在较大的项目里，Bug 和异常行为往往在后期才显现。

状态、声明式 UI 与架构

  • 关于声明式-响应式与命令式的争论很大：
    • 支持者：以状态为单一事实来源、声明式视图能减少更新逻辑 Bug，并让常见场景更容易实现。
    • 批评者：SwiftUI 的响应性不透明；视图更新时机很难推理；@State/@Binding/@Observable 以及 GeometryReader 之类的工具被视为“魔法式”的踩坑点。
  • 一个很长的子讨论重新回顾了经典 MVC：有人认为“正确”的 MVC 本就能解决大多数状态同步问题，而不需要重型响应式机制；也有人说 MVC 本身也有实际问题（事件风暴、批量更新、布局性能）。

API、稳定性与工具

  • 经常被抱怨的包括：
    • API 频繁变化（例如演进中的导航 API、状态系统）、针对不同 OS 版本的条件分支，以及 iOS 版本之间的行为差异。
    • 文档质量差或分散；严重依赖 WWDC 视频和第三方博客。
    • 调试和性能分析支持薄弱（视图层级检查、理解重绘），不过也有人提到新版 Instruments 已有改进。
  • 有人认为如果能放弃旧 OS 支持，那么从 iOS 26–27 开始 SwiftUI “非常好”；也有人说即便是当前版本，在真实应用中仍然会卡顿且 CPU 占用高。

Swift、UIKit/AppKit 与 Apple 文化

  • 对 Objective-C + Cocoa/AppKit/UIKit 有强烈怀旧：它们被视为优雅、强大，并且更适合复杂的原生应用；而 Swift 在一些人看来过于复杂，且除了 Apple 平台之外吸引力有限。
  • 也有人认为 Swift 是重大改进，并且现在是他们在所有地方的主要语言；他们觉得 AppKit/UIKit 冗长且过时。
  • 有几位将 Swift/SwiftUI 过去十年“半成品”式发布归因于领导层和 KPI 驱动的决策，并将其与更早的 NeXT/Cocoa 时代作对比。

替代方案与跨平台讨论

  • 讨论的替代方案包括 Flutter、Kotlin Multiplatform + Compose、Qt、React Native、WPF、MAUI、HTML/CSS/JS，它们各自有不同权衡。
  • 现在有人更喜欢 UIKit + AI 助手，而不是 SwiftUI，认为 AI 削弱了 SwiftUI“布局容易”的优势。
  • 共识是：没有唯一“正确”的方式；工具选择取决于应用复杂度、目标平台，以及对 SwiftUI 怪癖的容忍度。