One of the highly touted features of the iPhone is the abundance of applications available for near-instantaneous download and seamless installation. In traditional Apple fashion, in order to keep full control of the software environmnet and maintain this seamless experience, Apple exercises strict control over which apps are made available through the app store. Short of jailbreaking your phone, there is no other way to install third-party software.
The process by which apps are submitted and reviewed strikes many as highly inefficient. (It also strikes many as anti-competitive, but that is not the subject of this post. There are legitimate economic arguments supporting Apple’s control of the platform and for my purposes here I will take those as given, although for now I remain agnostic on the question.) Developers sink significant investment producing launch-ready versions of their software and only then learn definitively whether the app can be sold. There is no recourse if the submission is denied.
(Just recently, we witnessed an extreme example of the kind of deadweight loss that can result. A fully licensed, full-featured Commodore64 Operating System emulator, 1 year in the making, was just rejected from the app store. )
Unfortunately, this is an inevitable inefficiency due to the ubiquitous problem of incomplete contracting. In a first-best world, Apple would publicize an all-encompassing set of rules outlining exactly what software would be accepted and what would be rejected. In this imaginary world of complete contracts, any developer would know in advance whether his software would be accepted and no effort would be wasted.
In reality it is impossible to conceive of all of the possibilities, let alone describe them in a contract. Therefore, in this second-best world, at best Apple can publish a broad set of guidelines and then decide on a case-by-case basis when the final product is submitted. This introduces inefficiencies at two levels. First, the direct effect is that developers face uncertainty whether their software will pass muster and this is a disincentive to undertake the costly investment at the beginning.
But the more subtle inefficiency arises due to the incentive for gamesmanship that the imperfect contract creates. First, Apple’s incentive in constructing guidelines ex ante is to err on the side of appearing more permissive than they intend to be. Apple knows even less than the developers what the final product will look like and Apple values the option to bend the (unwritten) rules a bit when a good product materializes. While it is true that Apple’s desire to keep a reputation for transparent guidelines mitigates this problem to some extent, the fact remains that Apple does not internalize all the costs of software development.
Second, because Apple cannot predict what software will appear it cannot make binding commitments to reject software that is good but erodes slightly their standards. This gives developers an incentive to engage in a form of brinkmanship: sink the cost to create a product highly valued by end users but which is questionable from Apple’s perspective. By submitting this software the developer puts Apple in the difficult position of publicly rejecting software that end users want and the fear of bad publicity may lead Apple to accept software that they would have like to commit in advance to reject.
The iPhone app store is only a year old and many observers think of it as a short-run system that is quickly becoming overwhelmed by the surprising explosion of iPhone software. When the app store is reinvented, it will be interesting to see how they approach this unique two-sided incentive problem.
Update: Mark Thoma further develops here. He didn’t ask in advance for permission to do that, but if he did I would have given encouraging signals but then rejected it ex post.