我们是一个团队，为 iPad 创建一个非常大的应用程序，为弱势儿童提供电子阅读器。该应用程序构建到一半，我认为我们应该退后一步，审查应用程序的整个设计。我们正在构建的应用程序应该非常非常符合 iOS 的当前软件开发架构实践。我有解释以及以下问题：
该应用程序现在有大约 50 个视图（并且还在增加），大多数顶级视图在情节提要中（即单个情节提要），其他视图在 XIB 中（用于子视图、可重用的项目渲染器等）。
这种方法好吗？
现代 iOS 应用程序是否应该完全省略 XIB？
故事板应该是正确的，还是应该分解成子故事板？如果应该是，分解故事板的确切过程应该如何完成？如何确定模块？
如果您有一些以正确方式管理应用程序的技巧或一些经验法则来帮助简化和模块化应用程序，请在您的评论中提及。
很抱歉上面的文字很长，感谢您的阅读。
这有点主观，但在我看来，将 Xibs 与情节提要一起使用仍然是有效且可取的。故事板的想法很好，但是在当前的实现中它们肯定缺少一些功能，其中最明显的是视图重用。我最近参与了一些大型项目，故事板一开始总是很好，但迟早你会发现自己复制和粘贴表格单元格，然后是控制器，然后你必须在每次更新时在多个地方更改内容，这是完全无法维护。所以，是的，绝对坚持使用 Xib 文件以获得可重用的视图。
然而，我不太热衷于多个故事板的想法。虽然这在技术上很容易实现，但对我来说，它完全使故事板的目的无效。它们的唯一用途是（相对）清晰地概述控制器通过应用程序的流程。它们增加了一些小便利，但总的来说，我发现它们创建的代码通常比节省的代码多，并创建一些奇怪的代码模式（例如prepareForSegue:，当您想在需要属性设置的代码中使用控制器时，必须临时存储 ivars）。正如您所说，您如何将情节提要分成子情节提要？我只能认为您选择的任何分区方案都会有些武断，并且可能会在以后应用程序结构发生变化时发生变化，这根本没有乐趣。也许如果您的应用程序具有不同的操作模式，那么拆分情节提要是有意义的，但我认为这不适用于大多数应用程序。
所以，IMO，单一故事板，但使用 Xibs 来实现可重用的视图。