∞ Apple's use of private APIs for iPad gives it unfair advantage

The fact that Apple’s recently released iBooks is using private APIs means very little to most of us. In fact, the majority of users want the apps to be the best they can, regardless of what kind of programming they use. Unfortunately, for developers, it’s another story entirely. They aren’t allowed to use private APIs in their apps, which may cause some unfair competition.

Apple’s specially privileged, private-framework-using iPhone apps were relatively few, but their first-party area of influence on the iPad has just spread to e-readers, word processors, spreadsheets, and presentation tools: four major markets in which competitors may be at a severe disadvantage by not being able to do the same things as Apple’s alternatives if Apple chooses to play this card there.

iBooks and private APIs [Marco.org]



0 thoughts on “∞ Apple's use of private APIs for iPad gives it unfair advantage”

  1. The article you're pointing at has been updated to acknowledge that iBooks is the only confirmed culprit here. In fact, I've heard the same thing: the iWork apps use public APIs only.

  2. You do realize that this is not a new practice. Microsoft has done this for years and any OS developer will use undocumented or private API calls. They are uniquely qualified to do so. Why? When the OS is updated and the API's they are using are either deprecated or changed, they know the fact ahead of time and are able to make the necessary changes to the applications that use the private API's.

    Third party developers are not necessarily privy to OS changes far enough in advance to safely use private API's. Changes to those API's will destroy their software when the new OS is released and their users update to it.

    If Apple is claiming that some of their software only uses public API's, they are saying that to show that third party developers can make software as good as the software that only uses those API's.

    A great example of private API's being used by third party developers are all the new apps using the live camera data in the iPhone. Its possible that Apple will change that private API call to public since so many developers wanted/needed its use. However, if it stays private and Apple changes that call sometime down the road. Developers that used it will have to scramble to fix their apps when the new OS that changed it is released. Otherwise their apps will die and they will have a lot of unhappy users.

  3. It's not that this is a new practice. It's that that is not how Apple does it or has ever done it. It is not an open platform. Apple's name is on the hardware and the OS. They are delivering an experience and they want it to be a certain way. If you can work inside that experience, great. Otherwise, don't. This is the key to their success and they aren't going to change it so that people can submit flashlight apps that use private APIs.

    People need to stop analogizing how things work on other systems to Apple. Apple is not other systems. That's why people like it.

  4. Another issue might be illustrative. Remeber when Apple pulled the 64 bit Carbon framework at WWDC a few years back? They caught Adobe by surprise. It forced Adobe to stop work on a 64 bit version of CS4 for Mac and start rewriting it from the ground up in Cocoa. Now, Cocoa and Carbon are not Public vs Private by any means. But I think it makes a point about private APIs.

    If Apple were to release a private API before it's done, and they're sure they're going to use it as a public API, then they could end up breaking a lot of apps for no good reason. If Apple is banking on the iBooks application being a long-term success for them, and they are using these private APIs right now, then maybe they're simply a bit behind in getting these APIs done in time? OR maybe iPhone OS 4 will make those APIs public?

    I think we ought to watch closely and see how Apple is going to handle this. That they are only doing it with one brand new Application that's been public only since Saturday makes me want to at least give them the benefit of the doubt for a short while. We shall see.

  5. I don't follow you. Carbon was a deprecated framework in Mac OS X 10.0. It was only there at all because Adobe and others cried about having to rewrite their code. That was 10 years ago. They were not caught by surprise. They were supposed to start moving to Cocoa almost 10 years before they did.

  6. I don't think it's a question of "rights." Apple doesn't have unlimited rights. They can't break the law, just like anyone else. However, what concerns me is whether what they're doing makes sense for users. Not documenting, let alone opening, the entire platform to every person keeps a lot of bugs out of the system.

Leave a Reply

Your email address will not be published. Required fields are marked *