The iPhone API is new. It has yet to mature. Yes, it does use a very mature 20-year-old foundation steeped in the NeXTSTEP heritage as its foundation, there's a lot that was removed or didn't make the translation from AppKit/Cocoa (The Mac OS X API) to UIKit/Cocoa Touch (The iPhone OS API). This even includes things like the tools, where Interface Builder is limited in what it can do for iPhone files as opposed to Mac files. It's a matter of time before things improve, and they are improving. But it's frustrating, despite there being very good reasons for it.
Sometimes it's simply a case of the code not being there, that iPhone controls resemble Mac controls in function and name, but are instead cousins, with a mismatch of abilities and feature support. Other times, it's classes and code that are outright missing because they have no use in the new OS. An obvious example would be Applescript. Sometimes, it's a case that code is depreciated on the MacOS, and rather than adding depreciated code, it's missing outright on the iPhone. Then there is the code that is in the private frameworks, undocumented but with names that provide more than just a hint that promises cool features and abilities that would solve things.
Because we can see them, on the other side of the fence, that makes them all the more tantalizing. Honestly, it's not even a fence, more a line in the sand, because none of the reasons to not use them are technical in nature. It's simply a case of Apple hanging a "Do not touch" sign on them. But it's best to respect this. This is part of the contract between the API and our code.
It's an unwritten contract, but it goes like this: Apple publishes a subset of their frameworks (The public frameworks) with the promise that, if you link to these documented means, the code will continue to run fine, even in subsequent generations of the OS. The other half of the contract, the part the application must do, is to stick to only these published methods and means.
In doing this, the applications have freedom to use the public APIs without worrying about land mines of odd functionality changing, and Apple is free to refine, rename, refactor, and revise the code that is not public. Many frameworks introduced in Mac OS X first started life as a private framework in a previous version of the OS, and were made public only after all the major bugs have been squished. However, if this contract is violated, that apps depend on undocumented functionality, bad things happen, and one of two options are open:
This first option is for Apple to ensure backwards compatibility in a way called bug-compatibility. This is what Microsoft did during the 90s, and in some ways, is suffering consequences for letting happen. All these checks and recreating bugs means bloated code, and blocks to improvements. It means having all sorts of warts in the code; odd lines long forgotten, acting as an anchor to prevent serious change.
The second option is what Apple has historically done: let the apps break, as the contract was not adhered to. If the quirk still persists and the app in question still runs, that's great. But certainly don't go changing the operating system to check the application's name, in fear that actions must be done differently than what is best. I'm biased, but I prefer this, because I feel that this significantly contributed to the rapid changes and improvements that have happened in Mac OS X and what made the iPhone OS even feasible.
The problem is that the iPhone is not a desktop computer. It is an embedded device. And while an app breaking is to be expected every once in a while on a desktop computer, it's unacceptable on a cell phone or other important embedded device. And regardless of whose code it is, Apple would be blamed by the customer. So to avoid this, breaks in the contract must be treated as show-stopping bugs, ones that do not happen now, but could possibly happen in the future.
Bundled apps are exempt from this because of the very nature of being bundled. Suppose the Maps app included in iPhone OS 2.0 does not work with iPhone OS 2.1. This would not be a problem because the 2.0 Maps never will run on the 2.1 OS. iPhone OS 2.1 has its own version, which has been patched and modified to keep up with the shifting frameworks it uses. And for the same reasons, the 2.1 Maps app need never fear compatibility with iPhone OS 2.0 or 2.2. Third party applications that appear in the App Store, however, do not have this luxury and must be forwards-compatible. And as such, using undocumented calls should and are grounds for rejection from the App Store.
