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

Question

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

Answer 1

For closed-source static libraries we recommend cocoapods-packager. I'm not sure it's support for frameworks though.

Answer 2

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.

Answer 3

One solution is to turn on use_frameworks! in the framework's Podfile. Then you still could make your framework compiled, and embed your framework in the target app. The warning messages will disappear (It is simply because framework's pods are complied to another framework, but you don't embed this one in your target app. Then your app will refer to the binary of its own.)

But this is not a good solution for two reasons: 1. You need to make sure the target app include the necessary pods that the framework needs. 2. The app might use different pod version to the framework. If both framework and app refer to the same pod binary, it could lead to crash.

I doubt there is a good solution for this issue.