The iPhone OS 4 SDK was released last week, but it’s not all good news
for iPhone (and iPad) developers. That’s because Section 3.3.1 of the iPhone Developer
Program License Agreement comes with a new catch:
Applications may only use Documented APIs in the manner prescribed by
Apple and must not use or call any private APIs.
This addition came at a particularly bad time for Adobe, which just released the latest version of its flagship Creative Suite software bundle. Included with Flash Professional CS5 is a tool that Adobe clearly had high hopes for: the Packager for iPhone, which would give Flash developers the ability to compile their Flash applications as native iPhone apps.
Not surprisingly, Adobe wasn’t amused by Apple’s newest restriction. Adobe’s Lee Brimelow called it a slap in the face to developers, and while much of the attention on Apple’s move has focused on the battle between Adobe and Apple, other third party solutions that enable developers to build iPhone apps without writing Objective-C are also trapped in no man’s land.
Apple CEO Steve Jobs is aware of the controversy his company has created, and responded to one developer’s email with a terse explanation:
We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.
To be sure, there is some truth to this. Intermediate layers do, in many cases, limit a developer’s ability to take full advantage of a platform’s capabilities as it evolves. That obviously has implications for the platform if a significant number of developers are relying on the intermediate layers. But in blaming intermediate layers for sub-standard apps, Jobs overlooks four simple facts…
Poor programmers are always going to produce crappy software.
The language and the tools don’t matter. Crappy software is rarely the product of ‘intermediate layers‘; it is almost always the product of developers (lazy, under-skilled, etc.). Good, experienced developers are capable of assessing their needs and selecting the right tools for the job. When it comes to iPhone/iPad apps, that might mean building an app with Objective-C. But in some cases, using a tool like Corona or Titanium Mobile could make far more sense.
Eliminating ‘intermediate layers‘ will not, by itself, ensure that an app has been developed well, and by restricting the tools that developers can use, may actually result in lower quality apps as developers are less than ideally forced to develop using methods and tools they don’t like or are less experienced with.
Platform features are overrated.
One of the arguments that can be used to support Jobs’ stance is that if developers use third party tools to develop iPhone apps, developers may not be able to (or may not be encouraged to) take advantage of new features of the platform that differentiate it from other platforms.
But this is a red herring in my opinion. Anyone who has spent any time looking at iPhone apps knows: the vast majority of the apps don’t take advantage of the iPhone platform’s most advanced features. Again, good developers are quite capable of assessing what tools they need to achieve their goals. Apple, quite cynically, seems to believe that they’re not all capable of doing this.
The iPhone/iPad developer ecosystem is so vibrant.
If there were only one or two tools that allowed developers to create iPhone apps and none were any good, Steve Jobs might have a point. But the truth of the matter is that many of the tools that enable developers to build iPhone apps without Objective-C are quite decent. And their creators have a significant incentive to stay up-to-date with the iPhone platform’s capabilities and to meet Apple’s quality standards. After all, the most robust tools will be most attractive to developers, and tools that produce iPhone apps that consistently pass muster (eg. get past the App Store gatekeepers) are obviously the only ones that will gain traction in the marketplace.
Lock-in offers few real-world advantages.
On the surface, Apple has reason to fear a “write once, run everywhere” world. After all, if developers can write one application and compile it for use across multiple platforms (the iPhone, Android, etc.), other platforms may increasingly be able to offer consumers the same sort of apps and experiences that are more likely to be found exclusively on the iPhone today.
But this train of thinking is flawed. There are distinct demographic differences between the users of various devices, and it’s especially hard to argue that the iPhone is going to lose its consumer appeal simply because someone can buy the same apps on devices running other platforms.
In short, Steve Jobs has no logical reason to fear ‘intermediate layers‘. He should embrace them, and Apple would be wise to help guide the development of third party development tools by working with the companies that have created them. Apple could probably even monetize such relationships if it wanted to. But Apple’s illogical ideological, emotional and competitive interests are apparently preventing it from seeing the obvious.
As I’ve stated before, Apple is free (and should be free) to do what it thinks is best for its business. It’s hard to argue with success, and Apple has that in abundance. Apple’s success today, however, masks its past failures and its fearless leader would be wise to consider that past is often prologue: a certain level of control is beneficial, but seeking too much of it is detrimental.
Apple’s lust for control is a big reason why Bill Gates became the world’s richest person instead of Steve Jobs (and why you’re far more likely to use a PC than a Mac) and while it would be naive to argue that the today’s mobile market isn’t a completely different ballgame (it is), in my opinion it seems inevitable that Apple’s micromanagement of the iPhone platform and overly paternalistic attitude towards developers is more likely than not to become a liability at some point, especially as the number of viable business opportunities provided by less restrictive platforms like Android grows.
Photo credit: Danny Novo via Flickr.