对于大多数开发者而言，Storyboard为快速开发所带来直接价值是不可抹灭的。但对一些资深开发者及代码洁癖者来说，却会使其代码及配置相对臃肿或引来不必要的麻烦，那么，iOS开发究竟需不需要Storyboard？ 当我在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里看到的将是一个个白色块，里面包裹着可重用视图，但你不能直观的看到它们。 另一个问题是outlets，在合并的时候它们可能偶然的断开连接，或者如果你在重用视图时忘记连接它们，你的应用会崩溃。 有些人可能会争论说，当面临屏幕适配问题时，使用Auto Layout和IB结合是一种好的解决办法。这一点我仍然不同意——首先我认为在IB中管理布局约束是噩梦，使用拖拽很难将视图调整到精确的位置，元素会突然对齐到邻近的视图，并且当你添加多个box时，它们的层级顺序会打乱并且改变其它box。 与此对应的是，在Github上有不少Auto Layout的扩展，如Masonry、Snappy、PureLayout、Cartography等，能够帮你省却不少功夫。在将你的子视图实例化到视图控制器之后，你仅需要重写updateConstraints并设置约束条件，即可完成不同尺寸屏幕的适配。比如下面的示例使用了PureLayout库： updateConstraints.swift 对于表格视图需要计算每个单元格的高度，以达到根据Auto Layout约束条件自动调整大小，代码可以很直观的完成这一点。特别是当iOS 8引入了UITableViewAutomaticDimension选项之后。 英文文章来源：Martin Normark's Blog，译文出自：idlelife，译者：pockry |
