使用故事板一段时间之后我发现它们非常有用，但它们确实有一些限制或者至少是不自然的做事方式。 虽然看起来应该为您的应用程序使用单个故事板，但是当您达到中等大小的应用程序时，这会出现几个问题。
所以我的问题是什么是最佳使用方法？
我考虑过使用混合方法将逻辑任务拆分为单独的故事板，但这会导致UX流在代码和故事板之间分开。 对我而言，这感觉是创建可重用行为（如登录操作等）的最佳方式。
我还应该考虑一下Xibs的地方吗？ 本文对许多问题进行了很好的概述，并提出对于只有一个屏幕的场景，在这种情况下应该使用xib。 再次，这对我来说不太常见，Apples支持从故事板中实例化未连接的场景，这表明xib将来不会占有一席之地，但我可能错了。
你是对的，分解故事板是最好的方法。 分解不仅仅是使UI的一部分更具可重用性。 它还使团队中的故事板更易于管理。
最近，我的许多故事板都包含四个或更少的场景。 对于一个人来说，单独构建和维护一个或多个这样的UI模块是很容易的。 这种做法减少或消除了合并冲突。
如果我确实需要在其他人拥有的故事板中更改某些内容，我会先询问所有者他或她是否有任何本地更改。 如果是这样，我有时会让所有者为我添加更改。 分解仍然需要一些协调，但它远远低于完整的应用程序故事板。 自从我开始这种做法以来，我没有任何合并困难。
至于XIB，我认为我在文章中没有写到足够多的内容。 它们仍然非常有用。 它们对单视图控制器很有用。 然而，这不是他们真正发光的地方。 XIB具有故事板可能永远不会具有的一个优点。 XIB最基本的单元是UIView，而故事板的基本单元是UIViewController。 由于XIB可以容纳UIViews的集合，因此它们非常适合可视化创建自定义控件。 在XIB中，我可以直观地构建旋转拨盘或GPS小部件。 然后我可以将这些控件和小部件放到故事板或其他XIB中。 这些XIB在iPad应用程序中更常出现，因为它们具有能够容纳许多控件和小部件的更大屏幕。 在故事板中的UIViewController中构建UISwitch是不自然的。
现在是最好的消息。 可以在Interface Builder中连接故事板，而无需编写任何代码。 我计划在WWDC之后发布这种技术，因为Apple可能会在iOS 6中发布类似的功能。但是，既然你问过，我现在决定发布它。 我可以在我的博客和GitHub上找到更多详细信息，而不是重复我对RBStoryboardLink如何工作的解释。 这将使您的UIStoryboard体验更加愉快。
我发现这篇文章在使用StoryBoard时提到了很多问题，作者提出的一件事是在一个StoryBoard中使用了大量的nib文件，我同意他不应该这样做，但还有其他问题，例如：
我的根视图控制器已经成为许多segue的源视图控制器，因此它的prepareForSegue：已经成为一个愚蠢的大方法，填充了很多“if（segue.identifier isEqualToString：@”......“）”语句连续
和
可以在故事板中为视图控制器分配标识符。 不幸的是，这个标识符属性没有在UIViewController类中公开。 这使得在运行时很难对视图控制器层次结构进行安全的内省。 如果为视图控制器和segue公开了标识符，那将是非常好的。
还有...更多其他问题，我认为它确实有意义，我担心现在应该或不应该使用StoryBoard？