Q:

Class X is implemented in both  and  one of the two will be used, which one is undefined

I'm getting this warning:
Class X is implemented in both <framework> and <application> one of the two will be used, which one is undefined

This warning is covered quite a bit across the web but i haven't found anything that answers the specific problem I'm having.
Scenario
I've built MyFramework and MyApplication (as a test/demo application for MyFramework).
MyFramework uses a CocoaPod (which I'll refer to as CoolPod), which I also want to use in MyApplication (and it is reasonable to assume a consumer of MyFramework would also).
I need to be able to distribute MyFramework as a .framework (for closed source). However, this means that MyFramework embeds CoolPod in its compiled library.
Now when I import MyFramework and CoolPod into MyApplication I get this conflict (outputting the warning shown above) as CoolPod's classes are already included in MyFramework's library (as CoolPod is embedded).
So we have this structure:
CoolPod -> MyFramework \
                        MyApplication
               CoolPod /

Question
How do I avoid this conflict? 

Is there a way to my MyApplication provide CoolPod to MyFramework?
Do I have to pipe CoolPod's headers through MyFramework?

I've thought about including CoolPod's headers (but not its lib) in MyApplication, however this seems overly complex for what should be a simple case.
Any help is greatly appreciated, this is really blocking me right now.
Thanks,
Indigo

A:

My solution was to take the source code from the cocoa pod and create a Cocoa Touch Framework for it. Then I linked the framework to my api and to my test app.
This isn't great but it is all I could do quickly. I believe Cocoapods is working on supporting frameworks so this solution may get outdated soon enough.
My company also uses gradle for dependencies (java) and build scripting. So I created a groovy/gradle build task that builds my framework and my supporting frameworks (cocoapod frameworks) and creates a universal framework from them. Then it zips all of the frameworks. This means I can distribute one zip with all of the requirements. This obviously isn't the nicest way to distribute (we'll be moving to distributing through Cocoapods with dependencies on our closed source frameworks), but it is fast to setup.

