Paul Hudson
@twostraws September 16th 2019
每个有经验的iOS开发人员都熟悉Interface Builder和Storyboard，甚至XIB也是如此。他们可能不喜欢它们，但至少对它们熟悉。如果您以前从未使用过这些功能，则应该跳过此位。
还在？好的-这意味着您以前使用过IB，并且可能会对SwiftUI的不同感到好奇。
好吧，让我问您一个问题：您是否曾经手动编辑情节提要或XIB？
可能不会。好吧，除了那一次，但答案是肯定的-故事板和XIB包含相当多的XML，这些XML不容易阅读或编辑。
更糟糕的是，情节提要有一种随着时间而变得越来越大的习惯。当然，它们可能从很小的地方开始，但是随后您又添加了另一个视图控制器和另一个视图控制器，然后突然您意识到在一个文件中有十个数据屏幕，并且您对源代码所做的任何更改突然变得非常痛苦。
但是，尽管单点故障并不好，并且基本上无法看到有人通过对故事板进行修改而打开拉取请求时发生了什么变化，但故事板和XIB的问题更大。
您会看到，Interface Builder对我们的Swift代码一无所知，而我们的Swift代码对Interface Builder也一无所知。结果，我们最终得到了许多不安全的功能：我们将Ctrl从IB拖动到我们的代码中，以将某物连接到一个动作，但是如果我们删除该动作，代码仍然可以编译– IB真的不介意代码是否它打算呼叫不再存在。
类似地，当我们从情节提要板或出列表视图单元格创建视图控制器时，我们使用字符串来标识代码中的重要对象-一个如此普遍的系统，它甚至有自己的名称：“字符串类型的API”。即使这样，我们也需要使用类型转换，因为Swift不能知道它返回的表视图单元实际上是MooncakeTableViewCell。
存在这些问题是因为IB和Swift是非常不同的东西。这并不是一个很大的惊喜– Interface Builder不仅可以追溯到原始Mac OS X诞生之前，还可以根据Objective-C的工作方式进行设计。
SwiftUI在过去很难过。这是一个仅限Swift的框架，不是因为Apple决定是时候让Objective-C死亡，而是因为它可以让SwiftUI充分利用Swift的全部功能-值类型，不透明的返回类型，协议扩展等等。
无论如何，我们很快就会确切介绍SwiftUI的工作方式。到目前为止，您至少需要知道的是，SwiftUI修复了人们使用旧的Swift + Interface Builder方法所遇到的许多问题：
- 我们不再需要讨论基于程序设计或基于情节提要的设计，因为SwiftUI同时为我们提供了两者。
- 提交用户界面工作时，我们不再需要担心会产生源代码控制问题，因为代码比情节提要XML更易于阅读和管理。
- 我们不再需要为字符串类型的API担心太多了-仍然有一些，但数量大大减少了。
- 我们不再需要担心不存在的调用函数，因为我们的用户界面已由Swift编译器检查。
- 因此，我希望您会同意，迁移到SwiftUI可以带来很多好处！