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