我想要分发框架A，框架A依赖于框架B。我希望我的框架用户只需要包含框架A，但仍然可以编程访问框架B。
Apple一直使用“Umbrella Frameworks”的概念来实现这一目的，但文档中有这个主题：
不要创建Umbrella Frameworks
虽然使用Xcode可以创建Umbrella Frameworks，但对于大多数开发人员来说，这样做是不必要的，也不推荐这样做。苹果使用Umbrella Frameworks来掩盖操作系统库之间的某些相互依赖性。在几乎所有情况下，您应该能够将代码包含在单个标准框架束中。或者，如果您的代码足够模块化，您可以创建多个框架，但在这种情况下，模块之间的依赖关系将是最小的或不存在的，不应该为它们创建Umbrella Frameworks。
为什么不鼓励使用这种方法？什么使它成为苹果解决互相依赖的框架问题的好方法，但不适用于我的问题？
如果您是所有相关框架的唯一分发者，并且将所有框架打包成一个单独的版本化包并一起升级，则“伞形框架”才有意义。如果您处于这种情况，那么没问题，但这是一种非常不寻常的情况。在Cocoa开发世界中，除了苹果公司以外，很少有人会处于这种情况。
首先，“伞形框架”只有在您是给定框架的唯一分发者时才有意义。例如，假设您想将libcurl作为伞形框架的一部分包含在内。现在还有其他一些打包程序想将libcurl作为他的伞形框架的一部分包含在内。现在我们有了链接时冲突，这可能会导致链接错误或更糟糕的未定义运行时行为。我自己曾经追踪过这些问题，它们非常令人不愉快。避免这种情况的唯一方法是每个框架/库只有一个版本。伞形框架则鼓励相反的做法。
即使您只是将自己的代码分解为子部分，这意味着其他供应商可能会在其自己的伞形框架中使用您的子框架，从而导致相同的问题。请记住，如果您说作为第三方使用“伞形框架”是可以的，那么其他供应商也可以这样做。
其次，“伞形框架”只有在您控制所有子框架的版本控制时才有意义。在我的经验中，尝试修补互相依赖的框架集合中的一个部分几乎总是会导致灾难。
由于操作系统供应商的系统规模和普及程度，他们面临了一种不同寻常的情况。在某个规模下合理的事情，在另一个规模下可能就不合理了。NSResponder对此完全正确。当您提供一个完整的、数千个软件包的环境作为该平台上编写的每个程序的基础时，权衡是不同的。但即使是苹果也只有少数几个大型的组合框架，并且它们总是围绕着他们提供并控制版本的库的封装器。这主要是为了简化开发人员的工作，否则他们将不得不追踪数十个库和框架以获取编译所需的东西。没有第三方拥有这种情况，因此第三方需要此解决方案的情况非常罕见。要求客户链接两个库与要求他们链接20个库完全不同。如果您提供20个可以共同使用并由您控制的框架，那么也许应该使用一个组合框架，但也许您的框架太多了，这对于第三方来说是不必要的。
我在这里的大部分讨论都是针对OS X的。在iOS上，这对第三方来说不是问题。由于可能发生冲突，静态库绝不能链接其他静态库。
从理论上讲，我在这里讨论的大多数问题都是链接器的基本技术限制。链接器没有很好地管理多个库版本的方法，因此冲突是一个严重的问题。.NET装配件尝试提供更多灵活性。我对.NET开发不太熟悉，无法确定它是否成功。我的经验是，在大型多组件系统中，对于大多数问题，较简单、较不灵活的解决方案最好。（但是，人们总是向往未知的东西...）
