Instructions for building a Framework w/ Cocoapods

[GSatko]

So I am having some issues using this documentation with Cocoapods on top of it. Some advice would be great.

I went ahead and made a Framework listed in this guide and then I integrated the various Cocoapods I wanted in my podfile and installed the pods.

Everything was fantastic and I went on with my life, coding with reckless abandon.

Now that I want to build my framework I am running into various issues.

I made use of what paulyoung listed in #46 to build the workspace as opposed to the project and not run into build problems.

However, now I have a problem in that the framework product has inserted the lPods.a, which contains all of the open source external frameworks I am using. So when I run my dependent project (also a Cocoapod project) I now have duplicate symbols for, say, AFNetworking.

What I would like is to have the project build (of course) but not include the dependent frameworks in the framework product.

I definitely want to use AFNetworking in my framework, but I also definitely don't want to have it included in the framework and instead have users add AFNetworking themselves to use my framework.

The framework I am making itself is private, so there isn't any way for me to put it onto Pods repo as an open source framework dependent upon other frameworks.

[mrtristan]

@GSatko there are a couple solutions, the one you go with is entirely up to the project at hand and decisions that only you can make... i just did a bunch of research on this myself. (also for AFNetworking).

As far as our needs are concerned, i'm not yet shipping this framework so I made the decsision to expose AFNetworking headers as public instead of project or private and remove AFNetworking from the framework-dependent project and to import the framework version on that end.

the only other real solution that doesn't force the 'client' app to have cocoapods(not an option for me, despite cocoapods' awesomeness) is to automate a 're-namespace' of AFNetworking as discussed here: http://atastypixel.com/blog/avoiding-duplicate-symbol-issues-when-using-common-utilities-within-a-static-library/

the next solution, that involves the client project requiring cocoapods, is where you skip the linking of AFNetworking during the framework creation process (but keep it there during compiling and such so nothing breaks) and you actually use it as usual in the client-side. i'll edit this answer if i can find the link where i read about the specifics of doing this.

[kodeshpa]

@mrtristan I liked approach of namespaces AFNetworking more than asking client to add it as dependency, I had similar problem in the past specially with different versions of AFNetworking.

[GSatko]

@mrtristan The last solution, will it really require Cocoapods? I figure as long as the headers are available that it shouldn't quite matter, so I want to see if I can manage this approach if possible.

Luckily I'm not in any rush and am definitely considering the automating with a re-namespace if push comes to shove. I appreciate the link, I'll look through that. Since AFNetworking has a few categories I am hoping that this will work or I will have to resort in the end to your own solution and boxing all the frameworks within my own, not entirely the end of the world