当我在Xcode中创建一个新的iOS项目，无论它是iPhone/iPad设备独占还是universal的，我做的第一件事总是删除Storyboard。

并且，和你们想象的不同，我并不是想用XIB来代替Storyboard，我完全不使用Interface Builder。
Treehouse论坛对此有很棒的讨论，并且我听到的说法总是类似：Interface Builder会鼓励做出坏的实践。
因为我之前有在Window平台使用Visual Studio开发的经验，我可以很自信的说，Interface Builder非常不好，至少与VS比较是这样。Visual Studio之所以更优秀，其原因之一在于标记式语言（XAML），它能被设计师使用，就像HTML相对于web一样。
不管怎么说，让我们回到iOS上来。
使用Interface Builder最坏的地方是，它让分解视图块以及从视图控制器（view controller）使用视图的工作大大增加了。它的后果是导致出现体积臃肿的视图控制器，而这是应该避免的，并且它们编辑起来简直是一个噩梦。
即使你做了这些多出来的工作，并且提取出部分UI到可重用的视图里，你在Interface Builder里看到的将是一个个白色块，里面包裹着可重用视图，但你不能直观的看到它们。（译者注：根据网友指出，最新版的Xcode已经能看到了）
另一个问题是outlets，在合并的时候它们可能偶然的断开连接，或者如果你在重用视图时忘记连接它们，你的应用会崩溃。
有些人可能会争论说，当面临屏幕适配问题时，使用Auto Layout和IB结合是一种好的解决办法。这一点我仍然不同意——首先我认为在IB中管理布局约束是噩梦，使用拖拽很难将视图调整到精确的位置，元素会 突然对齐到邻近的视图，并且当你添加多个box时，它们的层级顺序会打乱并且改变其它box。

与此对应的是，在Github上有不少Auto Layout的扩展（如Masonry、Snappy、PureLayout、Cartography），能帮你节省不少功夫。在将你的子视图实例化到视图控制器之后，你仅需要重写updateConstraints并设置约束条件，即可完成不同尺寸屏幕的适配。比如下面的示例使用了PureLayout库：

updateConstraints.swift

对于表格视图需要计算每个单元格的高度，以达到根据Auto Layout约束条件自动调整大小，代码可以很直观的完成这一点。特别是当iOS 8引入了UITableViewAutomaticDimension 选项之后。