iOS Framework build: what is the best practice to link with third-party libraries?

Question

I'm build a Framework for iOS and my framework has AFNetworking as dependency. So what is the best practice to include AFNetworing? Reading other posts (specially this question here ) i came up with three options:

1. Copy all the .hm files from AFNetworing in to my project and compile my framework with it. But according to this , it will possible cause a situation where some third part developer using my Framework are already using AFNetworking and will get a compile-time error that some class is declared twice.

2. Use CocoaPods and link AFNetworking to my Framework. This is causing this error: -lPods is not an object file (not allowed in a library) .

3. Build something like the Aeris SDK where the third part developer using my Framework will be responsibly to add AFNetworking to their project.

I think that option 3 is the best but i don't know how to do that. How can i dev my framework calling AFNetworking classes/methods but do not include on the final framework product?

Thanks!

Answer 1

That's a very bad practice to use third party library in you library.
Ideally you should avoid doing that.

But if you really need it, you can define and add prefixes to class names.
Refer this article Avoiding dependency collisions in iOS static library managed by CocoaPods

Answer 2

Ok. I decided to go with the option 3.

A just added all the header files from any third-party lib to the my framework project (you can also add the .m files but not include them on the static library target).

And ai also documented everything, so developers using my framework will know what are the dependencies and how to include/install them on their own projects (including third-party lib versions, CocoaPods support, etc).

I decided not to go with option 1 because that will cause some situations where a project will have two copies of the same lib compiled on the final app. Even if a change the namespace for the libs on my framework code (to prevent "duplicated symbols" errors) that will still cause some other possible problems like an APP with larger size, possible bugs related to two or more instances of the same lib running together, etc...