自从
在
随 iOS 13 一起发布以来，我一直在关注它的动态，甚至
，但我一直避免使用它。正如我
，我主要是想避免处理与使用 UIKit 相比可能降低我的工作效率的错误和变通方法，我对此非常了解。
我对学习和使用它非常感兴趣，只是考虑到 Apple 的一些历史，比如 Swift 的早期，我有点犹豫。
我毫不怀疑 SwiftUI 将成为 Apple 平台开发的未来，问题是这个未来何时到来。
今年，该框架将在 iOS 15 中推出第三个主要版本。 SwiftUI 已经走了多远，它准备好构建严肃的应用程序了吗？
投票结果
我决定在 Twitter 上询问 Apple 开发者社区的想法。在一项民意调查中，我询问了那些有 SwiftUI 经验的人，他们是否认为该框架已准备好构建整个应用程序——用于严肃的项目，而不是业余项目。我在macOS 和 iOS 之间进行了分解，因为每个平台的 API 覆盖范围不同。以下是结果，共有 737 人参与：
-
是的，SwiftUI是完全两个平台上准备：
30.7％
-
SwiftUI 仅适用于 iOS：
23.1%
-
SwiftUI 仅适用于 macOS：
0.5%
-
SwiftUI尚未准备好使用：
45.7%
从这个结果来看，我不应该指定特定于平台的选项，因为大多数苹果开发人员只做 iOS 开发。无论结果如何，这都是关于整个社区如何看待该框架发展状况的一次调查。我也承认推特的调查不是很科学，并不是每个人都使用推特。鉴于上述所有情况，我认为相对公平的说法是：五五开。一半的开发人员已经开始使用 SwiftUI，而另一半还不愿意尝试。
SwiftUI 的期待功能
推特上有很多关于 SwiftUI 的讨论，在此我将尝试提炼和总结大家的意见，以及来自社区的其他评论和资源。
大家的普遍看法是 SwiftUI 还不够成熟，无法利用它编写整个应用，即 100% 纯 SwiftUI。原因有两个。
首先，它可能缺少必需的API，因此你必须借助UIKit。其次，你可能会发现一些bug或性能问题，必须通过UIKit来解决。尽管如此，如果遇到适合 SwiftUI 的情况，它也会大放异彩。首先，它可能缺少必需的API，因此你必须借助UIKit。其次，你可能会发现一些bug或性能问题，必须通过UIKit来解决。尽管如此，如果遇到适合 SwiftUI 的情况，它也会大放异彩。
SwiftUI 可以大幅加快开发速度。因此，你需要权衡利弊。
你必须混合使用 SwiftUI 和 UIKit。利用 100% SwiftUI 编写应用可能还需要再等几年。
多平台功能似乎还没有准备好，特别是 macOS API 似乎不太受关注。根据我尝试多平台示例应用的经验，某些 API 在 macOS 上的行为与我的预期不符，产生了一些奇怪的结果。
采用（或增加现有采用率）的最大障碍之一是 SwiftUI 一年一次的发布周期。新的 API 和错误修复需要等待一整年，这太难了。似乎在 iOS 13 中使用 SwiftUI 开发应用特别艰难，但 iOS 14 做了大量改进，并且 iOS 15 推出了大量新 API。
Steve Troughton-Smith表示：
由于 SwiftUI 只展现了部分 UIKit 和 AppKit 中存在的功能，因此很难判断 SwiftUI 一年一次的发布周期是否合理，而且缺乏后台的部署非常痛苦。[...] 以 iOS 15 中添加的新表单样式为例：目前这项功能还没有公开给SwiftUI [...]
你应该采用什么方法来构建应用？在听取了Noah Gilmore 的讨论之后，似乎利用 UIKit 编写App Delegate 并在 UIKit 中处理导航是个好主意。换句话说，有了 UIKit shell 和 SwiftUI 核心，至少可以在可能的情况下使用 SwiftUI。Noah 还建议首先尝试在 SwiftUI 中构建一个视图，如果行不通，则只能使用 UIKit。大多数情况下效果都很好。
对我来说，似乎目前“UIKit shell”是最好的方法。我知道这些框架都可以互操作，但从 UIKit App Delegate（或 Scene Delegate）着手比较靠谱。如果你非常熟悉 UIKit ，则无需从一开始就完全致力于 SwiftUI。简单来说，拥有一个“UIKit shell”就是留一手，在必要时方便退出 SwiftUI。
我有一个想法，刚开始利用 SwiftUI 编写表格视图或集合视图单元格。这似乎是一种将 SwiftUI 代码引入代码库的合理且可控的方式。然而，事实证明，这可能很棘手，因为 SwiftUI 单元格无法提供与 UIKit 相同的功能。对于某些需求来说这样做没问题。如果有问题，那么应用中的某些功能就只能完全使用 SwiftUI 的 List 或 UIKit 的 UITableView了。
另外，你需要想办法处理一些bug或问题（jessesquires.github.io/TIL/apple\_… UIKit 上投入一定的工作量。特别是有些应用的生命周期和导航会涉及很多 SwiftUI 的问题、bug或缺乏API。
App 的功能和灵活性都不如 UIApplicationDelegate。但是，正如 John Sundell 指出的那样，你可以同时使用这两个组件。
NavigationView 和 NavigationLink API的功能很有限，无法支持 UIKit 提供的功能。Omar 的这篇帖子（obscuredpixels.com/abstracting… API 以及提供导航层的技术。
根据我从苹果给出的示例和文档中看到的示例代码，与 UICollectionViewCompositionalLayout 的强大功能相比，LazyVGrid 和 LazyHGrid API 似乎非常弱。但是，有一些技术可以组合复杂的界面。
SwiftUI 的文档非常匮乏。我说的不是 API 文档，而是概念文档。请参见 Howard Oakley 的帖子（eclecticlight.co/2021/06/13/…
-
但是，仅通过查看 API 中的各个函数，根本不可能了解诸如属性文本之类的主要主题。首先，你需要了解子系统的设计和运作方式，以前苹果都会提供这些概念信息。正如苹果所熟知的那样，良好的概念文档的结构和编写方式与API 的类和函数的文档完全不同。
-
Howard在从整体上讨论了苹果的文档问题。然而，像 SwiftUI 这样的框架缺乏概念文档尤其应当。目前我们必须依靠个人调查和实验来获取有关其内部运作方式的信息。
总结
最后，SwiftUI 在某些方面还有很长的路要走。可能还需要好几年才能追赶上 UIKit。
Steve Troughton-Smith表示：
今年的这些Q&A是一个很好的资源，尽管一些交流确实突出了 SwiftUI 还有很长的路要走。
无法设置表格背景颜色，无法更改状态栏样式，没有新的工作表样式，没有自定义时间选择器的间隔……
终有一天这些 API 的限制都会减少，但一年一次的发布周期很难让 SwiftUI 赶上 UIKit。
我希望通过本文，为像我一样正在考虑是否以及应该开始使用 SwiftUI 的人提供一些帮助。如果你的目标是iOS 14 及更高版本，尤其是 iOS 15，那么现在就可以开始尝试了。
