CODEWITHSUNDEEP
iosobjective-cframeworkslinker
jackslash
jackslash

Reputation: 8570

Making an iOS framework: including 3rd party libraries and code

Im making a static iOS framework. I want to use 3rd party code, lets use AFNetworking as an example, in my framework. AFNetworking is popular. I can sense the namespace collisions now. What is the best practice here? As far as I understand I have 3 options:

1) Build AFNetworking into my framework, exporting the headers. This lets clients use the version of AFNetworking in my library, but they can't use other frameworks that also link AFNetworking. They rely on me for updates to AFNetworking if they build on it.

2) Code against the AFNetworking Headers, but make the third parties include AFNetworking in their projects. This adds an extra step for framework consumers, they have to add AFNetworking source. There may be version incompatibilities in the future, but at least if another framework uses AFNetworking they can use that at the same time.

3) Re-namespace AFNetworking and keep the headers private. This way I avoid namespace collisions in any way, except that it then becomes really hard to update my copy of AFNetworking. The final binary gets a bit bigger but all interoperability issues are resolved. This is a lot more work for me.

Do I have any other options? What are the best practices?

Upvotes: 13

Views: 3774

Answers (2)

mamcx
mamcx

Reputation: 16186

A better option is use http://cocoapods.org. This way, is possible to declare the dependencies of the libs and the get a single download for the whole project.

Don't rename headers. Is time-consuming, and hard.

P.D: A sample of this:

http://chariotsolutions.com/blog/post/using-cocoapods-to-manage-private-libraries/

Upvotes: 6

MrTristan
MrTristan

Reputation: 740

as far as number 3 goes, it's not a full on "re-namespace" but it's akin to that:

http://atastypixel.com/blog/avoiding-duplicate-symbol-issues-when-using-common-utilities-within-a-static-library/

Upvotes: 0

Related Questions