我想发布框架A.框架A依赖于框架B.我希望我的框架的用户只需要包含框架A，但仍然可以通过编程访问框架B.
苹果一直在使用"伞形框架"的概念来实现这一点，但文档中有这样一个主题:
Don't Create Umbrella Frameworks
虽然可以使用Xcode创建伞形框架，但是
为什么不鼓励这种做法？是什么让它成为解决苹果相互依赖框架问题的好办法，而不是我的？
我想发布框架A.框架A依赖于框架B.我希望我的框架的用户只需要包含框架A，但仍然可以通过编程访问框架B.
苹果一直在使用"伞形框架"的概念来实现这一点，但文档中有这样一个主题:
Don't Create Umbrella Frameworks
虽然可以使用Xcode创建伞形框架，但是
为什么不鼓励这种做法？是什么让它成为解决苹果相互依赖框架问题的好办法，而不是我的？
只有当您是所有相关框架的唯一分发者，并且将所有框架打包为一个单一版本的包，并一起升级时，伞形框架才有意义.如果这是你的情况，那没关系，但这是一个非常不寻常的情况.在可可发展领域，除了苹果之外，任何人都极为罕见.
首先，伞式框架只有在您是给定框架的唯一分发者时才有意义.例如，假设您希望将libcurl作为伞式框架的一部分.现在，其他一些包装商也希望将libcurl作为其伞形框架的一部分.现在我们有一个链接时间冲突，它可能会导致链接错误或更糟糕的、未定义的运行时行为.我自己也找过.他们非常讨厌.避免这种情况的唯一方法是每个框架/库只有一个版本.伞式框架鼓励相反的结果.
即使您只是将自己的代码分解成子部分，这也意味着其他供应商可能会在自己的伞式框架中使用您的子框架，从而导致同样的问题.记住，如果你说你作为第三方可以使用雨伞框架，那么其他供应商也可以.
第二点，伞形框架只有在控制所有子框架的版本控制时才有意义.在我的经验中，试图修补一组相互依赖的框架中的一部分几乎总是一场灾难.
由于其系统的规模和普遍性，操作系统供应商的情况不同寻常.在一个尺度上有意义的事情在另一个尺度上往往没有意义.NSResponder对此完全正确.当您提供一个完整的、数千个包的环境，这是为平台编写的每个程序的基础时，取舍是不同的.但即使是苹果公司也只有少数几个大型伞形框架，它们总是围绕着它们提供和控制版本的库进行包装.这主要是为了简化开发人员的工作，否则他们将不得不寻找几十个库和框架来编译一些东西.没有第三方会出现这种情况，因此第三方需要这种解决方案的情况非常罕见.要求客户链接两个库与要求他们链接20个库完全不同.如果你提供了20个框架，它们都可以一起工作，并且由你控制，那么也许你应该使用一把伞，但也可能你有太多的框架供第三方使用.
我在这里的大部分讨论都是关于OS X的.在iOS上，这对第三方来说不是问题.由于肯定会发生冲突，静态库绝不能链接其他静态库.
理论上，我在这里讨论的大多数问题都是链接器的技术局限性.链接器没有管理多个版本库的好方法，因此冲突是一个严重的问题.NET程序集试图提供更大的灵活性.我对你不够熟悉.NET开发来说明这是否成功.我在大型多组件系统方面的经验是，对于大多数问题，更简单、更不灵活的解决方案是最好的.(但是，草总是更绿的……)