I'm using an embedded framework for my custom views in a new project to take advantage of the new @IBDesignable stuff in Xcode 6 and I'd like to animate said views with Facebook's Pop. I've added Pop to the project using Cocoapods but the embedded framework doesn't have access to those files ('POP/pop.h' file not found
).
I tried copying the Cocoapods-related build phases from the app target to the custom framework target but they don't work as-is. What does work is copying the Pop folder into the embedded framework directly, but then Xcode tells me that I've gotta change all of the angle brackets <POP/pop.h>
to quotes "POP/pop.h"
. I'm assuming there's a better way and I'm blanking on it.
Assuming in your Podfile you are using the link_with 'MyCustomFramework'
, where 'MyCustomFramework' is your embedded framework name, and have run pod install
. Select your Project file (Blue on the top right) and go into "Build Settings". Then, find 'Allow non-modular includes in Framework Modules' and set it to YES, for both the Project file (blue) and the Custom Framework target (ex. MyCustomFramework - orange "lunchbox case" icon).
Then you can include cocoa pods stuff in your main MyCustomFramework.h file.
Then just import '@import MyCustomFramework;' in your Application target, and you'll get the rest of the CocoaPods at your disposal. (Ex. showing you access to 'each' from ObjectiveSugar).
Whether you should do this or not is a separate issue, but this allows your Custom Framework to include the CocoaPods libraries in itself, which then allows the Application target to just include your Custom Framework and gets all the CocoaPods as well.
Sorry for the multiple images, but I like to be visual.
I guess you are modifying the framework to use Pop. In this case you'll also need to add the Pop headers' path to the framework Build Settings' search header paths.
But then if you're modifying the framework you could just create a podspec for it as well and let CocoaPods handle everything (and send a pull request to the creator?).
As for the bounty question.
A framework should never embed other libraries. If for instance you want to use AFNetworking in your library:
- State that AFNetworking is required in your own framework installation instructions.
- If you distribute binaries you just build locally against AFNetworking headers. Users will need to provide their own AFNetworking when linking their App.
- If you distribute source code with your framework (if users have to build it themselves) then ask in your installation steps to set the AFNetworking headers path in your frameworks Build Settings Header Search Paths and preset it to common paths such as
POD_ROOT
, etc.
Then it works but you have complex installation instructions, users have to manually add resources if any, it is hard to control the AFNetworking version being added by users and most will never upgrade your framework because it may break their setup. All good reasons to support CocoaPods by creating a podspec (you can keep maintaining the framework/static library project if you really want).