Tuesday, April 13, 2010

Is Apple trying to avoid being the next Atari?

There has been a lot of wailing and gnashing of teeth over Apple's latest developer agreement prohibiting the use of compatibility tools or intermediary layers in applications developed for the iPhone. At first, this seems like it could be a draconian measure intended to stop other companies from offering cross-platform developer tools for mobile devices. These tools promise to give a developer the tools to write an application in one environment then create compiled applications for a variety of mobile devices at the push of a button. Without learning the developer environment of any of the mobile devices, developers can crank out applications using a single tool.

To the critics, Apple's move is anti-competitive and aimed at preventing Adobe and other vendors from offering tools such as Adobe's upcoming Flash CS5 which allows an application to be written in Flash then compiled into a pseudo-objective C+ application. These applications would instead run in an Adobe-created layer for the iPhone that abstracts out the hardware-specific features of the phone. Presumably Adobe intends to offer this abstraction layer for other mobile devices which would allow a developer to easily compile their application and run it on Android, the iPhone, Windows phone, Palm OS or any other device as long as the Adobe-provided abstraction layer exists for that particular model.

This sounds attractive. As a developer, by giving control to Adobe I can quickly get applications written for any platform. But there is a dark side to this that we have seen before.

Hardware abstraction layers that eliminate - at least from the developer perspective - the hardware the software is running on encourage a lazy, "least common denominator" model for the devices they operate on. Programmers are not going to add features to take advantage of hardware that are not widely supported, as it will require additional effort to work around when compiled for a device that doesn't have that hardware. This could be seen as an implicit discouragement of innovation as there is no reason to add new hardware if most applications are using an abstraction layer that doesn't support that hardware.

Runtime environments may stifle innovation
In this world, imagine that Apple adds a front-facing camera to the iPhone for videoconferencing. Apple will take a lot of time to ensure that the hardware does not impact battery life too adversely, cooperates with existing applications, and is available through their provided API. But in a world where iPhone applications are developed from cross-compiled Adobe Flash tools, Adobe would control when or if developers would ever be allowed to use the hardware. If Adobe's Flash development toolkit product managers decided against supporting this new hardware by not supporting it in their cross-platform tool then no new software supporting the hardware would be developed. Apple's hardware business would be subject to Adobe's business decisions regarding the availability and nature of features available on the platform.

We saw something like this back in the 1990s when Microsoft adopted a strategy for Microsoft Office for the Macintosh that effectively removed the differences between Windows and Macintosh and made the two programs look and act the same (and I even believe share large portions of the code base) in Office 4.2. This was roundly criticized as one of the worst Macintosh Office releases because it effectively removed the Macintosh experience from the equation. Ultimately, Microsoft abandoned this effort.

Runtime environments may adversely effect quality
There is also a potential quality issue at hand here. In the late 1970s and 1980s Atari dominated the video console scene for the home with the ingenious Atari 2600. By 1982 the Atari 2600 cartridge market became filled with a glut of poorly designed game titles. The E.T. game is cited as the beginning of the great videogame crisis of 1983 which effectively destroyed the console market. By 1983 so many crappy titles overwhelmed the Atari 2600 that game prices plummeted due to unsold inventory and consumers lost interest in the console as quality titles struggled to be noticed. For two years the market contracted, until in 1985 Nintendo released the NES.

Nintendo took a different approach to third-party games. Instead of following in the Atari 2600 model and losing control of the quality, volume and overall customer experience around the NES, Nintendo required third parties to officially license all games before being supplied with a chip that made their cartridges compatible with the standard NES consoles. In this way, Nintendo could prevent the release of materials which detracted from their brand and desired user experience. While subject to a lot of criticism, the NES revived a market that was considered all but dead.

Devaluing the developer
Ironically, in many ways a cross platform, low common denominator abstraction of all mobile hardware also devalues developer skills. Why hire someone who writes clean, tight code in Objective C+, C# or a devices preferred language against the hardware manufacturers API when I can crank out Flash applications that run on all devices. So what if the Flash applications have a weak user experience and limit the value users wring out of their hardware or chew through batteries or lock up all the applications in a unified manner. That will just be blamed on the hardware manufacturer anyway.

Apple's customer experience
The tension now with Apple's strict controls of applications for the iPhone/iPod/iPad platform is also part of the attraction mainstream users have toward the platform. Apple's ability to prevent applications which make poor use of resources (memory hogs, battery hogs, etc.) and their control over the basic user experience means that these devices work. I have yet to experience the equivalent of a blue screen of death on an iPhone.

Despite these strict rules, the application store is quite possibly the most phenomenally successful software store ever created. I've spent less than $150 on software for my new iPad and have more games, content creation tools, video entertainment and utilities than I have on my desktop or my laptop. And I enjoy the experience immensely.

Walking a fine line
Nonetheless, Apple isn't guaranteed a rosy future in its application store. There are many quality competitors out there. Palm has an interesting OS, Android is an "open" platform - although there still are restrictions imposed by Google and their business relationships, Blackberries have open distribution options, and Microsoft offers Windows Mobile and the upcoming Windows Phone environments. Developers and customers can readily move to a new platform tomorrow if they wish. If Apple's rules start to become too restrictive they will risk creating a move away from their devices. That is Apple's business decision to make.

On the flip side, already I've had my Android friends irritated that their particular device is still running an older version of the OS and newer applications won't work properly on their hardware. Such is the challenge of a more open model.

Developers cannot demand that every piece of hardware support Flash, HTML, or any other proprietary or standard technology. Doing so would stifle innovation and competition. I for one am happy that the iPhone has ignited a lot of excitement in the mobile device space and look forward to the innovation Apple, Google, RIM, Palm, Microsoft, and everyone else are forced to pursue to remain competitive in this landscape.

0 comments:

Post a Comment