HTML5 vs. Flash/Silverlight/JavaFX
Why did Apple ban Flash (among other things) from the iOS?
John Gruber's insightful blog post, Why Apple Changed Section 3.3.1, cuts right to the heart of the matter, to wit, that this is a tactic to help Apple establish the iOS API as a de facto standard for mobile apps.
This is a very dangerous tactic for Apple. Tactics that are perfectly legit for a non-monopolist (such as Microsoft's Windows pricing policy) are retroactively illegal for monopolists.
Apple's market share of the mobile handset market, at just 2.7%, is far from monopolistic. However, in 2009, 94% of mobile apps were sold into the iOS market. That is, if you want to profit from sales of your mobile app, then you must release it on iOS, and therefore you must develop it according to Apple's dictates. That is pretty much the definition of monopoly power. Once Apple is determined to have monopoly power, tactics such as Apple's banning Flash/etc. are likely to be found to be retroactively illegal. (I cannot over-stress the importance of the word "retroactively" in this discussion.) This is the market that will capture the attention of anti-trust regulators.
An anti-trust inquiry into Apple's tactics has already been launched in the US; I would not be at all surprised to see one follow rapidly in the EU.
Apple's actions impose two new costs on itself:
- Direct costs: Anti-trust defense costs a fortune, in legal bills, fines, and―most importantly―executive focus.
- Indirect costs: Acting in a monopolisitc manner, as Apple is now doing, makes it appear to be evil. Apple has profited enormously from its warm and cuddly reputation, which it has now started ruining. This indirect cost is very likely to far outweigh the direct costs of anti-trust defense.
If Apple's actions succeed in establishing it iOS API as the de facto mobile app standard, however, then these costs can be easily borne out of the immense profits that it will make from the resulting vendor lock-in. Apple would be far more powerful than Microsoft ever was, because it would control
- the central processing unit (A4, like Intel's x86)
- the hardware (iPhone/iPad/iWhatever, like Dell+HP+everyone else)
- the OS (iOS, like Microsoft Windows)
- the app distribution channel (AppStore, like everyplace you ever bought software), and
- the software development tools (XCode, like Microsoft's Visual Studio and the open-source Eclipse tools platform).
Apple would have proprietary control over the entire value chain...except for mobile apps, from which it would nonetheless extract a 30% tax via the AppStore. It would have the most comprehensive computing monopoly since IBM's.
Here are some relevant links:
- Gartner's Ray Valdes: HTML5 and the future of Adobe Flash, the best discussion of how Apple's SDK rules and the rise of HTML5 affect Flash. Qick answer: not much, for now.
- Blogger David R Poindexter: Flash Apologists are Legion, whose comments are prototypically naïve.
- First, it is using the license restrictions on the iOS SDK (and related AppStore approval) to focus independent developers on the iOS API, thereby building a critical mass of support for it, and locking it in as the de facto standard API for mobile app software development, as described above.
- Second, it is preparing for a future transition away from native (iOS or Android) apps to open-standards-based Web apps, in case its iOS-focused strategy either fails or dies a natural death due to the maturation of open standards such as CSS, HTML, etc. Hence, its aggressive support for those standards the open-source WebKit browser, on which Apple's Safari is based. WebKit is intended to ensure that if web apps emerge as the new de facto standard, no one else, outside of Apple, controls that API.
- Implement the iOS API on top of Android, allowing Apple to sell its developers an iOS-to-Android app-porting tool. If this tool were expensive enough, the profit from it would more than make up for any "sales of iPhones lost to Android phones due to the availability of iOS apps on Android," while further locking in the iOS API as the de facto mobile standard. Establishing the iOS API as the de facto API for Android apps would emasculate Android as a competitive threat, by ensuring that any new APIs developed for Android would be ignored by developers...until wrapped by new iOS APIs. If Apple could also extend its mobile advertising restrictions to iOS-based apps running on Android, then the porting of the iOS API to Android could be even more profitable. Alternatively (or in conjunction), Apple could license the iOS to other handset vendors, and license the iPhone as a reference design. This alternative is extremely unlikely, however, given Apple's corporate culture and business model.
- Release, and feature, Apple-branded mobile apps in the best-selling and most-stable categories. Most casual users will favor the Apple-branded products simply because they are Apple-branded (so long as the apps don't suck). This will not only earn Apple additional revenue, but also give it a stable of in-house applications which can help drive future new iOS APIs to critical mass, and with which non-Apple apps will need to interoperate.
- In the short run, Apple's having banned Adobe's Flash-to-iOS deployment tool is a pain. If I needed to sell my app to iOS users (which, thankfully, I do not), then I would have to use Apple's tools, framework, language, etc. for that version...which would not then be portable outside of Apple's universe. That is, I would be compelled to develop and maintain two codebases.
- In the medium term, I would expect to see Adobe find workarounds (such as proxying Flash content onto the iOS as Opera Mini does), which will work just fine for many kinds of content (streaming video, for example), but not so well for some kinds (games and RIA's, for example).
- In the long term, anti-trust action will almost certainly compel Apple to drop its development-tool restrictions.

