Unpublished is Unpublic

John Gruber’s latest post, “Private”, calls Erica Sadun to task for her invention of a distinction between “private APIs” and “unpublished API’s”.  I completely agree.  The distinction is nonsensical.

On technical grounds, of course, it’s a valid distinction, if not a valid characterisation.  Her “unpublished” APIs are APIs that are available in public frameworks, but not documented in the headers.  Her “private” APIs are APIs in private frameworks (i.e. those with no headers, installed in the “PrivateFrameworks” directory, as opposed to the “Frameworks” directory).

There’s also a distinction from a programmer-level point of view.  It’s much easier to use a private API from a public framework; just call it in the normal fashion after declaring it in a ‘fake’ header, or more safely, check its existence then call it (and if it’s not there,  fail gracefully).  For an API in a private framework it’s more complex; you need to link to the private framework, which will cause a crash if Apple removes it (although you could provide more safety by loading the framework dynamically in you code, then checking the APIs as you would unpublished APIs in a public framework - I believe that the iPhone security model might prevent this though?).

On more abstract grounds though, those that Gruber classifies as “social”, the distinction makes no sense.  For one, I can absolutely guarantee that the API implementers are making no distinction: if it’s not documented in a header, it’s private, and subject to change.  In fact, if you’re going to insist on making a distinction, you could even argue that the private APIs in public frameworks are the “more private” ones: for every private API in a public framework, an engineer has made the conscious decision that it should not be public.  In a private framework, even the primary APIs - the main ones used to interact with the framework (by Apple, in its own apps) - are private.  Of course, that distinction is nonsensical too, but I think it’s just as valid.

If you really understand what you’re doing, and you understand how Obj-C works,  there’s a case that you can safely use private APIs in some limited circumstances if your main functionality doesn’t depend on it, and you fail gracefully if they’re not there.  That doesn’t mean that they’re not private though.

In the end, if you don’t want your app to break, don’t depend on APIs that are not declared in the headers.  They’re all private APIs.