我在一家公司工作，我们有几个iOS开发人员，我们一起使用GIT在同一个项目中工作。我们从不在开发过程中使用Storyboards或.xib文件，因为几乎不可能正确地合并它们。
随着iOS7的推出，我想到了Storyboard和编码所有UI“旧方法”之间的根本区别，而没有使用Interface Builder。
这里有没有人这样做？最重要的是，你可以在Storyboard中使用XCode 5中的代码无法做到的事情吗？
答案 0 :(得分：11)
我要把你的问题分成两部分：NIB和故事板。
就NIB而言，源代码控制问题可能很痛苦但可管理，主要是因为您通常每个视图控制器都有一个NIB文件。你可以想象一种情况，你有两个开发人员在你的NIB驱动应用程序的两个不同部分工作，没有任何合并问题。故事板是不同的，因为您只有一个文件描述了应用程序的大多数（如果不是全部）UI。显然，那里存在更大的冲突问题。
如果使用正确，NIB可以非常有用并节省时间。这是一个例子：iPad上的iPhoto App具有非常复杂的UI。该UI的绝大多数是以编程方式布局的。 然而，该应用程序还使用NIB加载图形元素，然后在代码中布局。这是刷子面板的工作方式 - 所有刷子都是在NIB中创建的。这意味着Apple 不必须拥有数十个相同的图像/图像视图alloc / init代码片段。所有创建都可以在NIB中进行（在iPhoto UI上的WWDC 2012会话中对此进行了详细讨论 - 非常值得追踪）。
所以NIB--有时候很好，可以节省你很多时间，而 合并问题，在很多情况下可以很容易地管理和处理。
然后我们来到故事板。故事板很有趣。一方面，它们对于直接应用程序和平台新手开发人员非常有用且有用。我刚刚将基于UINavigationController的应用程序从NIB转换为故事板，发现节省了大量时间（特别是在桌面视图之外，因为使用故事板可以利用原型单元）。
但是，如果你正在与一些开发人员合作开展一个大型项目，我不相信故事板是有益的。正如你所说，合并冲突存在很大问题，而且与NIB不同，解决它们并不容易，因为单个故事板文件控制着应用UI的所有。
这是我建议的内容（并且可以随意忽略我！） - 如果您正在开发应用程序并在代码中完全进行布局/ UI ，请考虑NIB是否可以节省您的时间。他们可能不会 - 他们不适合所有人 - 但至少值得考虑是值得的。您可能会惊讶于有多少大型应用程序实际使用NIB（iPhoto，正如我所提到的，还有Apple提供的许多内置应用程序，以及大型团队提供的许多流行的第三方应用程序）。我可能不会考虑故事板，除非你是一个独立的开发人员在一个应用程序上进行相当简单的导航。这不是以任何方式做故事 - 我喜欢使用它们 - 只是它们不适合合作。
有人发表此评论以回答您的问题 - 我想讨论它：
您无法在故事板中执行任何操作，也无法在代码中执行任何操作。对象，手势识别器，segues甚至约束 - 都可以以编程方式构建
这技术上是真的，但实际上故事板/ NIB中的东西比代码容易。一个很好的例子是自动布局。虽然您完全可以在代码中管理自动布局约束，但严酷的现实是，ASCII自动布局表示比IB中的视觉表示更难处理。这在XCode 5上是尤其 true，在IB中对自动布局进行了大量改进（我不能详细说明它仍然在NDA下，但Apple公开谈论{{{ 3}}）。
答案 1 :(得分：3)
对我而言，故事板的唯一重大缺点是加载时间缓慢以及导航故事板时通常会出现的延迟。我不是在谈论2-5视图控制器应用程序。我说的是10多个......
如果我真的必须使用它们（UITableView原型单元格）或只是普通的xib，我个人的偏好是较小的故事板。
用简单的代码完成它只是......你有足够的时间在手上吗？ :)通常你不会因为这样做而获得很多。
答案 2 :(得分：2)
你应该在你的决定中考虑这些问题：
开发时间 -
显然，从头开始创建新应用程序时，使用xcode UI设计器要快得多，也易于学习。 在编程方式中，您必须在代码中定义您想要设置的每个元素属性。 使用storyboard将使开发过程更快。
代码重用 -
使用情节提要时，您必须使用项目符号将UI元素绑定到控制器，这些项目符号会在故事板文件中添加其他隐藏代码。在控制器之间创建segue时会添加相同的存根。 这个额外的隐藏代码将使得在您构建的其他应用程序中重用控制器变得更加困难。 如果您计划对控制器代码进行批量重用，那么以编程方式创建UI元素将更为合适。
源代码集成 -
当多个开发人员提交对文件的更改时，冲突解决是很常见的事情。 使用故事板创建和更改UI元素会在故事板文件中添加其他更改，这有时会使冲突解决变得棘手。 另一方面，当以编程方式更改UI元素时，只会将您所做的更改添加到控制器文件中。