何时使用情节提要和何时使用XIB
Answers:
我已经广泛使用了XIB，并使用情节提要完成了两个项目。我的学习是：
- 故事板非常适合屏幕数量少到中等且视图之间导航相对简单的应用。
- 如果您有很多视图并且它们之间有很多交叉导航，那么Storyboard视图将变得混乱，并且需要进行大量工作以保持清洁。
- 对于具有多个开发人员的大型项目，我不会使用Storyboard，因为您的UI仅有一个文件，因此无法轻松并行工作。
- 对于大型应用程序来说，将其拆分为多个情节提要文件可能是值得的，但我还没有尝试过。该答案显示了如何在情节提要之间进行监视。
- 您仍然需要XIB：在我的两个Storyboard项目中，我都必须将XIB用于自定义表格单元。
我认为情节提要是朝着实现UI正确方向迈出的一步，希望苹果公司将其扩展到将来的iOS版本中。但是，他们需要解决“单个文件”问题，否则它们对大型项目将不会有吸引力。
如果我启动一个小型应用程序，并且只能提供iOS5兼容性，那么我将使用Storyboard。对于其他所有情况，我都坚持使用XIB。
2016年1月12日更新：是2016年，我仍然更喜欢在代码中而不是在Storyboard中布置UI。话虽如此，情节提要已经走了很长一段路。我从这篇文章中删除了所有在2016年不再适用的观点。
2015年4月24日更新：有趣的是，Apple甚至没有像Peter Steinberger注意到的那样（在副标题“ Interface Builder”下）在最近开放源代码的ResearchKit中使用Storyboard 。
2014年6月10日更新：与预期的一样，Apple不断改进Storyboard和Xcode。适用于iOS 7及以下版本的某些要点不再适用于iOS 8（现在已标记为此类）。因此，虽然情节提要板本质上仍然存在缺陷，但我还是将我的建议从不使用修改为有选择地使用。
即使iOS 9已经发布，我还是建议 反对在决定是否使用情节提要时要格外小心。这是我的原因：
情节提要在运行时失败，而不是在编译时失败：您是否在segue名称中输入错字或在情节提要中将其错接？它将在运行时爆炸。您使用情节提要中不再存在的自定义UIViewController子类？它将在运行时爆炸。如果您在代码中执行此类操作，则将在编译期间及早发现它们。更新：我的新工具StoryboardLint主要解决了此问题。
情节提要快速变得混乱：随着项目的发展，情节提要变得越来越难以导航。另外，如果多个视图控制器与多个其他视图控制器有多个关卡，则情节提要很快就会开始看起来像一碗意大利面，并且您会发现自己放大和缩小并在各处滚动查找所要查找的视图控制器寻找并找出什么塞格点在哪里。更新：这个问题可以主要通过分割你的故事板最多可以解决成多个故事板，如在本文中通过Pilky和本文由罗伯特·布朗。
情节提要使团队工作更加困难：因为通常项目中只有一个庞大的情节提要文件，所以要让多个开发人员定期对一个文件进行更改可能会令人头疼：需要合并更改并解决冲突。当发生冲突时，很难说出解决方案的方式：Xcode生成情节提要XML文件，并且它的设计宗旨并不是要人类阅读，更不用说对其进行编辑了。
分镜脚本使代码审查很难或几乎不可能进行：对您的团队来说，对等代码审查是一件很棒的事情。但是，当您对情节提要进行更改时，几乎不可能与其他开发人员一起查看这些更改。您所能提供的只是一个巨大的XML文件的差异。弄清真正改变的内容以及这些改变是否正确或是否破坏了某些东西确实很难。
故事板会阻碍代码重用：在我的iOS项目中，我通常会创建一个类，其中包含在整个应用程序中使用的所有颜色，字体，边距和插图，以使其具有一致的外观和感觉：如果必须调整整个应用程序的所有这些值。如果在情节提要中设置了此类值，则将其复制，并且在要更改它们时需要查找每个出现的值。您很可能错过其中一项，因为在故事板中没有搜索和替换项。
情节提要板需要不断进行上下文切换：我发现自己在代码中的工作和浏览速度比情节提要板快得多。当您的应用使用情节提要时，您会不断切换上下文：“哦，我想在此表视图单元上点击以加载其他视图控制器。现在，我必须打开情节提要，找到合适的视图控制器，创建新的界面到另一个视图控制器（我也必须找到），给segue一个名称，记住该名称（我不能在情节提要中使用常量或变量），切换回代码并希望我不要键入错误的名称这是我的prepareForSegue方法的序号。我希望如何在我现在所在的位置键入那三行代码！” 不，不好玩。在代码和情节提要之间（以及在键盘和鼠标之间）切换会很快变老，并降低速度。
情节提要很难重构：重构代码时，必须确保它仍然与情节提要所期望的匹配。在情节提要中移动内容时，只有在运行时仍能与您的代码一起使用，您才会发现它。在我看来，我好像必须保持两个世界同步。我的拙见使我感到脆弱，使人沮丧。
故事板的灵活性较差：在代码中，您基本上可以做任何您想做的事情！使用情节提要板，您只能使用代码中的一部分。尤其是当您想对动画和转场进行一些高级操作时，您会发现自己正在“与情节提要进行战斗”以使其发挥作用。
情节提要不允许您更改特殊视图控制器的类型：您要将a更改
UITableViewController为aUICollectionViewController？还是变成平原UIViewController？在情节提要中不可能。您必须删除旧的视图控制器并创建一个新的视图控制器，然后重新连接所有segue。进行这样的代码更改要容易得多。情节提要向项目增加了两个额外的责任：（1）情节提要编辑器工具，用于生成情节提要XML；以及（2）运行时组件，用于解析XML并从中创建UI和控制器对象。这两个部分都可能包含无法修复的错误。
情节提要不允许您将子视图添加到
UIImageView：谁知道原因。情节提要不允许您为各个View（-Controller）启用自动布局：通过选中/取消选中情节提要中的“自动布局”选项，所做的更改将应用于情节提要中的所有控制器。（感谢SavaMazăre！）
情节提要具有更高的破坏向后兼容性的风险：Xcode有时会更改情节提要的文件格式，并且不以任何方式保证您可以打开几年后甚至几个月后今天创建的情节提要文件。（感谢这一点的思想优势。请参阅原始评论）
故事板可以使您的代码更加复杂：
init例如，在代码中创建视图控制器时，可以创建自定义方法initWithCustomer:。这样，您可以使customer视图控制器的内部不可变，并确保没有customer对象就无法创建该视图控制器。使用情节提要时这是不可能的。您将不得不等待prepareForSegue:sender:方法的调用，然后必须customer在视图控制器上设置属性，这意味着您必须使该属性可变，并且必须允许在没有customer对象的情况下创建视图控制器。以我的经验，这可能会使您的代码变得非常复杂，并且使您难以推理应用程序的流程。更新9/9/16：Chris Dzombak 就此问题写了一篇很棒的文章。这是麦当劳：用乔布斯（Steve Jobs）关于微软的话来说：麦当劳（视频）！
这就是为什么我真的不喜欢使用故事板的原因。其中一些原因也适用于XIB。在我从事的基于情节提要的项目上，这些项目花了我比他们节省的时间更多的时间，并且使事情变得更复杂而不是更加简单。
当我用代码创建UI和应用程序流时，我可以更好地控制正在发生的事情，更容易调试，更容易在早期发现错误，更容易向其他开发人员解释我的更改及其更容易支持iPhone和iPad。
但是，我确实同意，在代码中布局所有UI可能不是每个项目都适用的“一刀切”解决方案。如果您的iPad用户界面在某些地方与iPhone用户界面大不相同，则仅为这些区域创建XIB可能是有意义的。
上面概述的许多问题都可以由Apple解决，我希望这就是他们将要解决的问题。
只是我的两分钱。
更新：在Xcode 5中，Apple取消了创建没有Storyboard的项目的选项。我写了一个小脚本，将Xcode 4的模板（带有Storyboard-opt-out选项）移植到Xcode 5：https : //github.com/jfahrenkrug/Xcode4templates
创建故事板是为了帮助开发人员可视化其应用程序和应用程序流程。这很像一堆xib，但是在一个文件中。
有一个与此类似的问题。.xib文件和.storyboard有什么区别？。
您还可以通过代码创建自定义过渡，这些代码会根据需要动态更改，就像使用.xibs一样。
优点：
- 您可以在不编写太多代码的情况下模拟应用程序的流程。
- 更容易查看屏幕之间的转换和应用程序流程。
- 如果需要，还可将.xibs与情节提要一起使用。
缺点：
- 仅适用于iOS 5+。不适用于iOS4。
- 如果您的视图应用程序非常密集，可能会很混乱。
何时使用一种或另一种确实没有对/错，这只是一个偏好问题，以及您要使用的iOS版本。
我仅说明四个为什么要使用情节提要的简单原因，尤其是在必须由产品所有者，产品经理，UX设计师等组成的团队的高效环境中。
- 苹果极大改进了使用情节提要的使用。他们鼓励您与他们合作。这意味着他们不会通过更新破坏您的现有项目，他们将确保情节提要能够在以后的XCode / iOS版本中得到证明。
- 更明显的效果在更短的时间对产品的所有者和管理者，即使在创建阶段。您甚至可以将情节提要板本身用作屏幕流程图，并在会议中进行讨论。
- 即使在应用程序完成后（通常是生命周期开始的地方）–将来应用小调整将更快，更容易。这些很可能同时改变布局的多个方面，您可能希望以一种所见即所得的方式看到它们。替代方法是手写UI更改代码，并在IDE和模拟器之间来回切换以进行测试，每次等待编译和构建。
- 可以教会非开发人员在故事板中设置布局，并为开发人员创建必要的挂钩（IBOutlet和IBActions）。这是一个很大的优势，因为它使开发人员可以专注于逻辑，而UX设计人员可以以可视方式应用更改，而无需编写任何代码。
我不会写任何CONS，因为约翰内斯已经在他的回答中列出了所有可行的方法。而且其中大多数绝对是不可行的，尤其是没有XCode6的重大改进。
我认为您的问题没有一个正确的答案，这只是个人经验问题，您会感到更自在。
我认为，情节提要是一件了不起的事情。的确如此，要找出为什么您的应用程序在运行时异常崩溃的原因确实很困难，但是经过一段时间后，您会发现它始终与某些地方缺少的IBOutlet有关，并且您可以轻松进行修复。
唯一的实际问题是在带有情节提要的版本控制下的团队中工作，在开发的早期可能是一个真正的混乱。但是在第一步之后，很少会完全更改情节提要的UI更新，在大多数情况下，您最终会在xml的最后部分遇到冲突，这是segue引用，通常在您重新打开情节提要时会自动修复。 。在我们的团队工作中，我们更喜欢处理此问题，而不是使用大量的视图代码来处理繁琐的视图控制器。
我已经读过很多评论，这是自动布局。借助XCode5，它确实得到了改进，即使对于自动旋转的布局也非常好。在某些情况下，您必须在代码中执行某些操作，但是您可以简单地输出需要编辑的约束，然后在代码中执行所需的操作。甚至为它们设置动画。
我还认为，大多数不喜欢情节提要的人并没有完全尝试理解自定义手动segue的功能，在这里您可以完全自定义（在一个文件中）从一种方式过渡到另一种方式的功能，并且（一些技巧）甚至可以通过更新视图内容来重用以前加载的视图控制器，而不是完全重新加载整个视图。最后，您确实可以执行与代码中相同的操作，但是我认为您可以通过情节提要更好地分离关注点，但是我同意在许多方面它们缺乏功能（字体，图像作为彩色背景，ecc ... ）。
我没有在任何应用程序中使用StoryBoard或XIB。而是通过编程方式创建所有内容。
∆好处：
√您可以为创建任何复杂的UI或过渡动画UIView。
√支持所有iOS版本。无需担心<iOS 5。
√*您的应用将支持您代码中的所有iPhone / iPod / iPad设备。
√您会不断更新，因为您知道将始终有效的代码。
√*将在启动的任何（新）设备上正常工作–无需更改代码。
√一切由您决定。在某些地方，您想更改某些内容–无需查看情节提要或xib。只需在特定班级搜索它即可。
√最后但不是清单–您将永远不会忘记，如何以编程方式管理所有内容。这是最好的事情，因为您比任何人都知道控件深。
我从来不使用SB或XIB来发现问题，因为我对此很满意。
*如果您已经根据屏幕尺寸设置了UIKit的对象框架。
PS：如果您仍然没有做过这件事-您可能会遇到困难（或可能感到无聊），但是一旦熟悉了它-这对您来说真的是糖果。
如果您要关心Storyboard的性能，请观看WWDC 2015 Session 407
建立时间
界面生成器在编译情节提要时，首先要做的是两件事，它试图使应用程序的性能最大化，其次要使创建的nib文件的数量最小。
如果我有一个带有视图和一堆子视图的视图控制器，那么应该在构建时为该视图控制器创建一个nib文件，并为该视图创建一个nib文件。
通过为视图控制器和视图具有单独的nib文件，这意味着可以按需加载视图层次结构。
运行
当您使用UI故事板API分配一个故事板实例时，最初您要分配的内存就是UI故事板实例本身。
没有视图控制器还没有视图。
当您实例化初始视图控制器时，它将为该初始视图控制器加载笔尖，但同样，直到有人真正提出要求之前，尚未加载任何视图层次结构。
我一直在做一个合理大小的项目（用故事板的话说> 20个场景），遇到了很多限制，不得不反复去文档和Google搜索上做事。
UI都在一个文件中。即使创建多个情节提要板，每个情节提要板中仍然有许多场景/屏幕。这在中大型团队中是一个问题。
其次，它们不能与嵌入其他容器控制器等的自定义容器控制器一起使用。我们在Tabbed应用程序中使用MFSlideMenu，并且场景中有一个表。对于情节提要，这几乎是不可能的。花了几天的时间，我采取了XIB的方式进行完全控制。
IDE不允许选择处于缩小状态的控件。因此，在大型项目中，缩小主要是为了获得高水平的视图而已。
对于小组规模较小的小型应用程序，我将使用情节提要，对于中型小组/项目，我将使用XIB方法。
如果要在多个视图控制器中重用某些UI，则应使用XIB