文章摘要
SwiftUI发布七年后仍像永久测试版，存在性能、布局和数据流问题，缺乏向后兼容性。文章通过苹果官方教程故障和与UIKit对比，指出其用便利性牺牲精确性，并批评苹果从追求卓越转向“差不多就行”的企业文化。
文章总结
好的，这是根据您的要求，对原文主要内容进行的中文重述，保留了核心细节，并删减了与主题无关的冗余内容。
标题：SwiftUI 七年之痒：一个平庸的故事
核心观点： 自2019年发布以来，SwiftUI 并未如苹果所承诺的那样，成长为成熟、可用于生产环境的跨平台UI框架。即使在2026年，它仍像一个永久的测试版，给资深工程师带来了深深的职业挫败感。
主要问题分析：
数据流混乱： 苹果承诺的“单一数据源”在实践中变成了由各种属性包装器、宏和不断变化的框架组成的混乱局面。从最初的
@State、@Binding到后来的@Observable宏，苹果试图用编译器技巧解决性能问题，但效果不佳。开发者无法预测视图何时以及为何会更新，其响应机制就像一个“黑箱”，经常忽略重要变化，却对无关变化做出反应。布局系统不可预测： SwiftUI 的布局引擎基于“尺寸协商”理念，听起来合理，但在构建非标准界面（如浮动视图、自定义侧边栏）时如同噩梦。苹果官方 SwiftUI 教程中的 macOS 示例项目，在最新系统上运行仍存在侧边栏按钮大小不一等明显bug，且该问题已存在两年多未修复。开发者最终不得不大量使用
GeometryReader手动计算坐标，这完全违背了声明式布局的初衷，且代码在每次框架更新后都可能需要重写。API 不稳定且功能缺失： 现代 SwiftUI 代码库中充斥着
if #available版本检查，这与苹果“写更少代码”的承诺背道而驰。许多在 UIKit/AppKit 中存在多年的基础功能（如滚动时关闭键盘、自定义窗口工具栏、网络图片缓存），SwiftUI 要么迟迟不提供，要么提供的 API 仍处于测试阶段。此外，核心组件如NavigationView因bug过多被直接替换为NavigationStack，迫使开发者维护多套代码分支。开发者实际上是在为苹果做质量保证工作。性能不佳： 作者通过一个简单的图片画廊应用，在旧款 iPhone 上对比了 UIKit 和 SwiftUI 的滚动性能。结果显示，即使采用了后台解码等优化技巧，SwiftUI 的滚动流畅度也明显逊色。作者认为，如果展示几张 JPEG 图片都需要顶级芯片，说明其架构存在严重问题。
跨平台神话破灭： 苹果宣传的“一次学习，随处应用”在实践中变成了“一次学习，两次学习，部分应用，到处调试”。为 iOS 设计的布局很难直接应用于 Mac，否则会产生界面风格不协调的“异类”应用。不同平台上的相同组件，其实现方式也往往不一致。
深层原因与哲学转变：
作者认为，SwiftUI 的问题根源在于苹果公司整体开发理念的转变：从过去对 Cocoa、Aqua 时代“不妥协的工艺”的追求，转向了现代企业“差不多就行”的文化。这种“足够好”的心态导致产品品质下降，不仅体现在 SwiftUI 上，也体现在苹果自家的应用（如 Apple Music、设置、TestFlight）和系统组件中。作者认为，降低质量标准是一种选择，而非必要，他拒绝接受这种平庸。
结论：
SwiftUI 并非真正糟糕，而是平庸。对于构建稳定、高性能、可维护的系统而言，它几乎在所有关键方面都存在问题。它用“便利的幻觉”换取了“可预测的精确性”，迫使开发者在“花时间调试框架”和“交付有缺陷的应用”之间做出选择。因此，作者目前仍倾向于使用 UIKit 和 AppKit 等“传统”框架。
评论总结
根据评论内容，总结如下：
主要观点与论据：
SwiftUI的潜力与局限（评分：无）
- 支持者认为SwiftUI+SwiftData是最佳UI环境，但文档不足、需依赖AppKit/UIKit（评论3：“I fell in love with SwiftUI... still haven't been able to make a full app with it yet, mostly because of the lack of documentation”）。
- 批评者指出其“让简单事更容易，难事更难”，不适合复杂动画和精确布局（评论8：“SwiftUI it is the type of framework that makes the easy things easier to accomplish but the harder things harder”）。
框架设计争议（评分：无）
- 部分开发者质疑纯声明式响应式框架的普适性，认为其更适合简单应用（评论5：“pure declarative-reactive is the 'right' shape for an all-purpose native UI framework... works best for super simple tabs-and-flat-lists sorts of apps”）。
- 批评者指出修饰符顺序依赖、视图生命周期不透明、调试困难等问题（评论14：“the order of the modifiers in the builder matters... makes no sense”）。
与UIKit/AppKit对比（评分：无）
- 老开发者认为SwiftUI是倒退，怀念AppKit的成熟（评论10：“SwiftUI is a massive step backwards from AppKit”）。
- 另一些开发者认为SwiftUI是进步，尤其对新手友好（评论11：“developers who started with UIKit really have a hard time working with SwiftUI... it's an entirely different way to think”）。
跨平台与替代方案（评分：无）
- 有开发者转向Kotlin Multiplatform + Compose（评论15：“I don't see the point of learning SwiftUI anymore”）。
- 也有开发者坚持Web技术栈（评论16：“I still really like HTML for structure, CSS for styling, and JavaScript for logic”）。
苹果的更新策略（评分：无）
- 批评者认为年度更新周期导致文档滞后、API不稳定（评论3：“Apple's insistence on a yearly update cycle... You have to wait for the next WWDC”）。
- 支持者认为用户升级快，应支持最新版本（评论12：“Apple users upgrade. There's no reason that you should be supporting iOS 17 at this point”）。
平衡性总结： - 正面观点：SwiftUI降低入门门槛，适合简单应用，AI辅助可弥补不足。 - 负面观点：复杂应用性能差、调试困难、文档不足、API不稳定。 - 中立观点：需根据项目需求选择工具，SwiftUI并非万能。