iPhone Development is Digital Sharecropping

Posted by Adam Lassek | April 12, 2010

Last thursday, Apple announced an update to their iPhone SDK licensing agreement as a part of the iPhone OS 4.0 event. The new clause says:

Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

There’s a lot of nerd rage over this change, and I wanted to comment on the reasons behind it and the general trajectory of the iPhone OS as a platform. Whether you like it or not, Apple’s mobile devices are defining the future of smartphones and we all will be effected by them for good or ill.

Most people have interpreted this as a direct attack on Adobe, whose CS5 product was set to release only days later to include an iPhone development toolkit. If so, they’re leaving a lot of innocent bystanders in their wake: MonoTouch, Unity and Appcelerator’s Titanium just to name a few. The true implications of this policy change are still basically speculative, due to the notoriously selective application of policies by Apple (more on this later).

Many people are actually arguing that this is a good thing, that cross-platform apps are bad and native apps are good, and sometimes you have to piss people off to shed technologies that are holding you back. I’m not unsympathetic to this argument; in fact, I hate that Apple is making me defend FLASH of all things. I hate Flash. It is the bane of my browsing experience, and the sooner it disappears from the web forever, the better.

But to claim that any app written to be cross-platform is categorically inferior to native apps is simplistic and naive. Many cross-platform apps are an inferior experience, it’s true (ironically, I would place iTunes in this category). But some are good. And there are plenty of native apps that are crap. Apple is already holding developers to HIG and API standards that address this problem!

Let’s not mourn for Adobe. They brought this upon themselves by writing crappy software and generally treating Apple users poorly. It’s no wonder Steve Jobs hates them. This isn’t about Adobe, or any particular product. It’s about the relationship between Apple and their users and developers.

Originally, iPod users enjoyed widespread compatibility with their music application of choice. Since the iPod mounted itself as a USB/Firewire drive, it was a simple matter of supporting the iTunes library xml format. But the iPhone was designed from the beginning to use a proprietary syncing system, and an encryption system was introduced to the library to force people to use iTunes. They did this because they were creating an online music store, and rather than compete through a better experience they used their dominance in portable music players to prevent competition.

Despite the fact that the iPhone was a handheld computer, they treated it like an appliance. Only a handful of Apple-created or approved applications were distributed with it. When the iTunes App Store was introduced, you had to submit your application to Apple for approval in order to get it to people. There is no other way of installing software on the iPhone without jailbreaking it, a process that, thanks to Apple’s DRM, is illegal under the DMCA.

The App Store was a huge success and a crushing defeat for developers, depending on how you look at it. Finally the smartphone market had a clear winner: the one device that everybody wanted to own. But at the same time, because of the App Store’s restrictive policies, they were relegated to little more than sharecroppers on the Apple plantation.

To add insult to injury, the approval process is frustrating, obscure and capricious. What few clear guidelines there are, are applied inconsistently. This February, a new policy was announced that any application with “overtly sexual content” was to be banned. This wasn’t entirely bad; Apple was responding to the mass of “sexy bikini babes” applications that were starting to clog the system. But as many small-time applications were getting banned under the new policy, apps such as Sports Illustrated, FHM, and Playboy were allowed to stay despite clearly breaking the rules. The SDK agreement also disallows developers from using a runtime environment to interpret scripts after compilation, but EA games has several games in the App Store that use their LUA scripting language. iPhone developers are not treated equally.

Last Thursday’s change to the SDK agreement is really nothing new. This isn’t about making a stand for quality, or even forcing a paradigm change. The reasons behind this are obvious: anti-competition. The iPhone OS was built from day one to establish Apple as the gatekeeper. If you want to build a peripheral, you have the go through Apple. If you want to release an app, you have the go through Apple. And as anyone who has spent a few minutes browsing the App Store, it ain’t to increase the quality. When they represent the only distribution channel to the device, you have to take whatever you can get. That the Apple apologists don’t see this for what it is I can only ascribe to some form of Stockholm Syndrome.

All APIs are abstractions. Anyone using the iPhone SDK is already several layers of abstraction above machine code; to disallow adding another one in such an arbitrary fashion is absurd. Assembly language was originally developed because writing pure machine code is incredibly difficult. C was created as a lightweight abstraction on top of Assembly. Objective-C was created to add Object-Oriented programming techniques and Smalltalk-inspired message-passing on top of C. Each of these advances involve adding a layer of abstraction on top of a language that already works in order to make it work better. If using another language to generate object code for Apple’s APIs makes me more productive, why is it any of Apple’s business if I choose to do that?

Language-binding is an utterly commonplace programming technique used on every single OS in existence. If they’re willing to deny that, what next? How can I possibly justify the expense of developing an application only to find out some minor detail isn’t to their liking? What if it takes a really long time to rewrite? What if Apple simply refuses to publish it without telling me why? This kind of uncertainty is poisonous to attracting talent to a platform.

There is no reason why having an open platform has to conflict with the type of curated experience Apple is trying to create. Google’s Android App Store also has guidelines, but you are free to install software outside of the store if you choose. There is a clear separation between installing Google-approved applications and non-approved ones, but Google is willing to treat their users like adults. The inconsistency of the iTunes App Store would be far less onerous if Apple did the same.

Why would any self-respecting developer put themselves in a position where their entire livelihood, or at least the success of a contract, depend on the whims of a company that clearly doesn’t give a damn about them? Apple has shown us time and again that their mind can change at any moment, and they don’t care how many people are hurt in the process.

Obviously I feel strongly about this. But I want to make a distinction between Apple the computer company and Apple the mobile company, because there’s a pretty stark difference. I have nothing but good things to say about Apple the computer company; their computers are excellent, their customer service is excellent, and most importantly: OS X is an open platform. For some reason, their mobile users aren’t deserving of the same respect. It’s this infantilization of their developers and users that I take issue with.

Until this changes, my interest in mobile development will have to remain Android-based. It’s a matter of self-respect: are you an independent business, or a sharecropper?