界面生成器很棒。 情节提要不是。
我真的很喜欢使用Interface Builder。 它帮助我减少了很多本应在视图层中的代码。 但是使用情节提要会带来很多问题。 在这里，我将解释为什么孤立的xib对我来说比故事板更有效。
注意：这是我的看法。 这对我来说非常有效，但是您可以在此主题上有不同的意见，这很好。 我很高兴阅读。 以友好的方式讨论此问题是成为开发人员的最佳方式。
情节提要实际上是什么？
故事板可以看作是应用程序流程的直观表示。 真的很棒 如果您来到一个使用情节提要开发的新项目，并且已经组织了团队，那么您将拥有整个应用程序流程的完整全景图，以及每个屏幕的可视层次结构。 您将在短时间内了解该项目。
尽管很明显，情节提要板可以带来很多优势，但它们是有代价的：git合并冲突，可变变量，耦合视图控制器。
Git合并冲突
假设您正在登录屏幕上。 您团队中的另一位开发人员正在注册屏幕上的远程位置工作。 归根结底，你们两个都尝试将代码推送到远程git存储库和BOOM！ 一切都被打破。 Git到处都有冲突。
根据项目的大小以及在多个情节提要中如何分解项目（情节提要参考more），您将或多或少会遇到git merge冲突，但这肯定是一个使您头痛的问题。
可变变量
使用情节提要板时，无法创建自定义init，因此在尝试将数据从一个屏幕传递到另一个屏幕时会遇到严重的问题。
使用情节提要时传递数据通常是通过重写ViewControllerA中的prepareForSegue来设置ViewControllerB中声明的隐式展开变量的值来实现的。 这种方法的问题在于，如果不设置该变量，没有什么可以阻止您执行segue。
在执行情节提要的应用程序中，很常见的导致崩溃的原因是，未设置应该在执行segue之前设置的隐式展开的可选变量的值。
耦合视图控制器
使用情节提要时，可以在视图控制器之间定义序列。 如果ViewControllerA与ViewControllerB有联系，则它们将耦合在一起。 ViewControllerA知道将在其后显示ViewControllerB，而在segue继续存在的情况下，这就是事实。
视图控制器不应该如此耦合。 视图控制器不应该知道导航流程中的下一个视图控制器，因此可以随时替换它。 解决此问题的一种流行解决方案是使用导航协调器，并将导航流执行委派给充当介体并执行所需转换的新对象。
使用Xibs
使用自己的xib创建视图控制器就像创建新类一样简单
然后创建一个新的UIViewController子类，选择“也创建XIB文件”。
可以使用以下代码来实现结果视图控制器：
请注意，您可以创建自定义初始化程序，以使您不会忘记将数据从视图控制器传递到另一个控制器。
修改AppDelegate
需要修改AppDelegate以允许在不使用情节提要的情况下启动应用程序。 需要这样的代码：
首先，我们实例化UIWindow。 然后，我们使用自定义初始化程序实例化根视图控制器。 最终，该视图控制器被设计为窗口的根视图控制器，并且使窗口成为键并可见以启动流程。
孤立的Xib有何不同
使用隔离的Xib（每个View Controller一个Xib）比情节提要更好，原因有以下几个：
- 它们有助于避免git合并冲突。 如果您与其他开发人员在同一视图控制器中工作，则将继续存在合并冲突，但这远不及在同一情节提要中进行。
- 它们使我们拥有不可变的变量。 实例化视图控制器时，将创建其所有依赖项集，因此您不会在传递数据时犯傻错误。
- 可以使用导航协调器来解除视图控制器的耦合。 视图控制器可以与应用程序的其余部分隔离，从而使其完全可替换。
何时使用故事板
Xib和情节提要只是我们的工具和资源，开发人员可以在方便时使用它们。 Xib并不是解决所有问题的方法。 在某些情况下，使用故事板可能是最佳选择。 让我们探索一些：
- 该应用程序是由单个开发人员开发的：在这种情况下，合并冲突不是问题。
- 该应用程序具有明确定义的流，其中固定了视图控制器：在这种情况下，情节提要将显示流而没有重大问题。
- 小型应用程序：在小型应用程序中，使用Xibs可能会过大。
结论
在这里，我讨论了使用xibs和情节提要构建iOS应用程序用户界面之间的一些区别。 通常，我更喜欢使用xibs而不是情节提要。 它们比情节提要更易于维护。 但是在某些情况下，情节提要更好，特别是在应用程序较小且开发人员是唯一使用该应用程序的开发人员时。