Question

为什么iOS开发不需要Storyboard

Answer 1

当我在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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

override func updateConstraints() {
super.updateConstraints()

self.buildStatusIndicatorView.autoPinEdgesToSuperviewEdgesWithInsets(UIEdgeInsetsZero, excludingEdge: ALEdge.Trailing)
self.buildStatusIndicatorView.autoSetDimension(ALDimension.Width, toSize: 10)

self.buildNumberLabel.autoPinEdgesToSuperviewEdgesWithInsets(UIEdgeInsets(top: 5, left: 15, bottom: 5, right: 5), excludingEdge: ALEdge.Bottom)
self.buildNumberLabel.autoSetDimension(ALDimension.Height, toSize: 23)

self.branchLabel.autoPinEdge(ALEdge.Top, toEdge: ALEdge.Top, ofView: self.contentView, withOffset: 10)
self.branchLabel.autoPinEdge(ALEdge.Trailing, toEdge: ALEdge.Trailing, ofView: self.contentView, withOffset: -10)

self.commitMessageLabel.autoPinEdge(ALEdge.Top, toEdge: ALEdge.Bottom, ofView: self.buildNumberLabel, withOffset: 10)
self.commitMessageLabel.autoPinEdgeToSuperviewEdge(ALEdge.Leading, withInset: 15)
self.commitMessageLabel.autoPinEdgeToSuperviewEdge(ALEdge.Bottom, withInset: 5)
self.commitMessageLabel.autoConstrainAttribute(ALAttribute.Width, toAttribute: ALAttribute.Width, ofView: self.contentView, withOffset: -20)
}

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

Answer 2

随着iOS开发发展至今，可以说在UI制作上大家逐渐分化为了三种主要流派：使用代码手写UI及布局；使用单个xib文件组织viewController或者view；使用StoryBoard来通过单个或很少的几个文件构建全部UI。
手写代码
代码UI可以说具有最好的代码重用性。如果你的目的是写一些可以高度重用的控件提供给其他开发者使用，那毫无疑问最好的选择应该是使用代码来完成UIView的子类。这样进一步的修改和其他开发者在使用时，都会方便不少。使用代码也是最为强大的，会有xib或者StoryBoard做不了的事情，但是使用代码最终一定能够完成所要的需求。
XIB
其实IB和xib是从iOS SDK初次面世开始就是捆绑在开发者工具套装内的内容了，而到了Xcode 4之后更被直接集成到了Xcode中成为了IDE的一部分。xib设计的一大目的其实是为了良好的MVC：一般来说，单个的xib文件对应一个ViewController，而对于一些自定义的view，往往也会使用单个xib并从main bundle进行加载的方式来载入。IB帮助完成view的创建，布局和与file owner的关系映射等一些列工作。对于初学者来说，牢记xib的文件都是view的内容，有助于建立起较好的MVC的概念，从而在开发中避免或少走弯路。
最大的问题在于xib中的设置往往并非最终设置，在代码中你将有机会覆盖你在xib文件中进行的UI设计。在不同的地方对同一个属性进行设置，这在之后的维护中将会是噩梦般的存在。因为其实IB还是有所局限的，它没有逻辑判断，也很难在运行时进行配置。
StoryBoard
简单理解来说，可以把StoryBoard看做是一组viewController对应的xib，以及它们之间的转换方式的集合。在StoryBoard中不仅可以看到每个ViewController的布局样式，也可以明确地知道各个ViewController之间的转换关系。
现在StoryBoard面临的最大问题就是多人协作。因为所有的UI都定义在一个文件中，因此很多开发者个人或企业的技术负责人认为StoryBoard是无法进行协作开发的，其实这更多的是一种对StoryBoard的陌生所造成的误解。虽然Apple并没有在WWDC明确提及，但是没有人规定整个项目只能有一个StoryBoard文件。
现在会有一些对于StoryBoard性能上的担忧。因为相对于单个xib来说，StoryBoard文件往往更大，加载速度也相应变慢。

Answer 3

开发不需要Storyboard主要是容易造成svn的冲突，几乎都要修改。
主要还是看自己的选择，对于多数开发者而言，Storyboard为快速开发所带来直接价值是不可抹灭的。但对一些资深开发者及代码洁癖者来说，却会使其代码及配置相对臃肿或引来不必要的麻烦。

Answer 4

简单理解来说，可以把StoryBoard看做是一组viewController对应的xib，以及它们之间的转换方式的集合。在StoryBoard中不仅可以看到每个ViewController的布局样式，也可以明确地知道各个ViewController之间的转换关系。
现在StoryBoard面临的最大问题就是多人协作。因为所有的UI都定义在一个文件中，因此很多开发者个人或企业的技术负责人认为StoryBoard是无法进行协作开发的，其实这更多的是一种对StoryBoard的陌生所造成的误解。虽然Apple并没有在WWDC明确提及，但是没有人规定整个项目只能有一个StoryBoard文件。
现在会有一些对于StoryBoard性能上的担忧。因为相对于单个xib来说，StoryBoard文件往往更大，加载速度也相应变慢。

Answer 5

随着iOS开发发展至今，可以说在UI制作上大家逐渐分化为了三种主要流派：使用代码手写UI及布局；使用单个xib文件组织viewController或者view；使用StoryBoard来通过单个或很少的几个文件构建全部UI。
手写代码
代码UI可以说具有最好的代码重用性。如果你的目的是写一些可以高度重用的控件提供给其他开发者使用，那毫无疑问最好的选择应该是使用代码来完成UIView的子类。这样进一步的修改和其他开发者在使用时，都会方便不少。使用代码也是最为强大的，会有xib或者StoryBoard做不了的事情，但是使用代码最终一定能够完成所要的需求。
XIB
其实IB和xib是从iOS SDK初次面世开始就是捆绑在开发者工具套装内的内容了，而到了Xcode 4之后更被直接集成到了Xcode中成为了IDE的一部分。xib设计的一大目的其实是为了良好的MVC：一般来说，单个的xib文件对应一个ViewController，而对于一些自定义的view，往往也会使用单个xib并从main bundle进行加载的方式来载入。IB帮助完成view的创建，布局和与file owner的关系映射等一些列工作。对于初学者来说，牢记xib的文件都是view的内容，有助于建立起较好的MVC的概念，从而在开发中避免或少走弯路。
最大的问题在于xib中的设置往往并非最终设置，在代码中你将有机会覆盖你在xib文件中进行的UI设计。在不同的地方对同一个属性进行设置，这在之后的维护中将会是噩梦般的存在。因为其实IB还是有所局限的，它没有逻辑判断，也很难在运行时进行配置。
StoryBoard
简单理解来说，可以把StoryBoard看做是一组viewController对应的xib，以及它们之间的转换方式的集合。在StoryBoard中不仅可以看到每个ViewController的布局样式，也可以明确地知道各个ViewController之间的转换关系。
现在StoryBoard面临的最大问题就是多人协作。因为所有的UI都定义在一个文件中，因此很多开发者个人或企业的技术负责人认为StoryBoard是无法进行协作开发的，其实这更多的是一种对StoryBoard的陌生所造成的误解。虽然Apple并没有在WWDC明确提及，但是没有人规定整个项目只能有一个StoryBoard文件。
现在会有一些对于StoryBoard性能上的担忧。因为相对于单个xib来说，StoryBoard文件往往更大，加载速度也相应变慢。