Xcode6提供的Interface Builder，为iOS界面创建提供了许多方便。但是，任何事物都存在两面性，这里对IB提出了几点思考。
一个Storyboard只对应一个UIViewController
这样的好处是显而易见的，权责分明，Storyboard负责界面的绘制，而UIViewController负责逻辑的整理。然而，这也说明了一个Storyboard无法对应多个UIViewController。这意味着如果两个界面基本相似，如果还是采用Storyboard的方式，则还得绘制两套基本相似的界面，对应的控件如果有相似的逻辑则得全部重新操作一遍。
简单的解决方法是把相同的部分以XIB文件的方式绘制为UIView，再在UIViewController中将UIView手动添加进去。虽然这样做还是违背了Storyboard的初衷，但也只能这样做了。
除此之外，Storyboard只能对应一个UIViewController也意味着这个Controller无法在被继承的同时携带Storyboard，就算你想利用父类的逻辑进行新的扩展优化也是无能为力的。
布局约束的使用场景
布局约束对于界面设计来说可谓节约了不少工作。不用特别关心某个控件的具体尺寸，而只关心它以怎样的方式存在于界面中，和其他控件之间的位置关系如何。
以最原始的方式使用布局约束，便是手动敲代码，但Objective-C在这方面可谓极度欠缺便捷性。几个简单的约束逻辑都需要敲上好几十行代码。好在有其他第三方库封装了这些逻辑并以极简的方式提供给开发者使用。IB中当然也提供了约束的设置，并且在设置、查看、重置界面这几个方面来说都寄予了开发者极大的方便。
虽然IB把开发者从繁杂的代码中解放出来，但并不意味着能在各个方面都如此。在维护方面，IB上的约束显然没有那么便捷。试想一下你接手了一个模块，某个Storyboard里的界面到处都是约束，你会作何感想？如果要在此基础上添加或删除控件，很容易又把界面弄得一团糟。
解决方法显然是不要用太复杂的约束，道理和写代码一样。如果界面复杂，说明界面也需要重构，把整个Storyboard里的界面按功能切分，整理为不同的XIB文件。这样的代码对于别人来说，噩梦或许会少一点。