为什么我们发布 Swift，而不是 SwiftUI

自 2019 年以来，每一届 WWDC 都在进一步推动 SwiftUI 的发展，而每当我们开始开发一款新应用时，团队都会坐下来探讨同一个问题： 它已经成功进入我们的应用程序了吗？ 到目前为止，对于那些关键部分，答案是否定的——而对于那些不重要的部分，答案很可能是肯定的。.

这并不是对 SwiftUI 整体的评价。许多团队都利用它开发出了出色的应用。这只是描述了它对我们而言的适用场景：我们是一家小型工作室，同时维护着几款 iPhone 和 iPad 应用，这些应用中任何一款都不能出现意外情况。.

什么有效

SwiftUI 确实非常适合静态设置界面、表单布局，以及任何视图树较小且数据流为单向的场景。我们正在使用它。在设计过程中，我们也会用它来预览效果——其迭代速度比 UIKit 更快。.

实际上，这意味着用于选择单元或导出数据的界面通常采用 SwiftUI 实现，并嵌入到主界面采用 UIKit 构建的应用程序中。这两种框架能够无缝共存，通过混合使用，我们可以充分发挥各自的优势，而无需将整个应用程序完全绑定到某一种实现方式上。.

（对我们来说）什么行不通

一旦某个界面需要自定义手势、对性能要求较高的列表、复杂的导航状态或精确的动画时机，我们就会转而使用 UIKit。原因并非出于炒作——而是因为如果不这么做，我们就会遇到那类 bug。 SwiftUI 在最近的几个版本中有了显著改进，但在运行时仍会以 UIKit 极少出现的方式给我们带来意外。.

具体案例很有帮助。打字练习软件需要确保每次按键都能立即显示出正确的字符，且无任何可见延迟，同时屏幕更新速度要跟上用户手指的节奏。 在旧款手机上，追踪器中记录的长期历史条目需要能够流畅滚动。支持拖放功能的日程表，其手势操作不应与系统自身的手势发生冲突。在这些类型的界面中，我们发现 UIKit 的表现更加可预测。.

权衡取舍

坚持使用 UIKit 并非没有代价。这意味着实现相同的界面需要编写更多的代码，也意味着新加入的开发者必须熟悉一个越来越少被教程提及的旧框架。一些新的系统功能会首先在 SwiftUI 中推出，而要在 UIKit 中实现这些功能则需要额外的底层实现工作。 我们也必须坦诚地承认，我们的谨慎部分源于熟悉感：对一个框架的深入了解固然有价值，但这也可能成为一种借口。.

此外还有一个悬而未决的问题。我们的 iPhone 和 iPad 应用已经可以在搭载 Apple Silicon 的 Mac 设备上运行，而且我们计划开发原生的 Mac 应用。如果 SwiftUI 能显著简化这些平台之间界面代码的共享，那么情况可能会有所改变。.

我们的失误

我们曾用 SwiftUI 实现过一个界面，纸面上看起来很简单，实际却并非如此：这是一个带有自定义滑动操作的列表，其状态会随着滚动而变化。该界面在预览中运行良好，但在真实设备上却表现异常。用 UIKit 重构它所花费的时间，反而比直接用 UIKit 开发还要多。 现在，我们会根据每个界面的实际功能需求，在开发初期就做出决定。.

这才是唯一的真正考验： 这会在实际制作中给我们带来惊喜吗？ 对于我们开发的大部分项目，答案是排除了将 SwiftUI 作为核心框架。我们明年会再重新考虑这个问题。