Prevent duplicate symbols when building static library with Cocoapods

Question

While I've seen many questions dealing with Cocoapods and static libraries, most of them seem to assume you'll eventually have a single workspace with your static library and end target app.

In my scenario, I am building a static library. More specifically, I'm hacking a MyLib.framework for users to consume. I'd really like to manage MyLib.framework's dependencies with Cocoapods, but it creates many pain points when consumers of my library also use Cocoapods.

For example, my library has an AFNetworking dependency which I manage with Cocoapods. When I build my library, it links in libPods.a which includes AFNetworking, as well as some "dummy" files/objects. If users of my framework also use Cocoapods to build their app, they'll see something like this:

duplicate symbol _OBJC_METACLASS_$_PodsDummy_Pods in:
    /Users/erikkerber/Dropbox/Projects/MillMain/MyLib.framework/BuddySDK(Pods-dummy.o)
    /Users/erikkerber/Library/Developer/Xcode/DerivedData/MillMain-fngfqhlslygksgcfuciznkpqfrbr/Build/Products/Debug-iphonesimulator/libPods.a(Pods-dummy.o)
duplicate symbol _OBJC_CLASS_$_PodsDummy_Pods in:
    /Users/erikkerber/Dropbox/Projects/MillMain/MyLib.framework/BuddySDK(Pods-dummy.o)
    /Users/erikkerber/Library/Developer/Xcode/DerivedData/MillMain-fngfqhlslygksgcfuciznkpqfrbr/Build/Products/Debug-iphonesimulator/libPods.a(Pods-dummy.o)
ld: 2 duplicate symbols for architecture i386

I imagine if they were to add an AFNetworking dependency, that they would also get duplicate symbols relating to AFNetworking.

I plan to eventually distribute MyLib with Cocoapods as well, but I also want to be able to distribute a MyLib.framework itself.

Is there any way to use Cocoapods with my library while making Cocoapods safe to any potential user?

Answer 1

In short, the only good way of distributing prebuilt libraries is by not including any of the dependencies, but leaving that up to the user. I.e. in your example, you would instruct your users how to also add AFNetworking to their project. The same basically applies regarding the dummy files.

Having said that, you could of course go for multiple prebuilt variants:

• Include all dependencies.
• Only include your lib’s source, leave dependencies up to the user.

We have been talking about creating a plugin to produce standalone static libraries, for the purpose that you want, but that’s as of yet not started and will probably take a little while longer. (Until someone/anyone has the time.)

As a workaround, you could use your Podfile’s post_install hook to remove the dummy files altogether. (these are only needed for non-source libs like Testflight anyways.) E.g. something like the following:

post_install do |installer|
  installer.project.targets.each do |target|
    source_files = target.source_build_phase.files
    dummy = source_files.find do |file|
      # TODO Fix this to the actual filename
      # puts "File: #{file.file_ref.name}"
      file.file_ref.name == 'TheDummyFile.m'
    end
    puts "Deleting source file #{dummy.inspect} from target #{target.inspect}."
    source_files.delete(dummy)
  end
end

This is untested code.

The post_install hook yields the CocoaPods installer object, from which you can get the Pods.xcodeproj targets, for which you can find documentation here. From there you can drill down and do anything you like to the project, which is saved to disk after running this hook.