Every public API starts its life as a private API written for some specific application, and goes through many iterations before its finally carved in stone and added to the public API.
If Cocoa Touch doesn't do something you need it to, Apple's framework engineers want to know about it. File a bug.
Nobody, not even Apple, can develop a perfectly designed API by simply waving a magic wand. It takes a lot of time and careful consideration, and involves feedback from developers because they're the ones who have to work with it. Otherwise you end up with an inconsistent mess that's a pain to use.
Apple's own applications have been using APIs and have had capabilities unavailable to third parties since day one. The only difference with iBooks is that the app is distributed through the store, but that is completely orthogonal to the issue of private APIs. I cannot make myself get outraged about this.
I wouldn't say I'm outraged over it, but it seemed like a nice system to have the built-in apps (which can't be competed with since Apple explicitly disallows apps that duplicate built-in functionality) have free reign to do whatever they wanted but have Apple's own App Store apps, which compete with 3rd party apps, do so on a level playing field.
There's a fairly substantial difference, in that all Apple apps that used private APIs came installed with the device. They weren't competing for a share of the app store market.
Apple is now directly competing for the same dollars as everyone else on the app store, but they're doing so using tools that nobody else is allowed to use.
I've always thought of regular iPhone developers as 3rd class citizens of the platform. First class is reserved by Apple, who get to do anything they wish. Second class is large/well-known/well-connected companies which get exempted from some of the limitations and finally Joe Developer with every limitation and app-approval thrown at him.
I know this doesn't bother 95% of iphone developers, but it really does irk me.
There are a lot of comments about how private APIs is normal, and this is true. The big difference between the iPad and windows though, is that developers could (and did) leverage the private APIs on windows.
This had it's upsides and downsides:
Upside: cool functionality in 3rd party apps
Downside: Either MS had to bend over backwards to support APIs that were never public, or older apps would break on newer versions of windows. MS would be blamed for this breakage, not the developers that used an undocumented API
Obviously Apple is doing this to prevent the downside, but it does mean that 3rd party apps are more worse off then they were in the windows world, where they could at least reverse engineer and release.
I don't think it translates a will to be unfair, but rather, a side-effect that once an API is public, you have to support it publicly (and that's a lot, lot of work and money on the long run).
If the API is only "public internally", that means a lot less friction if they need to improve it.
Microsoft was also bundling. E.g. Internet Explorer.
To its (very slight) credit, Apple doesn't ship the iPad with iBooks installed by default.
Their control of the App Store is perhaps more-problematic (Microsoft couldn't actually stop competitors from using those undocumented APIs, once discovered). But at the same time, Apple doesn't dominate the mobile market like what Microsoft had on the desktop. (Similarly --obligatory bad-car-analogy-- auto companies exercise far more control over their dealership networks than Microsoft ever did over its resellers. But the FTC/EU took issue with Microsoft because of its monopoly status.)
Also, there's always the inconsistent treatment of game consoles to consider. The FTC has never investigated a dominant console supplier for not allowing any app from any developer onto their console. And Apple's App Store is wide open when viewed through the lens of that market.
They don't have it pre-installed, but as soon as you open the App Store for the first time you get a system alert message prompting you to download iBooks.
Seems like maybe iBooks was intended to be a "first class" app but they couldn't make the schedule to make the OS image, so they decided to distribute it over iTunes.
And perhaps they wanted to allow Kindle etc on the store without raising the controversy of why they don't block them since they duplicate built-in functionality.
I would sure want the luxury of instantly pushing out a minor update to all users of the app rather than having to wait months if I was internally developing a first party app.
Also once Microsoft found that their undocumented APIs were in widespread use, the still continued to support them or created shims that recognized certain applications and made sure their still worked.
Exactly what I was thinking while reading this article. Taking advantage of control of one market to push it's own products in favor of competitors in another market.
If Cocoa Touch doesn't do something you need it to, Apple's framework engineers want to know about it. File a bug.
Nobody, not even Apple, can develop a perfectly designed API by simply waving a magic wand. It takes a lot of time and careful consideration, and involves feedback from developers because they're the ones who have to work with it. Otherwise you end up with an inconsistent mess that's a pain to use.