When you are competing to be the dominant platform, compatibility is an important strategic variable. Generally if you are the upstart you want your platform to be compatible with the established one. This lowers users’ costs of trying yours out. Then of course when you become established, you want to keep your platform incompatible with any upstart.
Apple made a bold move last week in its bid to solidify the iPhone/iPad as the platform for mobile applications. Apple sneaked into its iPhone OS Developer’s agreement a new rule which will keep any apps out of its App Store that were developed using cross-platform tools. That is, if you write an application in Adobe’s Flash (the dominant web-based application platform) and produce an iPhone version of that app using Adobe’s portability tools, the iPhone platform is closed to you. Instead you must develop your app natively using Apple’s software development tools. This self-imposed-incompatibility shows that Apple believes that the iPhone will be the dominant platform and developers will prefer to invest in specializing in the iPhone rather than be left out in the cold.
Many commentators, while observing its double-edged nature, nevertheless conclude that on net this will be good for end users. Jon Gruber writes
Cross-platform software toolkits have never — ever — produced top-notch native apps for Apple platforms…
[P]erhaps iPhone users will be missing out on good apps that would have been released if not for this rule, but won’t now. I don’t think iPhone OS users are going to miss the sort of apps these cross-platform toolkits produce, though. My opinion is that iPhone users will be well-served by this rule. The App Store is not lacking for quantity of titles.
And Steve Jobs concurs.
We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.
Think about it this way. Suppose you are writing an app for your own use and, all things considered, you find it most convenient to write in a portable framework and export a version for your iPhone. That option has just been taken away from you. (By the way, this thought experiment is not so hypothetical. Did you know that you must ask Apple for permission to distribute to yourself software that you wrote?) You will respond in one of two ways. Either you will incur the additional cost and write it using native Apple tools, or you will just give up.
There is no doubt that you will be happier ex post with the final product if you choose the former. But you could have done that voluntarily before and so you are certainly worse off on net. Now the “market” as a whole is just you divided into your two separate parts, developer and user. Ex post all parties will be happy with the apps they get, but this gain is necessarily outweighed by the loss from the apps they don’t get.
Is there any good argument why this should not be considered anti-competitive?
Cheap Talk 
10 comments
Comments feed for this article
April 13, 2010 at 8:39 am
ninspector
My research is related to this topic, so I would like to say something about it. The platform, developers and end users can be treated as a two sided market. If you assume the developer and the end user are the same, the underlying assumption is that the elasticity of each side is the same, but this is not a general phenomenon in the real market.
In one side, developers must pay the platform for the permissions to user apple development tools (this payment can be negative), and on the other side, end users also need to pay the platform to use the software. Simutaneously , the end users pay the price to the developers.
For example, we have portable and iphone as two platforms, if a developer uses cross-platform tools to development, it can be regarded as a multi-homing developer. However, now apple precludes this possibility and thus such contract is exclusive.
Under exclusive contract case, the developers indeed must endure the monopoly power of app store, but it also beneficial to have a “responsible” platform that internalizes the externalities between developers and users;
under multihoming case, the monopoly distortion is smaller but the dead weight loss from the externalities between the two sides also increases.
From this point of view, it is not clear that apple’s policy decreases the consumer surplus or the developer’s profit.
By the way, specialized tools is generally more efficient than universal tools, therefore, forcing the developers to choose specialized tools is not even definitely decreases the number of developers. the logic is:
exclusive contract —- qualities of software improve—more end users join the platform
and if the developers and users can rationally expect this result, ex-ante, there are more entrance in both sides.
April 13, 2010 at 9:33 am
Marciano
A techie comment: Apple’s move is not just anti-competitive; it also runs the risk of throwing away the baby with the bath water. According to the new SDK terms, you *must* write C, C++ or Objective-C code, period (well, that plus Javascript, but even then you must use Apple’s built-in interpreter). Also, you cannot use any ‘compatibility layer’ or ‘framework’. That’s bad: EA, for instance, uses a scripting language called Lua to implement the game logic in many of their products. Many developers use convenience frameworks to avoid repeating the same code over and over again. Both these common practices are now technically no longer allowed.
Even worse, it’s not clear when one draws the line. Suppose I want to use a convenience framework or `compatibility layer’, but instead of just adding its compiled code (bundle) to my project, I include all its source files and recompile them with my project. Now my app is entirely written in C or Objective C, and does not link to any external framework. Am I OK then? And if not, how about copying some boilerplate/standard code from a book — e.g. a numerical optimization routine? Again, where do I draw the line?
My guess is that this rule will be either relaxed, or selectively enforced by Apple (which would also be bad).
April 13, 2010 at 11:39 am
fmb
It seems to me that the app purchase decision involves some unavoidable uncertainty about quality, which reduces market efficiency. Apple’s policy may reduce this uncertainty enough to be a net positive for everyone.
It’s certainly bad for Apple’s brand if many apps are harder to use. The overall experience is remarkably intuitive and easy, but every buggy app undermines that.
I think this is roughly what ninspector said.
Note that on the margin this suggests that distributing any app to yourself should be allowed.
April 13, 2010 at 5:09 pm
Noah Yetter
Is there any good argument why this should not be considered anti-competitive?
“Anti-competitive” practices are basically a myth. This is a COMPETITIVE practice.
May 15, 2010 at 4:19 pm
Free Articles Directory Submission
This is very competitive indeed.
April 13, 2010 at 10:19 pm
Karl Katzke
Another techie comment, but from a techie who handles the design and usability side of things.
Succinctly, I think this would be better summarized as “Apple protecting it’s brand name” than as anti-competitive behavior.
There is absolutely NOTHING that renders this move anti-competitive. It’s similar to tool manufacturers designing proprietary attachment points that are compatible with their own set of tools.
Digression: The holy grail of DIY tools has been the Fein Multimaster for several years now; it combines remarkable capabilities with a remarkable price, and the accessories and consumables are even more remarkably priced. The connections between those consumables and accessories are also proprietary. While other manufacturers have now been able to replicate the tool and even produce attachments for Fein-specific systems due to the expiration of patents, they have chosen to go with their own proprietary attachment schemes. While many competitors are cheaper (MUCH cheaper!), people who use this type of tool regularly will still purchase the Fein brand name product despite the price. This is not because they are locked in (the cost of the tool system, steep as it is, pales in comparison to the high cost of the Fein consumables) but because both accessories and consumables manufactured by Fein are made to a higher standard of quality and switching to another brand would mean using an inferior accessory attachment scheme. Apple consumers have repeatedly shown that they prefer to pay more to get a higher quality of product. In return, Apple tightly controls as much of the experience as possible to maintain that quality, including purchasing as far up and down their supply chain as they’ve deemed necessary, whereas most computer and device companies outsource or partner for large chunks of that supply chain.
Adobe can still compete in this field if they focus their efforts on the Android or Windows Mobile platform (hasn’t demonstrably happened yet), or if they develop a way to generate source code that can then be compiled with XCode Tools or another compiler. (Indeed, Apple’s own X Code Tools uses the open-source GCC compiler to compile source code.)
A direct ActionScript -> Objective C translator may potentially threaten Adobe’s own intellectual property, which is a risk that they will either have to accept or decline on their own. It should be noted that Adobe has repeatedly threatened companies that sought to create similar projects; this is very much a case of a pot calling a kettle black — or a competitor using the media to paint another black. This is rarely covered in the media because it’s mostly played out in boring legal filings against companies too small to have a PR department, but it’s very present in the Adobe EULA.
I could go on about Flash’s failings as a runtime, but I’ll stop there. This is much ado about nothing, frankly, and I’ll be glad to see the day that Adobe is dead and buried under the poor engineering and marketing decisions that they’ve made with all of their flagship products.
April 16, 2010 at 9:44 am
b
Yes, higher quality can be a competitive form of entry barrier….however, contractually excluding 3rd party attachments/complementary goods is clearly anticompetitive by precedent (xerox). If not, we need also to revisit the well-known interaction between microsoft and the justice department roughly a decade ago. In response to Katzke, if these other platforms/software (i’m probably using this term incorrectly as i am no techie and i don’t routinely carry a cell phone even, gasp!) are truly of such lower quality, the very competitive effects you highlight should render the exclusive contracts moot. Clearly Apple sees some benefit to these contracts.
April 19, 2010 at 11:24 pm
Greg
1. “this gain is necessarily outweighed by the loss from the apps they don’t get.” Necessarily?
2. You seem to be considering a local optimum where there are two platforms with easy development of applications that run “acceptably” on either, as in “…but you could have done that voluntarily before and so you are certainly worse off on net.” However, consider another local optimum where the two platforms are completely independent and are specialized for two different sets of users. At this local optimum, any attempt to make them more compatible would be locally pessimising. Thus we can imagine two local optima; which of the two is globally optimal is speculative.
For the present discussion you can imagine Job’s edict as a way of forcing movement from one equilibrium to another. See the discussion of arrow keys at http://www.asktog.com/columns/082iPad&Mac.html.
September 3, 2010 at 8:14 am
From Frustration to Delight
[…] effects were important in explaining the success of some of these, as were brilliant strategies for building and exploiting platforms, but I want to highlight something else all these resources have in common: they all delight their […]
September 14, 2010 at 9:14 am
The Life Are Really Beautiful For All
[…] effects were important in explaining the success of some of these, as were brilliant strategies for building and exploiting platforms, but I want to highlight something else all these resources have in common: They all delight their […]