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