在2019年的精彩发布会七年之后，SwiftUI 本该是所有苹果平台上跨平台 UI 开发的成熟和生产级未来。然而，直到2026年，SwiftUI 似乎仍然停留在一个永恒的测试阶段。在这次深入探讨中，我分析了为什么最初的兴奋感已经转变为高级工程师的深重挫折。我分析了与性能和布局可预测性相关的系统性问题，SwiftUI 不断变化的数据流的混乱状态，以及迫使开发者陷入大量适配和变通措施噩梦中的令人沮丧的缺乏向后兼容性。通过实际案例——包括苹果自己的 SwiftUI 教程（存在问题）以及与 UIKit 的正面性能比较（猜猜谁赢）——我展示了 SwiftUI 如何为了便利的假象而牺牲了精确的工程设计。除了代码之外，这个视频还探讨了在库比提（Cupertino）发生的更广泛、更令人担忧的转变：从原始 Cocoa、Aqua 和自动布局时代的无妥协工艺，向现代企业文化的“足够好”产品转变。如果你厌倦了为损坏的特性寻找借口，纠结于布局错误，并替苹果做质量保证，这个视角就适合你。 链接 里程碑（苹果破损的 SwiftUI 教程）未记录的 Self._printChanges() 方法（以及其他调试技巧）SwiftUI 只会让开发糟糕的应用变得简单 SwiftUI 组仍然被视为有害的（SwiftUI 隐藏的陷阱又一个例子） 视频文字记录 介绍 好吧，让我们开始吧。这将是关于 SwiftUI 的较长篇幅，讨论它的问题以及为什么我认为它在短期内不会变得更好。过去七年并没有让 SwiftUI 成为一个真实的、生产级的 UI 框架：它仍然存在着布局一致性和性能方面长期以来的问题。但是你不必只听我的话；你可以自己在苹果的官方第一方 SwiftUI 教程中查看。只需下载下面链接中的完整演示项目，并在你的 Mac 上运行它。我稍后会回到这个特定案例。但让我们先回顾一下。SwiftUI 于2019年宣布，并引起了很大的轰动。我在场，亲眼见证了这一切。苹果承诺结束为自动布局而苦苦挣扎的时代，并在你每次做出最微小的更改时重新构建应用的时代。相反，你将获得声明式语法、单一的真实来源、内置动画、即时预览以及代码的跨平台可重用性。对我来说，这听起来好得令人难以置信。事实证明，确实如此。到如今，初始的兴奋感不仅消退了，它还给越来越深的专业挫败感让路。在七年之后，关于“SwiftUI 仍然是一个年轻框架”的借口，已经完全没用了。在这个行业中，七年就像一个世纪。这大约是这和这之间的时间，也是从第一款 iPhone 到 iOS 7 重新设计之间的时间。相比之下，SwiftUI 感觉就像处于一个永恒的测试状态。每个新特性都附带一个细则。每个布局修复都会破坏另外两个你根本没碰到的东西。老实说，我已经厌倦了在我自己的项目中为所有这些找借口。 SwiftUI的存在理由 但在我们看看 SwiftUI 具体的优缺点之前——主要是缺点——让我们看看 SwiftUI 的存在理由。苹果并不是真心想给你提供优秀的开发工具，而是因为它有点不得不这样做。苹果必须回应来自竞争的压力。到2010年代中期，Facebook 的 React 成为网页上的事实标准，而不久之后 React Native 和谷歌的 Flutter 开始征服移动平台。这两个框架都是反应式和声明式的。从任何业务的角度来看，构建原生应用程序开始显得越来越不具吸引力。相反，他们可以在 iOS 和 Android 上使用相同的代码库，同时借用来自自己网站的组件。我相信还有一个原因，那就是 Mac App Store。你最后一次打开它是什么时候？你最后一次在你的 Mac 上安装新的原生应用程序是什么时候？是的，情况差不多。iOS App Store 是苹果转向服务业务的关键步骤，得益于每笔交易的30%费用。但在 Mac 上，许多应用程序仅在浏览器中运行，或作为 Electron 包装的网页应用程序。SwiftUI 本该解决这两个问题：让开发者留在原生生态系统中构建新应用，并使现有应用易于移植到 Mac。反应式数据流、声明式布局和跨平台支持是 SwiftUI 的主要卖点。苹果是否兑现了这些承诺？让我们仔细看看。 数据流 值得 Senior Engineers（包括我在内）关注的最大痛点之一是数据流。在纸面上，单一的真实来源听起来像是一个美梦。但在实践中，现实却是一团困惑的麻烦，充满了属性包装器、宏和不断变化的支持。