SwiftUI 对比 Interface Builder an

每个有经验的iOS开发人员都熟悉interfacebuilder和storyboard。你可能不喜欢它们，但至少熟悉它们。如果你以前没用过这些，可以跳过这一章。

还在这里吗？好的-这意味着你以前用过IB，可能很好奇SwiftUI有什么不同。

好吧，让我问你一个问题：你经常手工编辑storyboard或XIB吗？

可能很少或没有。好吧，但总的来说答案是否定的——interfacebuilder和storyboard包含大量不易阅读或编辑的XML。

更糟糕的是，storyboard会随着开发时间的推移，变得越来越大。当然，它初始时很小，但是再你添加了一个又一个视图控制器后，会意识到在一个文件中有十多个视图的数据，你所做的任何源代码管理更改都会变得非常痛苦。

还有一个很糟糕的缺点就是，当开发人员通过源代码管理下拉该文件时，无法明显看到改动信息。XIB也是如此。

IB使用时，接口生成器对我们的Swift代码了解不多，而我们的Swift代码对Interface Builder也知之甚少。结果，我们最终得到了很多不安全的功能：我们用Ctrl键从IB拖动到我们的代码中来连接某个动作，但是如果我们删除了这个动作，代码仍然可以编译—— 说明IB真的不在乎它要调用的代码是否存在。

storyboard也是类似的，当我们在storyboard创建TableViewCell ，或者 创建视图控制器view controll时，我们使用字符串来标识代码中的重要对象，甚至有自己的名称：“stringly typed api”。即使这样我们也需要使用类型转换，因为Swift无法知道storyboard返回的TableViewCell的具体类型。

导致问题存在是因为 IB、storyboard和Swift 是各自独立的。

SwiftUI打破了这种传统方式。它是一个只支持Swift的UI框架，这并不是因为苹果认为Objective-C是时候消亡了，而是因为SwiftUI可以充分利用Swift的所有功能——值类型、不透明返回类型、协议扩展等等。

不管怎样，我们很快就会知道SwiftUI是如何工作的。目前至少需要知道的是，SwiftUI修复了人们使用旧Swift+Interface Builder方法时遇到的许多问题：

1 不再需要争论程序设计或基于故事板的设计，因为SwiftUI同时给了我们两者。

2 不再需要担心在提交用户界面工作时会产生源代码管理问题，因为代码比脚本XML更易于阅读和管理。

3 不必太担心string类型的api了——仍然有一些，但明显更少。

4 不再需要担心调用不存在的函数，因为我们的用户界面由Swift编译器检查。

上述都是迁移到SwiftUI的好处。

概念Interface Builder

xib和nib都是Interface Builder的图形界面设计文档，nib这个名字来自于NeXTSTEP系统，在NeXTSTEP被Apple收购之前，一直使用nib作为Interface Builder的图形文档，nib的发展经过了nib2.0,nib3.0，到NeXTSTEP被Apple收购之后，带有NeXTSTEP标志的nib被换成了xib

与nib不同的是，xib是一个XML格式的纯文本文件，而nib是一个二进制文件，xib比nib有个很明显的好处，就是xib可以很方便地进行diff操作。由于xib是文本文件，所以在版本控制和管理方面比nib更有优势。然而，不论在 Interface Builder中选择的是nib还是xib格式，Xcode编译后都将得到一个供程序运行时使用的经过编译的二进制nib文件。

引用《Cocoa Programming for Mac OSX》一书的说法，Interface Builder 把窗口、菜单栏以及窗口上的各种控件的对象都“冻结”在了一个 NIB文档里面了；程序运行时，这些对象将会“苏醒”。