Re: Private Frameworks

FROM : Chris Hanson
DATE : Mon Jan 14 06:51:25 2008

On Jan 13, 2008, at 12:55 AM, Kyle Sluder wrote:

> Assuming you're building your framework as part of the same project as
> your actual app, you can simply mark the role of the framework's
> header files as private, and #import them in your app's source using
> relative quoted paths like #import "FrameworkHeaderFile.h", rather
> than the typical #import <FrameworkName/HeaderFile.h> paradigm.


That's not what the "private" header role is for.  It just determines 
whether, when building a framework, a header is left in the project, 
copied into a framework's PrivateHeaders directory, or copied into a 
framework's Headers directory.

It doesn't change at all how you import the header.  Specifically, 
*headers that are part of frameworks should always be imported using 
framework notation*.

Let's say I have a framework Foo where I implement a class Bar. 
Initially Bar is entirely internal to the framework (Bar.h has a 
header role of "project") so I always refer to it as "Bar.h" in 
#import directives.  Then I want to make Bar available to my own apps 
that use this framework, so I change its header role to "private".  At 
the same time I do this, I will *fix up* all references to "Bar.h" to 
actually use <Foo/Bar.h> so it's always used consistency.

If I want to ship my app with my framework embedded, after the Copy 
Files build phase that embeds it, I'll just have a Run Shell Script 
build phase that deletes all PrivateHeaders directories.

> You're still going to need to link the app to the framework and copy
> the framework into the app bundle's Frameworks directory, but this way
> you won't be copying the headers with it.


Private headers are still copied, just to a different directory.  You 
can reference them just like public headers, but they're easy to strip 
out after building when you don't want to publish them outside (say) 
your team.

  -- Chris