Apple’s new iPad apps – iBooks, Pages, Keynotes and Numbers – wouldn’t be accepted into the App Store if they were submitted by an outside developer. That’s because they use private APIs that other devs don’t have access to. Yet.
Some features that these first party apps have, such as access to the system dictionary or true brightness control, aren’t available in the current iPad API. This frustrates developers like Marco Arment, who created the popular Instapaper.
This has been problematic in our industry before, and we’re going to start seeing the same arguments against Apple – rightfully so – as they move into more application markets and exert unfair advantages.
That’s not the kind of development or software-market environment I want to see, as it would be a waste of a great platform and great potential. Ideally, Apple should only publish first-party App Store apps that would be approved if they were submitted by a third party, and they should therefore use no undocumented or prohibited APIs.
However, these programming classes would most probably be available in future releases of the iPhone/iPad Software Developer Kit. Apple has a long story of introducing new operating system APIs in their own software before making them available to developers. Usually, this happens because of timing issues. Sometimes, Apple’s software engineers have to rush to meet a deadline and need new functionality that is not in the OS. This forces them to make new APIs, which require appropriate documentation for developers to use. Sometimes these APIs are experimental or in progress. There are countless examples of this process first-app-then-public-API in Mac OS X or iPhone OS – like the web browsing view or some of the video processing features of Final Cut Pro.
But still, since Apple is selling their apps in the App Store right alongside everyone else’s apps, it’s natural for those devs to feel like it’s tough to compete when the competition isn’t playing by the same rules. [Marco.org]Additional reporting by Jesús Díaz