为什么iOS开发不需要Storyboard

随着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文件往往更大，加载速度也相应变慢。