2

Imagine the following scenario;

I'm developing a cocoa touch framework that requires SomeLibrary (e.g. AFNetworking). My framework is going to be included into someone's project that might require SomeLibrary as well. How do I accomplish this without running into these nasty duplicate warnings when I include AFNetworking into my framework directly (either via source code or Cocoapods)?

I've tried it with Cocoapods on both projects (my framework, and a test project that includes my framework), but that results in duplicate code warnings as well.

When I don't add AFNetworking into my framework development project, the compiler can't find the required files, which is why I can't build it. I've tried with including AFNetworking's source code directly into the main project, and using the pod, but in both cases the AFNetworking/AFNetworking.h import in the framework project fails.

How can I do this without making a pod out my framework (which isn't really an option)?

I've found this related answer, but I don't know what search path to set for the framework project in order to find a library of the master project; https://stackoverflow.com/a/23123725/1069487

Any help would be highly appreciated!

Community
  • 1
  • 1
AlBirdie
  • 2,071
  • 1
  • 25
  • 45

1 Answers1

0

You will have to build your framework linked against static library.

  1. You build AFNetworking as a static library (that will give you a .a file as AFNetworking.a)
  2. You build your framework that link against your static library. But be aware that the library won't be embedded in your framework (there is no way to include static library into framework on iOS). Your framework is able to use AFNetworking API because it is linked against it.
  3. any project that use your framework and use AFNetworking methods of your framework need to link with the static library AFNetworking.a that you should provide as a standalone file beside your framework.

See iOS-Framework here for more details : https://github.com/jverkoey/iOS-Framework

Nicolas Buquet
  • 3,880
  • 28
  • 28
  • 1
    Though that seems to be a solution, I don't thing it is a viable one. I as the framework vendor really have no intention providing a AFNetworking library to my customers as that could have severe implications with their current development process. Imagine they use CocoaPods for their project, including a pod for AFNetworking. Using the method you've described would essentially break that dependency for them and would force me into updating the AFNetworking static library whenever something changes to that library that might be of interest for my customer. – AlBirdie May 11 '15 at 07:53
  • So, you should include he source code of AFNetworking to your project, and refactor AFNetworking classes and global functions/variables (like adding your initials: AIAFNetworking) so that they don't collide with another import AFNetworking in a final user's project. Methods names can be kept because they are attached to class whose names will be changed. – Nicolas Buquet May 11 '15 at 08:08
  • 1
    Thought about that as well, but that's a rather ugly solution to be honest. I honestly can't imagine that this issue can't be solved nicely (somehow pointing my framework to look at the main project for dependencies) as it is probably a rather common one. – AlBirdie May 11 '15 at 08:11
  • 1
    Perhaps @compatibility_alias from objective-C can help you. See this SO topic: http://stackoverflow.com/questions/178434/what-is-the-best-way-to-solve-an-objective-c-namespace-collision – Nicolas Buquet May 11 '15 at 12:12
  • That makes re-naming AFNetworking's source code certainly a lot more friendly for future updates. Didn't know about that one. Still wondering if this really is the last resort to solve these dependency issues. – AlBirdie May 11 '15 at 12:26