iGetIt! Music

Online music education courseware for non-musicians who want to learn how to write their own rock songs.

My Photo
Name:
Location: Austin, Texas, United States

This blog documents the development of JIMS iGetIt! Music System (JIMS). JIMS' goal is to help you Understand Music in 24 Hours™, if you are (a) a non-musician (b) who wants to learn how to write your own rock songs. Requiring no instrument other than your own computer, and without using traditional notation, JIMS is being designed to deliver a deep understanding of tonal structure...in just 24 hours.

Monday, June 14, 2010

HTML5 vs. Flash/Silverlight/JavaFX

Given that I've invested many months in teaching myself Flex, and have a professional background in technology evangelism, I'm fascinated by Apple's decision not to support Flash/Silverlight/JavaFX/etc in the iPad.

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:

  1. Direct costs: Anti-trust defense costs a fortune, in legal bills, fines, and―most importantly―executive focus.
  2. 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:
Apple is attempting to cover two bases at once:

  • 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.

In short, Apple's "banning Flash" has absolutely nothing whatsoever with the technical merits of Flash; it is purely a platform play by Apple. All of Steve Jobs' comments regarding the technical merits of Flash are just smoke and mirrors, to distract attention from the core issue.

To further execute this strategy, I would expect Apple to take two steps:
  1. 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.
  2. 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.



Both of these steps would increase the value of the iOS API standard to developers and consumers, thereby increasing its value to Apple and also locking it in even further.

So, what does all of this mean for Flash/Flex developers such as myself?
  • 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.

And throughout this run, the only affected deployment platform is iOS―that is, Apple's mobile products. Flash continues to work great on Macintosh computers, and on all other computers; just not on Apple's mobile products.

Apple's tactic has slightly devalued Flash/Flex's cross-platform value proposition, but the demand for Flex developers has been rising so rapidly that Apple's tactic is a blip, not a barrier, to the monetization of Flex development skills.

Labels: , ,

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

Links to this post:

Create a Link

<< Home