47

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

Jef
  • 4,728
  • 2
  • 25
  • 33
Zenton
  • 977
  • 1
  • 9
  • 20
  • 2
    I have a similar issue, did you find a solution? – cocoapriest Jan 08 '15 at 19:51
  • 1
    Similar issue, but with unit tests, is discussed here: http://stackoverflow.com/questions/6149673/class-foo-is-implemented-in-both-myapp-and-myapptestcase-one-of-the-two-will-be – ThomasW Nov 16 '15 at 04:38
  • 1
    Surprising — isn't this a really common pattern? Don't developers want to be able to create DAGs of compilation units without worrying that there are gonna be collisions?! – fatuhoku Nov 21 '15 at 04:08
  • Hi @Zenton. Besides the accepted answer, did you manage to solve this issue with a different solution? I'm facing the same issue, I would appreciate your advice. – Fernando Reynoso Aug 23 '18 at 22:14

5 Answers5

3

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.

Zenton
  • 977
  • 1
  • 9
  • 20
2

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

orta
  • 4,225
  • 1
  • 26
  • 34
1

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.

syshen
  • 397
  • 3
  • 13
1

If you want a quick solution - just add your MyFramework project as a subproject to MyApplication project. You can still use cocoa pods both for your framework and test application (but include your "common" lib with pods only to framework project)

Robert Fogash
  • 136
  • 3
  • I wasn't able to make this approach work - the app target won't link, with "Symbol(s) not found for architecture arm64" for any classes defined in the pods included only in the framework. Any ideas? – stephent Sep 08 '15 at 17:52
  • This worked for me. I just had to delete my derived data to get it to work – Alpine Jan 06 '17 at 01:06
0

You can create a Podspec for your MyFramework with CoolPod as a dependency.

Your MyFramework.podspec will look something like:

Pod::Spec.new do |spec|
  spec.name          = 'TestFW'
  spec.version       = '1.0.0'
  spec.license       = { :type => 'BSD' }
  spec.homepage      = 'https://github.com/user/TestFW'
  spec.authors       = { 'Auther Name' => 'author@gmail.com' }
  spec.summary       = 'Testing FW Pod with Test App'
  spec.source        = { :git => 'https://github.com/user/TestFW.git' }
  spec.module_name   = 'TestFW'
  spec.ios.source_files   = 'TestFW/*.swift'

  spec.dependency 'CoolPod'
end

And your MyApplication's podfile will look something like this:

target 'TestApp' do
  use_frameworks!

  pod 'CoolPod'
  pod 'TestFW'
end
Shahrukh Alam
  • 184
  • 3