Cocoa best practice for architecting a custom framework which requires an Apple framework

Let's say I've got a custom framework with a dozen classes and categories. They all inherit from/extend standard cocoa classes. For this reason, my framework links to < Cocoa > during compile.

My question is, if I add a class which requires < QuartzCore >, what is the recommended way to package that?

1) If I simply add the class to the framework, and import QuartzCore, any consumer of my framework has to also import QuartzCore.

2) If I move the class into another framework, any consumer has to import both my frameworks to get the full functionality, as well as QuartzCore. No classes in the first framework can use the second framework.

3) Is there a way to do #ifdef #endif or something similar and then weak-link the QuartzCore fr开发者_运维技巧amework so that both Cocoa-standard classes and QuartzCore-dependent classes are in a single framework, but consumers don't have to add QuartzCore to their projects? If QuartzCore is not present ideally the class/category simply wouldn't be available to the runtime.

---

Personally, I'd go with #1. Pretty much any non-trivial app should be linking to QuartzCore anyway.

You can weak link the Framework to yours. Remove QuartzCore from the frameworks you link to and then add to "Other Linker Flags" the argument "-weak_framework QuartzCore".

Full documentation on weak linking is in Xcode. There is a guide called "Weak Linking With Apple Frameworks".