Apple’s SDK brouhaha explained for non-developers (as if you care)

I’ve got it in my craw to try to explain the current brouhaha behind Apple’s recent SDK changes. It’s a case of history repeating itself, so that a dominant platform can retain its dominance through bullying and complexity.

To understand this issue, you must understand the plight of every business that develops mobile applications. When planning to create an application for mobile devices, this is the conversation that happens at thousands of companies around the world, again and again:

Boss: We want everyone to be able to run our application, no matter what phone they use. Can you create an application that will run on all phones?

Engr: All the phones use different APIs (Application Programmer Interfaces). We can’t write one application that runs on all phones.

Boss: So write a different version of the program for each phone.

Engr: That would take 20 times as many developers as we have, probably one to concentrate on each phone. Can I hire 20 times as many developers?

Boss: No, we can’t afford to hire. So write the application as a web page. I hear web browsers are getting pretty powerful.

Engr: Yes, and very many smartphones are, or soon will be, running a similarly powerful HTML5 browser. But the HTML standard is always about 10 years behind the times in terms of supporting our needs for storage, media input, media output, GPS, compass, touch, tactile, and odor. We can’t do our app in HTML5.

Boss: So we’re back to writing a separate application for each platform. What can we afford to do; keeping in mind that iPhone is the device by which our company will be judged?

Engr: We can spend a lot of time making a really sweet iPhone version, and a little bit of time hacking together good-enough version for Android and Blackberry, then throw together some crap versions for J2ME and Palm and Symbian and Windows mobile.

Boss: Isn’t there some way we can write our application once, and run it everywhere?

Engr: Some way to “write-once, run-anywhere”? Hmmm… That question is beyond the scope of this little embedded dialog. Let’s return to Brent’s blog...

The nirvana solution for every developer with less-than-infinite time and money is to Write-Once, Run-Anywhere (WORA). In a WORA world, you would take the time to write application source code, then flip a switch and the WORA tool would compile that application into something that ran on iPhone, something that ran on Android, something that ran on Blackberry, and Pre, and on and on.

There are two ways to make WORA magic happen:

1. UBER-API: Translate an uber-API into something that runs on all platforms. The most well-known contender in this area is Adobe’s Flash (but there’s also Corona & Titanium & PhoneGap and others). With Adobe’s tools, a developer could write Flash code, then compile that same code into something that would run similarly on a wide range of phones.
2. EMULAPI: Create an API layer on all platforms that copies (or emulates) the API of another platform. To do this, one would emulate the X API on the Y Platform, so that code written for X could then be compiled to run on Y. For example, Google could write a tool to take the Objective-C source code of an iPhone application (possibly even the raw binary application), and run it on and Android via a compile- or run-time layer that emulates the iPhone API.
   

Every dominant platform (i.e. the platform that has the most developers creating for it) has fought to retain its dominance by preventing WORA. IBM did it with mainframes. AT&T did it with Unix. Microsoft did it with desktops. Now Apple is doing it with mobile.

Apple does not want to lose its dominance. Apple does not want WORA. Apple’s tactics to prevent WORA are the same ones used by IBM, AT&T, and Microsoft before it. These tactics are A) bullying, and B) complexity.

A: PREVENTING WORA THROUGH BULLYING

Much has been written this week about section 3.3.1 of the iPhone Developer Program License Agreement, which says, in essence, that no app will be accepted into the app store if it is originally created with a non-Apple API. For as long as Apple can get away with it, this bullying clause prevents WORA type 1: UBER-API. You can read here, here, here or here for more about this brouhaha.

B: PREVENTING WORA THROUGH COMPLEXITY

Apple also announced something else last Thursday that has not been much written about: They announced over 1500 new APIs. That’s 1500 NEW APIs, an addition to the approximately gazillion API’s already in the iPhone SDK.

Why is it so important for a dominant platform to have so many APIs, and for that API list to keep growing? Remember that the second way to achieve WORA is to duplicate the API of the dominant platform. If Apple wants to prevent this form of WORA (i.e. to prevent a developer from writing an app for the iPhone, but being able to then compile that same app to run on Android and RIM and other platforms) they need to keep their API large, complex, and always growing. This makes it hard for another platform to duplicate for two reasons:

1. The shear number of APIs means that a lot of engineers must take a lot of time duplicating those APIs.
2. With so many APIs will come even more bugs. Some small percent of code is going to contain bugs, even if written by the mighty geniuses at Apple. To duplicate Apple’s API well you must also duplicate the bugs, which is even harder than duplicating the APIs themselves.
   

So that’s what’s up with Apple this week. In short, they are now the dominant platform in a space, and they intend to maintain that dominant position for as long as possible by preventing the ability to write an application once and run it anywhere. Apple’s tactics for maintaining their dominance are: bullying and complexity. They’re the same tactics use by every computer platform dominator before them. All of this has happened before, and it will happen again. So say we all.