使用iOS 8, Xcode 6。
我们说我有2个动态框架frameworkA和frameworkB，它们都依赖于libC。另外，我有一个同时使用frameworkA和frameworkB的应用。我最初的想法是让frameworkA和frameworkB伞形框架和libC做一个子框架。但是，Apple建议不要使用伞形框架，而post描述了为什么伞形框架由于潜在的链接器冲突问题而成为一个坏主意。
我的第二个选择是使用cocoapods（对此仍然是新的，因此在细节上有点模糊）使用libC作为一个pod然后被编译成frameworkA和frameworkB。但是，我发现两个框架仍然有自己的libC副本。由于应用程序使用两个框架，这是否会导致链接器冲突问题？有没有更好的方法来解决这个问题？
更新 @Rob我工作的项目确实需要复杂的依赖关系管理，但我在问题中保持问题域的简单性，试图更好地理解如何使用cocoapods来帮助解决伞框架的链接器冲突问题。我与一组编写库的开发人员合作，可以依赖彼此提供版本化通用API的基本库。我们需要将尽可能少的库打包并交付给使用我们的库构建应用程序的不同组织，其中一个关键要求是我们提供动态框架。
答案 0 :(得分：16)
解决大多数问题的最佳方法是将所有代码放在项目中并进行编译。当你遇到有问题的专门问题时，你应该看看其他解决方案，比如静态库，最后是框架。
如果您的代码库具有需要不同构建要求的部分，则静态库可能有意义。如果所有部分都具有相同的构建设置，那么只需添加文件＆＃34;他们从一个＆＃34;普通＆＃34;进入你的项目目录并构建您的项目。如果您的构建时间非常长并且某些部分永远不会改变并且您希望能够清理＆＃34;静态库可能很有吸引力。没有重建那些部分。但是在你开始复杂的多包项目之前，请等到你开始遇到这个问题。
如果您销售闭源库，那么框架非常有吸引力。出于您注意的原因，您应该强烈避免添加第三方依赖项。如果必须，最好的方法是帮助您的客户将所有部分打包为框架，并让它们在最后链接所有部分。但这增加了很多烦恼;所以请确保真的需要第三方作品。
如果您拥有一大块可重复使用的代码，并且它们自己的生命周期与主要产品分开，那么您也可以考虑使用框架。但同样，保持简单。避免使用第三方内容，如果你必须拥有第三方内容，请让消费者在最后将其链接起来。
（这不是新的解决方案，BTW。当你使用curl时，如果你想要SSL，你还需要下载并构建OpenSSL并将它们自己链接在一起.Curl并没有内置的OpenSSL 。）
但在绝大多数情况下，这都是矫枉过正。不要跳到框架。不要跳到图书馆。只需将所有代码放入项目中并进行编译即可。 90％的问题都会消失。特别是iOS项目通常不是那么大。解决框架有什么问题？
如果您的组织在很多产品中反复使用了很多代码，那么我听说很多团队都有好运使用内部CocoaPod来管理它。但这只是为了简化检查代码。它仍然进入一个项目，你将它们一起编译成一个二进制文件;没有框架需要。对于某些以前非常痛苦的问题，动态框架是一个很好的特性。但是，对于大多数情况，他们只是寻找问题的复杂性。
（如果你有其中一个专门的问题，请编辑你的问题，我很乐意进一步讨论如何处理它。）
编辑:(你属于那个＆＃34;专门的问题，＆＃34;所以让我们来谈谈它。我也曾在一个大型的多团队Mac和iOS开发中做了很多年环境。我们尝试了几乎所有不同的解决方案，包括框架。它们只是iOS上的新功能。）
在您描述的组织中，我强烈建议将每个依赖项打包为自己的框架（AFNetworking，JSONKit等）以及每个部分作为框架，然后让应用程序开发人员将所有这些依赖项链接在一起。结束。通过这种方式，它与其他动态库（libcurl，openssl等）相同，后者需要app dev将所有内容链接在一起。
在任何情况下，动态框架都不应包含其他可能需要的框架（即框架永远不应打包＃34;第三方＆＃34;东西）。那会爆炸。你不能让它不爆炸。您将遇到膨胀，构建冲突或运行时冲突。它就像合并冲突一样。开发者必须做出选择。应用级链接正在做出这种选择。
使组件过度依赖其他组件是数十年的麻烦的源头，从Windows DLL Hell到具有竞争崩溃处理程序的iOS应用程序。所有最好的组件系统看起来都像Legos，最终用户组装具有最小依赖性的小块。尽可能让你的内部框架只依靠Cocoa。这有一些有形的设计影响：
AFNetworking只是为了在NSURLConnection上保存几行代码。当然，如果你非常依赖另一个框架的功能，那就不同了。但作为框架开发人员，在需要另一个框架之前，您的门槛应该非常高。+load魔法不要聪明。只要说清楚并保持一致。当然，祝你好运。支持其他开发者总是一个有趣的挑战。