跳转的话，sb不sb无所谓，因为完全可以用代码来激活跳转啊

1楼 @tinyfool 那界面开发呢，一直在纠结手写还是ib？我除了最开始学iOS的时候用过ib外，做项目一直手写界面。对ib做复杂界面，一直没有尝试过。

还不用过两者，喜欢犹豫。要是工作中让我遇见这样的程序员，请允许我躲的远远的

3楼 @jeffery ⊙﹏⊙b汗，大哥不能这么说，网络上尽量不要鄙视他人。前面问话我尽量小白一些，是希望更多人参与讨论。一个成熟的项目，技术选型或者调整需要很谨慎，不是想怎么样就怎么样，要充分评估可能出现的风险。

我这个问题的重点在于使用storyboard或者ib达成的应用复杂度。因为我参与过的这么多项目，复杂度远超大部分人能够接触过的项目，都是手写代码，所以对于storyboard或者ib能够承载的项目复杂度一直持谨慎态度（还有低版本iOS兼容性的考虑）。同时我其实也毫不怀疑storyboard或者ib在小项目或者工具类应用上的便利性。

这是为什么我想发起这个讨论的原因----手写代码和storyboard或者ib在实践中的边界在什么地方。storyboard和ib的项目在实施中会在什么时间点遇到不能解决或者克服的问题必须大量手写代码介入重构？手写代码的项目同样会在什么时间点会遇到不能解决或者克服的问题必须引入ib或者storyboard来解决？

我希望这个讨论比其他讨论更有意义的地方在于，我想尝试寻找的是两者最佳实践的边界而不是比较两者谁更好。

页面的控件不怎么改变，动画比较少的情况，我会选择SB，因为布局直观明了。

现在开发一般都是sb+手写代码两个交替使用，并不是说一个项目只能用SB或者只能是手写代码。

现在SB已经完善很多了，不过个人还是比较喜欢一个人开发的时候用SB，多人合作的时候可能需要解决很多冲突，最好一个人一个SB

还是喜欢自己手写

storyboard对于页面跳转的处理能像手写代码一样灵活。 可以先在storyboard上控制器之间连线，命名segue，代码判断是否跳转，再执行 [self performSegueWithIdentifier:@"xxxSegue" sender:nil]即可。

在主要组织页面关系的时候用连线，其余像登录控制器多处需要进行跳转的次要关系，就不要连线了。直接通过代码初始化控制器跳转，和使用xib类似。 UIStoryboard *storyBoard= self.storyboard;
UIViewController *viewController = [storyBoard instantiateViewControllerWithIdentifier:@"LoginViewController"];

总体上来说，Storyboard有以下好处：

• 你可以从storyboard中很方便地梳理出所有View Controller的界面间的调用关系。这一点对于新加入项目组的开发同事来说，比较友好。
• 使用Storyboard可以使用Table View Controller的Static Cell功能。对于开发一些Cell不多，但每个Cell都不一样的列表类设置界面会比较方便。
• 通过实现– (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender方法，每个View Controller的跳转逻辑都聚集在一处，这方便我们统一管理界面跳转和传递数据。
• Storyboard可以方便将一些常用功能模块化和复用。例如WWDC2011年介绍Storyboard的视频就将微博分享功能模块化成一个单独的Storyboard。我在开发App时，也将例如通过第三方注册登录模块做成一个单独的Storyboard，便于以后复用。

但是 Storyboard 也有非常大的缺点：

• 不方便继承和界面重用。
• 不利于多人协作时合并编辑的内容。

现在就我了解，国内主要的大公司都没有使用 storyboard ，别说 storyboard 了，对于xib 很多公司都不提畅使用。关于 autolayout , 可以使用 Masonry（ https://github.com/Masonry/Masonry ） 这样的开源库来手写实现。

另外，这儿有关于Facebook不用storyboard的讨论：http://qr.ae/Bs37O

我也写过一篇文章讨论过这个：http://blog.devtang.com/blog/2012/12/15/do-not-use-storyboard/

至于楼主提的问题，就像问“ VB 能够写多复杂的程序”一样，其实不太好。对于牛逼的人，用不用 storyboard 都不会限制你写出程序的复杂性，只是说爽不爽，方不方便，好不好用而已。

对于 8楼 @tangqiaoboy 说的2个缺点，我说下个人意见：

1. 不方便继承和界面重用。首先继承这个本身很多设计规范就不提倡，即使特殊情况下有也很少，更多的是组合。关于重用，完全可以写个可以在ib或sb上重用的一个自定义的ui。
2. 不利于多人协作时合并编辑的内容。这个根本不是问题，多人合作一般都负责不同的模块，不同的模块在ui界面上会有多大的冲突？即使多人基于storyboard开发，完全可以把storyboard拆分开来，你实现你模块的storyboard，他实现他的storyboard，又有什么问题？

1. 对不确定的值可以通过直观看的,反复调整某个值的,用sb会方便. 那么反之,如果你的项目里,大多数边界值事先都已经很清楚,那么这点优势也不明显了
2. 对于创建不是很多(或者不是很有规律,通过代码统一逻辑创建)的约束,或者,会比较快.
3. 对于有很多交叉跳转的时候, 在sb上划线其实很不方便了,即使画完, sb也会变得很乱. 这时更多的是通过id做跳转. 这时其实在跳转这块,和你在代码里写是一样的
4. 代码多了,其实和sb上面板多了,是一样的,如果不做好统一规划,维护起来都挺困难的

初学者,入门上手即 Storyboard 挺好的, 当然我算是个人开发者, 上面讲大公司的问题,我没有什么发言权. 但是,确实我很喜欢Storyboard 现在使用多个 Storyboard 来构建应用也是比较成熟的了, 使用的话: 1. 看看 WWDC 的视频 2. 试试吧,谁试谁知道 3. 有问题,提出来,应该有解的啊.