Any vendor in the platform business knows that their primary product is programming interfaces—the so-called APIs that developers depend upon in order to deliver applications. The API exposes features of the platform, and differentiate applications running on that platform from all others. Lose control of the API, and you will lose control of the developer. Developers are the leading indicator for platform success. Ergo, lose the developer, lose the platform.

Steve Jobs’ protestations about quality aside, Apple’s recent moves to bar developers from using any but Apple approved technologies to write iPhone applications is naked self interest… nothing new. For example:

• In 1992, Borland was kicking Microsoft’s rear with Turbo C++ and a development framework called Object Windows Library (OWL) which abstracted the underlying Windowing system out of existence, allowing developers to write applications that run on several OS platforms, including IBM’s competing OS/2. In Canada, Microsoft’s developer market share was below 30% in 1992. They were about to lose the entire Windows franchise to Borland—a company that made programming languages. Microsoft responded by releasing C7 with the Microsoft Foundation Classes (MFC), Visual Basic, and a number of other tools that eventually became Visual Studio. Within less than two years, market share amongst developers had climbed back over 70%.
• In 1993, IBM made their famous statement that OS/2 was a better Windows than Windows. They allowed Windows applications to be run inside a virtual machine on OS/2, giving them instant access to the thousands of Windows applications on the market. Having done that, however, developers chose to write applications for Windows instead, knowing that they would run well on OS/2. IBM never made significant inroads into the developer community, and OS/2 never gained traction.
• In the telecom industry, Nortel (and many others) routinely asked developers to sign NDAs before allowing access to the APIs for their products. The NDA was a legal mechanism by which vendors could prevent their APIs from falling into the hands of competitors, and thus hinder the development of compatible knock off technologies.

Controlling APIs by tying them to the use of specific development tools is simply a bare-knuckled way of retaining control of the platform, which is critical to the health of the iPod/iPhone/iPad franchise. It’s not about screwing Adobe or developers who use Flash. It’s about not allowing Adobe and other cross platform vendors to screw Apple.

As Microsoft learned from their experience with Borland, Jobs and co need to be mindful that developers will naturally migrate to tools which offer advantages such as productivity improvements, cost savings, or user experience benefits. Prohibitions, unfortunately, will only work for Apple for a short time. Ultimately, they must choose to compete for the hearts and minds of developers. I expect that they already know that, however, and are planning one or both of:

• a licensing program to allow third parties to build development tools that use the iPhone API natively.
• a suite of modern development tools and languages that give productivity benefits in line with what developers are used to in the web development world. MacOS already comes with Ruby built in. Why shouldn’t iPhone OS also support Ruby or something similar?

Either would also be in their rational self interest.