[akeefer]

In general a well-reasoned article, but I don't really agree with the contention that private APIs should be removed: when you're shipping releases of something infrequently and you want to avoid breaking client code, APIs have to be something you can commit to supporting long-term without significant changes. Keeping APIs private allows you to provide functionality that you want to have without risking a bunch of stuff breaking client-side on upgrade, since you can update your applications to work with your API as needed. Getting APIs right enough that they can be supported indefinitely is really, really hard, and it's not reasonable to expect that every bit of required functionality will be implemented and designed to such a high level of completeness the first time around.

[Zev]

Personally, I'm with al3x on what he says about private APIs in this post. Here's a few of my favorite moments that I've personally encountered with Apple and private APIs:

* There are APIs that date back to 2.2.1 (at the very least) that haven't changed but won't be made public. And these are APIs that - nearest I can tell (and this is with a rather large amount of testing) - work perfectly fine. Or, better yet, APIs that have existed on Mac OS X since 10.0 (and likely taken from NextStep) still being considered private! (Well, until very recently in at least one case; NSAttributedString was made public without any UIKit additions)

* The docs suggesting the use of private APIs located in PrivateFrameworks. (They still suggest this, by the way.)

* This one is probably my all time favorite: All but calling the task the API performs does trivial and pasting a few lines of code (using APIs that have existed publicly since 2.0) that can reimplement the function in the report, rather then make the API public.

If the API is that trivial to do and the engineer behind the radar is so sure that the code won't cause any problems that they can tell people to use said code, then, why wasn't it simply public in the first place? Someone obviously felt it was useful enough for Apple to have..

* Reimplementing something that the system can already do. In what is, in all likelihood, the exact same way the system implemented it; in a lot of my cases, I end up (unknowingly) creating methods and vars with the same names Apple used for their methods and ivars.

Yes, there are legit reasons to keep APIs private. Big Hacks™ to get a release out the door do happen. But, in my experience with the iPhone/iPad (which is, admittedly, one sided towards what I've experienced), Big Hacks™ and things disappearing between releases isn't the case and keeping many of the APIs private is more of a hinderance than anything else.

And FWIW, relevant radars have been filed for many of these issues as the situation arose, mostly to what feels like an unvarying degree of futility; Radar doesn't get called a black hole for no reason.

[glhaynes]

I have no problem with private APIs per se and always felt that Apple had found a sensible system: apps on the App Store, including Apple's, couldn't use private APIs, but the built-in apps could do whatever they wanted.

But apparently at least iBooks (and maybe iWorks?) on iPad use private APIs. That doesn't seem fair at all: selling side-by-side with 3rd party competitors on the store that can't do the same things Apple's apps can.