在iOS编程中，使用最新的iOS 7和Xcode 5。
是否只有普通代码（以编程方式创建所有这类UI元素）才能实现，而其他两个（界面构建器，故事板）都不能实现？
是否只有界面构建器可以实现的内容，而其他两个都不能实现？如自动布局设置。
是否只有故事板可以实现，而其他两个都不能实现？
故事板是否相当于将所有xib文件放在一起？
是否可以通过在项目A中进行一些更改，将使用界面构建器或故事板（将其命名为项目B）的普通代码（将项目A命名）项目转移到项目中？因为据我所知，唯一的方法是创建一个新项目C并使用界面构建器将项目A中的所有内容复制到项目C中。从普通代码到界面构建器或故事板的这种转换需要部分归因于上面的问题1,2和3.
是否可以通过删除.xib或.storyboard文件，使用界面构建器或故事板（将其命名为项目D）转移到仅使用普通代码进行项目（将其命名为项目E），并删除所有这些IBAction还是IBOutlet标签？尽管如此，我现在所能做的仍然是创建新项目并使用不同的方法再做一次。
答案 0 :(得分：2)
1：
界面构建器对自定义UIView上的自定义属性的支持有限，不会在Apple的视图中公开完整的属性，也不允许使用除操作系统内置的任何字体之外的任何字体 - 如果您想使用自己的字体，则需要包含它们，然后以编程方式设置它们。我看到的一个解决方法是将你不使用的OS字体别名用于你所包含的字体和方法swizzle UIFont来替换另一个字体，但显然这种事情开始显着地削弱了视觉工具。
同样，虽然可以在界面构建器中使用KVC设置一些属性，但它不允许您对CALayer执行任何操作。约束不足以满足所有布局可能性 - 例如假设您在顶部有一个框，其大小由其内容决定，其内容是从服务器返回的字符串。
2
我没有意识到这一点。在过去，这是为UINavigationBar设置自定义UINavigationController类的唯一方法，因为Apple忽略了为此提供公共API，但已经解决了这个问题。我想可能还有其他类似的例子，我不知道但是，如果是这样的话，它们会因疏忽而变成边缘使用。
3
一旦1000个控制器变大，它就可以使你的项目易于消化。故事板允许设置视图控制器如何相互交互，它们传递什么数据，如何传递它的大局。故事板还允许指定视图控制器包含。
故事板还可以指定表视图的内容，NIB不能这样做，如果您在代码中执行操作，则会以不同且更混乱的方式完成。参见例如this tutorial。同样，它可以创建静态集合视图。
4
故事板链接各种控制器，并在此过程中指定链接转换。如果您使用NIB，则需要以编程方式提供。它还为您提供了应用程序流的良好视觉概念。
5
您可以一次转换一个视图控制器;该过程将选择一个控制器来适应，创建笔尖，连接，从源中删除您的视图创建代码，然后可能添加在超类上调用init的自定义版本initWithNibName:...
没有自动化工具。
6
如果你要删除NIB或故事板，你将删除所有视图应该如何布局的记录 - 实际上它们应该被创建。然后，您需要以编程方式编写所有内容。
答案 1 :(得分：2)
这个问题似乎假定故事板，XIB / NIB和以编程方式创建的视图之间的区别仅在于每个视图的功能。显然，最小化代码量必须写入的优势在于更快地依赖于开发速度，易于维护以及减少缺陷机会的能力。例如，故事板的目的不是能够做你在NIB或编程创建的视图中无法做的事情，而是在很大程度上使你更容易开发和维护这样的应用程序。
尽管如此：
您可以在代码中执行许多操作，而单独使用IB无法完成这些操作，例如：具有乘数，自定义外观，自定义转换，高级自定义容器等的自动布局约束。另一种表达方式是，即使在IB中设计UI时，某些用户界面也需要您深入研究代码。
我所知道的，你无法在IB中做到你无法在代码中实现（但通常需要更多努力才能实现），例如：细胞原型等
有些事情比NIB或编程生成的代码（例如单元原型，展开segue等）更容易做到，但我不相信你可以在故事板中做任何事情。在代码中实现（付出更多努力）。
故事板不仅仅是一系列NIB之间的直观表示（尽管这本身就是一个优势）。故事板提供的功能是，如果不使用其他代码，NIB就无法再现这些功能。因此，故事板不仅可以直观地捕获应用程序的流程，而且还可以最大限度地减少必须编写的代码量，因此，故事板是设计工具，开发方法和生产力工具的有趣组合。
通常，是的，您可以将应用转换为使用故事板的应用，但通常需要对代码进行大量重构。
是的，您当然可以将故事板应用转换为仅代码再现，但您必须添加大量代码，通常是比故事板难以维护的代码，但您可以做到这一点。