很多人在问我关于 SwiftUI 的问题，我也已经尽力去问其他知道得更多的人，并试图找到合适的明确答案。
所以，现在开始...
这个问题已经被问过很多次了，所以我在本书中专门加了一章，以便能更详细地回答这个大问题：你应该学习 SwiftUI，UIKit，还是两者都学？
SwiftUI 可以在 iOS 13、macOS 10.15、tvOS 13 和 watchOS 6，以及这些平台的后续版本上运行。这意味着，如果你从事开发的应用必须支持 iOS N-1 甚至 N-2 ——即当前版本和之前的一两个版本--那么你能提供的功能就会受到限制。
然而，重要的是你不要把 SwiftUI 想成是一个类似于 Java 的 Swing 或 React Native 的多平台框架。官方的说法似乎是，SwiftUI 不是一个多平台框架，而是一个在多平台上创建应用程序的框架。
这听起来可能是一样的，但有一个重要的区别。苹果并不是说你可以在每个平台上使用相同的 SwiftUI 代码，因为有些事情是不可能的--例如，没有办法在 Mac 上使用苹果手表的数字表冠。
SwiftUI 的许多部分直接建立在现有的 UIKit 组件之上，例如 UITableView。当然，还有许多其他部分不是--它们是由 SwiftUI 而非 UIKit 渲染的新控件。
但问题的关键不在于 UIKit 在多大程度上参与其中。相反，重点是我们并不关心。SwiftUI 或多或少地完全掩盖了 UIKit 的行为，所以如果你为 SwiftUI 编写应用程序，而即使苹果在两年内用一只会唱歌的大象取代了 UIKit，你也不必在意--只要苹果让大象兼容 UIKit 暴露给 SwiftUI 的相同方法和属性，你的代码就不会改变。
虽然 Auto Layout 肯定被用于幕后的一些事情，但它并没有暴露给我们这些 SwiftUI 开发者。相反，它使用了一个灵活的盒式布局系统，这对来自 web 端的开发者来说是很熟悉的。
SwiftUI 的速度快得惊人--在我迄今为止的所有测试中，它似乎都超过了 UIKit。在与制作它的团队交谈后，我开始明白了其中的原因：首先，他们积极地扁平化了他们的层级结构，所以系统执行了更少的绘制，但其次，许多操作可以完全绕过 Core Animation，直接进入 Metal 以获得额外的速度。
所以，是的：SwiftUI 的速度快得惊人，而且我们不需要做任何额外的工作。
在使用 SwiftUI 时，能够同时看到视图的代码和视图的预览--它的外观--是非常有用的。 如果你能看到代码而不是预览，那么你有可能需要进入编辑器菜单并确保 Canvas 已启用。
当你对预览做任何改变时，它也会更新生成的代码。同样地，如果你改变了代码，它也会更新用户界面。因此，代码和预览是相同的，并始终保持同步。
SwiftUI 给我们提供了标准的系统颜色，如红色、蓝色和绿色，但这些并不是你可能习惯的 UIColor 的纯红色、蓝色和绿色。相反，这些是自动适应明暗模式的新风格颜色，这意味着它们会根据你的系统外观看起来更亮或更暗。
不！苹果在 WWDC19 和 WWDC20 都推出了大量的新功能。如果苹果仍然在 WWDC 上谈论 UIKit 的新功能，那么你就相当安全了--他们不会有出其不意地退役的风险。
可以！你可以把一个嵌入到另一个里面，而且效果很好。