The temptation to distribute another framework is understandable, but highly discouraged. I'll try to explain why that is (with arguments), and also provide some great alternatives that will help in your case.
Umbrella framework are intended for use, only when you are the distributor of both frameworks, you have full control over them, and they will be distributed together.
There is a popular quote on the topic from Apple, where they say that they discourage umbrella frameworks.
Don't Create Umbrella Frameworks
While it is possible to create umbrella frameworks using Xcode, doing
so is unnecessary for most developers and is not recommended. Apple
uses umbrella frameworks to mask some of the interdependencies between
libraries in the operating system. In nearly all cases, you should be
able to include your code in a single, standard framework bundle.
Alternatively, if your code was sufficiently modular, you could create
multiple frameworks, but in that case, the dependencies between
modules would be minimal or nonexistent and should not warrant the
creation of an umbrella for them.
First, here is what most developers do in this situation, since there are many frameworks out there that rely on others.
Inform the user that your framework requires the use of another third party framework. This is completely standard and expected in most cases. Then link to it at the system level. It's as simple as that. Your framework will find the third party and function seemlesly, just like using a native framework. Take UIKit for example. To link to the third party, follow the steps in the next section. It can certainly be done the standard way, but using a tool like CocoaPods will make your project easier to maintain.
To completely answer your question, instead of adding the third party framework the usual way, since you could run into problems and complications, use CocoaPods to add it for you. This way, you eliminate possible issues and also get the added benefit of CocoaPods getting you the exact version of the third party you will need.
Here is the CocoaPods Podfile for an app called "CrashTest"
target 'CrashTest' do
pod 'PLCrashReporter', '~> 1.2.0'
end
Just to clarify, when you are developing the framework, it will still be added to your project and visible. The big difference here is that it will be distributed separately from your framework, and end users will have to add both to their projects in order to make things work.
Here are the reasons why this is done this way.
For example, you would like to include PLCrashReporter in your framework. Say another framework vendor wants to include it in theirs as well. The application using both frameworks will have PLCrashReporter included twice (as part of each umbrella framework). Possible even different versions of it. This could lead to serious issues inside of the user application. If both umbrella frameworks are linking to PLCrashReporter, as described in the previous section, this issue would be avoided completely.
Another point, which I touched on above is versioning. When distributing an umbrella framework, you need to be able to control the versions of all frameworks involved, and you have no control over the third party framework. Which would again lead to a similar problem as the one described above.
I know that this approach does not provide a direct answer to the question, but it's trying to discourage a bad practice instead, while pointing the industry standard way of doing things.
