Pandering to Content Providers Hurts Usability

In an essay titled "Welcome to iPhone: Your Crappy Mac of Tomorrow, Today!", Mike Ash of Rogue Amoeba writes:

Code signing is used pretty much only for evil on the iPhone, and it could easily shift that way in Mac OS X as well.

In a response, Michael Tsai of C-Command Software writes:

I think most of what Apple has done is defensible.

Yes, the things Apple has done are defensible. They did these things for good reasons. Unfortunately, not good enough reasons. Apple's reasons are not user reasons, they are content provider reasons. Pandering to content providers may help a platform in the short run, but the decreased usability which invariably results from such moves¹ is incredibly harmful in the long run.²

Addendum: Matt Legend Gemmell disagrees, writing:

Fact is, pandering to content providers provides fucking content. It's a continuing negotiation process between Apple and these providers, and we all know that Apple is about as politically bleeding-heart-liberal in its views on DRM as it possibly can be without gross fiduciary irresponsibility.

Given that Apple doesn't even provide the option of selling non-DRM'd, unsigned or self-signed iPhone applications, I have to wonder about Apple's "bleeding-heart-liberal" views on DRM. And pointing out that Apple is a business does not imply that they can't be criticized for their actions just because said actions may make them money.

Still, the point about content providers being able to force Apple into providing DRM'd solutions is correct, and I should have spent more time discussing different aspects of this issue. I apologize for my poorly reasoned, one-dimensional blog post (in my defense, I mainly wrote it so I could link to Mike Ash's and Michael Tsai's posts) and resolve to do better in the future :-)

Maintaining the balance between DRM and usability is not easy, and I tend to agree with the notion that Apple historically did a swell job of it.

Finally, as somebody who has to maintain an application which provides an SDK, I understand the issues involved in providing stable APIs. I have absolutely no problems with Apple keeping parts of the iPhone's API private if they are not yet mature enough for public consumption.