Handle external not-cocoapods-framework in a cocoapods project - iphone

Question

I fell in love with Cocoapods and I want to migrate all my projects with it.
Before doing it, I've a few questions on how to handle external not-cocoapods frameworks in my projects.
1) Let's say that I'm using Cocoapods and I've included only AFNetworking framework.
At some point, I need to use some CoreGraphic animation and I need to use QuartzCore: AFNetworking is not using this framework, so QuartzCore is not included in my Pods project.
What's the best way to handle this situation?
Is better to think "I put all the frameworks in my Pods project, so in my "app project" I've only the code necessary to my app"? And if yes, how? Adding in my Pods.xconfig this code
OTHER_LDFLAGS = -ObjC ... -framework QuartzCore
? Or there are other (better) ways?
Or is better to think "this is not a Pod, so I add the framework on my "app project" as I've always done before"?
2) I've a library (saved in my HD) that is not on the main repository of Cocoapods and there is no Podspec file: what's the best way to include it on my project?
I create a podspec for that library and I link it using :local attribute on my Podfile
I add that library in my "app project" as I've always done
Of course every way works fine, so I'm not asking "How to add an external framework", I'm asking what's the best way to do it :)

Answer 1

Framework
CocoaPods tries, to the possible extent, to separate its files from your work. This is also needed because CocoaPods needs to control some files. For example the Pods.xcconfig is assumed to be under CocoaPods control and it is recreated during each installation. In other words any change that you make to it is lost.
So if you need a framework you should add it to your app project. In principle you should do it even if the framework is included by some Pods because they might be updated removing the dependency and your project would break.
Custom library
Both alternatives work, if you plan to reuse the library creating the podspec might come handy in future. You could also create a custom repo (see the wiki) so you don't need to use the :local option.