In Defense of the IPhone API Limitations; the Compatibility Contract
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.
Continue reading "In Defense of the IPhone API Limitations; the Compatibility Contract" »
