SwiftUI 七年：一场平庸的持续 Beta
SwiftUI After 7 Years
距离 2019 年发布已过去七年，SwiftUI 本应成为 Apple 平台成熟的跨平台 UI 框架，但现实却令人沮丧。作为一名资深工程师，我发现它仍深陷性能瓶颈、布局不可预测和数据流混乱的泥潭。从 Apple 官方教程的 Bug 到与 UIKit 的性能对比，SwiftUI 似乎用便利性幻觉换取了工程精确性。这不仅是技术债务的累积，更折射出 Cupertino 从追求极致工艺向“够用就好”的企业文化转变。如果你也厌倦了为破碎的功能找借口、与布局 Bug 搏斗，这篇文章或许能道出你的心声。
在 SwiftUI 中，你永远无法确切知道一个视图会更新多少次，也无法理解它为何选择在那一刻更新。
HN 评论区
271- rayiner
复杂系统的问题在于，你可能在意识到自己已经“死”了之前很久就已经死了。仅仅凭借过去明智决策的惯性和积累的基础设施，一切可能看起来“还不错”很长一段时间。你会看到一些磨损或裂痕，但整体看起来依然根基稳固，直到它不再稳固。
苹果无法推出一个比前代更好的 UI 框架，这令人担忧。这家公司曾从 Toolbox 转向 Carbon，再转向 Cocoa，每一步都比上一步更好。如果 MacOS X 和 Cocoa 今天还不存在，苹果还能造出来吗？微软在二十年间未能推出 Win32 的真正继任者，这表明微软（至少是其操作系统部门）早在多年前就已经“死”了。我不禁想问，十年后我们是否也会对苹果做出同样的评价。
- sandoze
这似乎是一个流行的“争议性”话题。自 2021 年以来，我一直在生产应用和游戏中使用 SwiftUI。必要时，我会降级使用 UIKit、Metal 或 Core Animation。但这与我以前用 UIKit 做游戏时，必要时降级使用 Core Animation 或 C 语言编写的字形渲染器并没有什么不同。
数据流：作者声称无法知道何时会发生更新。不仅经验能帮上忙，还有分析工具可以告诉你何时、何地发生了更新。这并非黑魔法。保持 View 小巧，小心地传递数据。@environment 非常酷，但可能会产生级联效应。这在 iOS 17+ 中得到了极大改进，我不再支持比 iOS 17 更老的版本。
GeometryReader：我偶尔会使用它。在处理某些视图复杂性时，它有点像是必要的恶。它也可能表明你做错了什么。
API 稳定性和性能：苹果用户会升级系统。此时没有任何理由去支持 iOS 17——甚至 iOS 18 在我们多个应用中的用户占比也仅约 2%。我一直使用 SwiftUI 且没有遇到重大性能问题，但我也不会过早优化。我会根据需要进行分析并修复。我早期工作过的一家工作室将所有游戏原型都用 UIKit 编写，当性能崩溃时，我们会切换到必要的工具（例如 OpenGL）——就像在核心游戏逻辑中那样。
我还可以继续说下去，但归根结底，只是为工作选择正确的工具，如果你不精通……
- cosmic_cheese
我肯定很多人会不同意，但我怀疑纯声明式 - 响应式（declarative-reactive）并不是通用原生 UI 框架的“正确”形态。据我的经验，Kotlin+Compose 也有许多类似的毛病……它主要的可取之处在于它比 Android Framework 更好（大多数时候），但这门槛其实很低。
这些框架有很多好点子，但它们未必能以一种超越高质量传统命令式框架（其中点缀着声明式 - 响应式片段）的方式结合起来，至少对于更复杂的应用来说是这样。SwiftUI 及其同类框架最适合那种超级简单的、只有标签页和平铺列表的应用。
- spacedcowboy
苹果在 ObjC 和 AppKit 上曾有过真正的赢家。Swift 相对于 ObjC 所提供的优势而言，其复杂性令人发指，而 SwiftUI 则是相对于 AppKit 的巨大倒退。
这只是我个人的看法（MHO），也阻止不了这股势不可挡的洪流，但对我来说，转向那里毫无吸引力 :( 如果（当？）苹果放弃 ObjC，那就是我转向 Linux 的日子。
- emehex
我注意到，那些从 UIKit 起步的开发者真的很难适应 SwiftUI。我认为这是因为这不仅仅是新语法，而是一种完全不同的思维方式：状态是真理之源，视图是短暂的，你是在描述 UI 而不是管理它。
- peheje
尽管有各种趋势，我依然非常喜欢用 HTML 做结构，CSS 做样式，JavaScript 做逻辑。
界限并不完美清晰，但这没关系。这种分离提供了一种有用的思考方式：先构建结构，再处理样式，在需要的地方添加行为。
我对 Compose 的体验——虽然我怀疑 SwiftUI 用户会有同感——是我必须时刻、处处思考一切。
然后我们加上一些 MVVM/UDF 的风味。“ViewModel”对视图一无所知，尽管它通常只为一个屏幕服务。添加一些“MutableStateFlow”，将它们组合成“ScreenUiState”，将其暴露为“StateFlow”，并结合生命周期感知进行收集。
解耦得完美无瑕。极其易于测试。
然后公司完全不写单元测试，完全依赖每晚运行两小时的屏幕测试。
欢迎页的重构搞崩了个人资料页。
“你没检查夜间构建吗？”
没有。它是晚上跑的。
“好吧，那是你的责任。”
但你把它搞坏了。
“是的，但那是你的代码。”
那为什么我们还发布了？
行吧。安排个事后复盘，叫上我妈一起来。
而且我在这里并不是在责怪移动开发者。我是前端、后端、全栈，现在大概也算 AI 工程师。我亲自参与过整个技术栈中把简单事情变复杂的过程。
我喜欢 Web 的一点是，一个简单的屏幕可以用原生 JavaScript，另一个可以用 Vue，还有一个可以用某种专用的表格组件。
人们对此反应惊恐：如果组件重复了怎么办，……
- happytoexplain
AutoLayout 虽然像其他东西一样有缺陷，但仍然是所有平台上 UI 的巅峰。
SwiftUI 是一次值得称赞的尝试，旨在让 UI 开发变得“傻瓜-proof”，但它牺牲了太多，最终失败了。
- slopinthebag
Swift 是我用过的最糟糕的语言。作为背景，我用过从 JavaScript 到 C++ 的所有语言，而我现在的选择是 Rust。
Swift 感觉难以穿透。太多的语法和特性是“渐进式披露”的（顺便说一句，这是糟糕的 UX 范式），但它们只是突然跳出来，破坏线程语义，工具链也烂透了。它也是唯一一种我无法让 AI 表现还不错的语言，这是双重打击。
我讨厌 Swift 到了极点。