这是我参与「第四届青训营」笔记创作活动的的第十五天。本篇文章将会翻译stream网站中的《UIKit vs. SwiftUI: How to Choose the Right Framework for Your App》文章（作者：Jeroen L）。原文地址：getstream.io/blog/uikit-… 。
SwiftUI 和 UIKit 都是构建一个应用程序的绝佳框架。但是当开始一个新的 iOS Xcode 项目时，你必须做出选择。选择 UIKit 还是 SwiftUI 作为你的主要实现框架是一个重大的决定。我们将探讨这两个框架的一些特性，并列出它们的优缺点。
因此，让我们深入研究并帮助您确定哪种方法最好。
UIKit vs. SwiftUI：开始一个新项目
今天是个好日子。这一天，您将创建一个新的Xcode项目，您和您未来的团队将在这上面工作多年，这是多么重要的一天。在一个应用程序的一生中，有几个奇特的时刻，它很可能作为一个iOS代码库只经历一次。上传第一个构建到App Store是其中之一。另一个是创建Xcode项目本身。
在为你的项目命名之后，你将面临着最大的决定。选择SwiftUI或Storyboard。但是，使用Storyboard意味着UIKit。Xcode实际上是在问你："你想使用SwiftUI还是UIKit？"
作为iOS开发者，我们都知道UIKit和SwiftUI。但无论如何，让我们来认识一下这些竞争者，以确保我们都能得到正确的介绍。
UIKit
UIKit是一个框架，使你能够构建用户界面（UI），可以处理触摸事件和输入，同时管理用户、系统和你的应用程序之间的互动。
UIKit是CocoaTouch的一部分，它在2008年作为iOS SDK的一部分发布，并在iOS的第一个公开版本（当时被称为iPhoneOS）中提供。
在此之前，UIKit是为iOS的前两个版本私人开发的。UIKit于2008年公开发布，而且没有任何被苹果抛弃的迹象。有了UIKit，在构建iOS应用时，你可以获得最完整、功能最齐全的开发者体验。
UIKit是基于Objective-C语言开发和发布的。即使到了今天，你在为iOS平台开发时也会经常碰到Objective-C代码。越来越多的开发者开始使用Swift，但UIKit框架仍然是以Objective-C为基础构建的。
Objective-C是一种建立在C语言之上的语言，为C语言带来了类似Smalltalk的面向对象编程。Objective-C在苹果公司恢复和推出iPhone的过程中发挥了非常重要的作用。
SwiftUI
SwiftUI是苹果生态系统中一个相对较新的部分。我说 "相对 "是因为它是在2019年随iOS SDK的第13版首次发布的。但SwiftUI已经成熟到如此程度，以至于它现在是许多应用程序开发人员的可行选择，特别是在针对iOS 14+甚至15+时。然而，iOS 13上的SwiftUI有一系列特定的限制，减缓了iOS应用开发者的采用。
SwiftUI是一个UI框架，与UIKit相比，它采用了一种更加反应式的方法来开发你的UI。在UIKit中，布局你的视图是非常明确的。对窗口和UI的调整需要计算和更新尺寸，或者从视图层次中添加和删除视图。
另一方面，SwiftUI更强调定义你想在屏幕上看到的内容。当屏幕上的内容需要改变时，你定义新的状态，如果一切按计划进行，SwiftUI将计算所有的差异并自动更新显示给终端用户的表现。你可以对屏幕上发生的事情进行细粒度的控制。但即便如此，实际的渲染还是来自于对UI底层状态的修改。UIKit的工作方向正好相反；作为一个开发者，你需要检测什么已经改变，并主动更新整个UI以反映这个新的状态。
SwiftUI在很大程度上依赖于Swift中存在的语言功能。这一点很重要，因为苹果首先需要向Swift语言添加特定的功能，以便能够像现在这样创建SwiftUI。苹果在2014年公开发布了Swift，并在这些年里对该语言进行了大量更新。这些更新有些是小的，有些是比较重要的。问问任何在Swift早期从事iOS工作的开发者，他们可以分享一些关于在Swift版本之间迁移的故事以及其固有的挑战。
UIKit 和 SwiftUI 的主要区别
现在，我们将比较使用SwiftUI和UIKit的主要区别。我们将看看你如何定义你的UI，这两个框架的心理模型的差异，可用的文档和在线支持，最小的iOS版本，开发速度，多平台支持，以及两个框架的互操作性。最后，你必须决定在你的情况下什么是最重要的。
SwiftUI 中没有 Xcode Interface Builder
使用UIKit，你可以选择在代码中或在Interface Builder中定义你的整个UI。Interface Builder是Xcode的一部分，它允许开发者通过拖放许多UIKit UI组件来创建一个用户界面。
但在SwiftUI中，苹果已经抛弃了Interface Builder，转而使用Live Preview。实时预览会在你编辑时渲染你正在进行的SwiftUI代码。实时预览允许你直观地检查你的UI代码的某些方面，而且对你的代码的任何修改都会立即反映在实时预览中。
在使用实时预览时，有一些注意事项，但随着每个版本的发布，苹果的预期工作流程变得更好。而最重要的是，在使用实时预览时，Xcode变得越来越稳定。
UI更新是反应性的，而不是强制性的
如前所述，UIKit要求你作为一个开发者定义屏幕上的内容，屏幕何时更新，以及如何在不同的UI状态之间转换。在SwiftUI中，这以一种反应式的方式工作。终端用户在屏幕上看到的东西更多的是更新视图结构的副作用，让系统计算需要做什么来更新屏幕以反映这个新状态。这是一种不同的思维方式，也是开发者从UIKit转移到SwiftUI所要克服的最大挑战之一。
文档、支持和可用内容
与SwiftUI相比，UIKit的内容要多得多，但随着越来越多的团队采用SwiftUI，这种情况正在逐渐改变。在这方面，你必须考虑在UIKit上构建的现有代码库的数量。很多时候，由于支持的版本要求低于iOS 13，这些代码库根本无法采用SwiftUI，这一限制将在可预见的未来把许多正在进行的实际开发工作限制在UIKit上。
最低 iOS 版本
要使用SwiftUI，你必须接受iOS 13作为最低支持版本。如果这不可能，你就不能使用 SwiftUI。即使你能支持iOS 13，你也需要问问自己是否应该支持。在iOS 13中，SwiftUI是如此的有限--在某些地方甚至是坏的--以至于在一两个屏幕之外，它真的不可能应用于你的应用程序。它在iOS 14甚至iOS 15中会好得多，但同样，在你的情况下，什么样的最低目标版本是可以接受的？
另一方面，如果你愿意，UIKit目前允许你支持回到9.0版本。问题是你是否应该这样做，但如果需要的话，这种可能性是存在的。在大多数情况下，支持一个主要的iOS版本超过6年可能有点过了。但如果有这个需求，UIKit在向后兼容性方面就会胜出。
发展速度
现在，人们一致认为SwiftUI是开发应用内功能的最快方式（注意，这里的 "共识 "主要是基于iOS开发者的个人意见）。在网上，你会发现在UIKit和SwiftUI中开发相同功能的一些不错的比较。在这些比较中，很明显，一般来说，SwiftUI需要更少的代码来实现UIKit的相同结果。
不过有一点需要注意。SwiftUI在功能上远不如UIKit完整。每当SwiftUI缺乏UIKit中的功能时，你通常必须通过UIViewRepresentable协议将该功能从UIKit桥接到SwiftUI。
如果使用得当，SwiftUI的一大好处是，你的数据和显示你的数据的视图层次更松散地耦合。这让你在SwiftUI中重复使用现有的模型和视图层次逻辑时有了更大的灵活性。这也是SwiftUI的最大好处之一。正确使用 SwiftUI 可以促进你的代码中的抽象变得更干净。
另外，SwiftUI的实时预览功能（当它在工作时）大大提升了开发速度。SwiftUI的一个缺点是学习曲线比较陡峭，因为你要尝试用SwiftUI的方式来 "做用户界面"。与UIKit相比，熟悉SwiftUI的工程人才库也仍然小得多。但大多数iOS开发者都非常渴望了解--并亲身体验--实际的SwiftUI实现。
动画
使用SwiftUI，你可以免费获得大量漂亮的动画和过渡。而在UIKit中，除了一些基本的过渡，你必须在你的代码中明确定义动画。与SwiftUI相比，用UIKit使你的用户界面变得非常流畅需要付出努力。
显然，你可以影响SwiftUI所发生的事情，但由于它的声明性，你可以免费获得很多东西。
多平台支持
SwiftUI承诺可以在苹果的所有设备上工作。如果你在Apple Watch、iPhone或MacBook App上工作，应该没有关系。你的SwiftUI视图应该适应任何屏幕尺寸。不过，这并不意味着写一次就能在任何地方运行的情况。苹果明确表示这不是SwiftUI的情况或目标。主要是UI编程模型可以在苹果的生态系统中转移；当把为iPhone编写的SwiftUI代码转移到macOS时，你仍然必须投入工作，以确保它在新的环境中工作。
这确实打开了创建跨平台组件的大门，并允许你大大减少特定平台代码的数量。
小部件
如果你想在iOS上创建小部件，你必须为这些目标使用SwiftUI。在开发小部件时，没有办法使用UIKit。你可以在一个基于UIKit的应用程序中嵌入一个基于SwiftUI的小部件。只是要注意的是，小部件和SwiftUI是绑在一起的。
在这方面，小部件确实也提供了一个机会。小组件可以成为在一个完全基于UIKit的应用中做一些SwiftUI工作的绝佳的第一次机会。如果widget是一个需求，你就会有一些SwiftUI的编码。我想说的是，如果你对UIKit有充分的投资，并想更多地亲身体验SwiftUI，这是一个很好的机会。
UIKit 和 SwiftUI 之间的互操作性
UIKit 和 SwiftUI 可以一起工作。在 SwiftUI 视图中添加 UIKit 视图很容易，反之亦然。已经有一些关于如何在 UIKit 和 SwiftUI 之间进行互操作的好内容（只需搜索UIHostingController、UIViewRepresentable和UIViewControllerRepresentable）。
事实上，苹果也为此写了一些很棒的内容。
所以使用 SwiftUI 和 UIKit 并不是相互排斥的。但是 UIKit 和 SwiftUI 之间的接口确实是以复杂性为代价的，所以尽可能只使用这两个框架中的一个是更可取的。混合 UIKit 和 SwiftUI 时（仍然）有很多粗糙的边缘。
应该在下一个项目中使用什么？
我们试图在本文中回答的大问题。您应该在我们的下一个项目中使用 SwiftUI 还是 UIKit？
这完全取决于您的用例。我不能为你回答。我知道的一件事是，了解和熟悉 SwiftUI 很重要。
以下是我自己使用的一些粗略指南。
如果您可以对以下任何问题回答“是”，请选择 UIKit：
- 您是否需要最大限度地控制应用的外观和行为？
- 您想在开发过程中尽量减少意外和粗糙边缘吗？
- 您是否需要不适用于 SwiftUI 的特定功能、框架或 SDK？
- 您是否必须支持 iOS 12 和/或 iOS 13？
- 但不要小看 SwiftUI 的力量。
如果您对以下任何问题回答“是”，则可以使用 SwiftUI：
- 您想最大限度地提高开发速度（快速行动是优先事项）吗？
- 您的应用程序是否需要大量动画和过渡而无需太多努力和代码？
- 您想为 Apple 平台上应用程序开发的未来做好准备吗？
现在看来，UIKit 确实在这方面取得了胜利。这并不奇怪，因为 UIKit 比 SwiftUI 成熟得多。但每年 SwiftUI 都在变得更好。最重要的是，Apple 明确将 SwiftUI 标记为所有 Apple 平台上的开发未来。小部件甚至必须用 SwiftUI 编写。
不幸的是，目前还没有最终的答案，SwiftUI 和 UIKit 之间的选择在此时都是有效的。使用这两个框架都很有趣。而且我相信无论您选择哪种框架，您都可以构建出令人惊叹的东西。
