Engadget Cares: save us from Apple's groundbreaking, developer-shackling App Store

It's not hard to argue that the App Store's inspired success for the mobile software world, with over 100 million programs downloaded on only a few million phones in just a matter of months. Palm, Nokia, Microsoft must all be simmering (and understandably so). But Apple, if you're having trouble getting buy-in from passionate developers with a serious creative vision for iPhone apps beyond the dozens of me-too calculators and to-do lists -- and you know you are -- the writing's on the wall, and you're the one who put it there.

But it's not just about the draconian SDK agreement (which we'll get to in a minute), or the uncertainty that runs through every developer -- large and small -- as they wonder whether you'll will give the all-important thumbs-up to the app they've just invested all that blood / sweat / tears / money into (we'll get to that, too). What seems to the rest of us like nefarious intent may simply be Apple coming to grips with its own successes by reacting with the same kneejerk response it plies to most everything else: control and micromanagement.

Let's rewind for a moment though, and go back to what Steve said at this Spring's iPhone roadmap event, where the SDK was introduced for the first time. As Steve's introduction reached its crescendo, he excitedly declared, "The developers and us have the same exact interest, which is to get as many apps out in front of as many iPhone users as possible," but "there are going to be some apps we're not going to distribute: porn, malicious apps, apps that invade your privacy..." The slide listed "malicious," "illegal," "porn," "privacy," "bandwidth hog," and "unforeseen." Ah, unforeseen -- glorious wiggle room. I suppose "apps that might compete with our own" wouldn't have gone over as well with the crowd. Read on.

As soon as the iPhone SDK's legal agreement made its way into the hands of eager developers, it became clear just what everybody was in for. Paraphrased in layman's terms (and vetted with help from our own geek-lawyer extraordinaire, Nilay), here are the key clauses your developers have to agree to in order to write an app for the iPhone:

Sections 2.1 and 2.2b: Use our SDK -- which is the only way to make a proper app -- but you can only distribute the applications through us. We're it. Make an app and try to sell it without us, and you're totally liable. Oh, and sub-note: we can approve or withhold an app at our sole discretion, and we're in no way responsible for your business's viability, nor your investment of time or money should we decide not to consign it in the App Store.

Section 3: You can't make apps that are mean, evil, malicious, install backdoors, etc. Alternately, no VoIP over cellular, no providing real-time route guidance, and nothing intended for use in emergency / life-saving situations. Don't breach anyone's copyright -- and don't screw with us.

Sections 5.1, 5.2, and 5.3: This SDK legal agreement is confidential. Engadget shouldn't even be writing about it. Also confidential: any knowledge we share with you about how to develop iPhone apps. So if you were thinking about doing a blog or a book about developing for the iPhone, or simply open-sourcing your app, then think again. Knowledge is a dangerous thing -- why do you think we did a commercial themed after Orwell's 1984?

Don't worry though, not everything is confidential: namely, anything you submit to us will be absolutely "non-confidential." We can talk publicly or privately about your apps without warning -- including what they do and how they work -- to whomever we want (including your competitors), and even before you've announced anything. We can also look at what you're doing, knock it off, and release our own version without any reproach. Trust that we wouldn't do such a thing, though.


Besides a few very specific callouts (like the no VoIP on cellular bit), all we've got to go by is one vague, gray, largely unspecific blanket statement: "No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and builtin interpreter(s)."

Basically, that means that you can't build anything that you haven't prescribed in its given tool and feature set. So if the iPhone already has something like, say, a browser (read: mobile Safari), and Google wants to port a mobile version of Chrome for the iPhone, Google's out of luck. And Apple's legal wiggle room is unbelievably broad. Is a Word / Excel editor a code interpreter? Is a BitTorrent client a code interpreter? Should one have to build a complete and fully functional piece of software just to find out?

Thankfully, you guys have a fast-tracked review process for rejected apps so devs don't have to go to the back of the line if their program has some fixable but show-stopping issues. But mitigating the inherent risk of having their hard work nixed, developers are likely to either avoid the platform entirely for applications requiring any significant level of investment, or do as a huge portion of devs alrady have, keeping their apps largely limited to completely safe, un-interesting, dare I say novelty concepts. It's like the SDK doctrine, purposefully or not, gave Sturgeon's Law ("ninety percent of everything is crap") a big helping hand by de-incentivizing the best developers from doing anything interesting. Calculators, to-do lists, dictionaries, flashlights, there are hundreds and hundreds -- but not a single app that will sync my Google Calendar over the air, or help me manage my multiple Gmail accounts, or let me acquire podcasts -- the most frequently updated content on my device -- on the go.

In fact, each of those kinds of apps has, among others, been blocked or rejected. As developer Synthesis discovered in creating their iPhone SyncML client, there's no way to directly sync the device's calendar over the air with CalDAV / SyncML. Sure, one can do this with the Apple-endorsed methods (via Exchange or Mobile Me), but unlike the iPhone's relatively open contact database, devs aren't allowed to touch the iPhone's calendar database. No one really knows why, and they're certainly not being offered any explanations. Sorry, Synthesis.

Then there's more recently MailWrangler, and the now-infamous Podcaster, two apps rejected for not "providing sufficient differentiation or added functionality" and "duplicating the functionality of... iTunes," respectively. Podcaster allowed for podcast downloads on the go, while MailWrangler gives users legitimate, Apple-prescribed means of accessing multiple Gmail accounts without having to log out and log back in again.

But here's the real kicker in all this: there are already numerous iPhone apps with very real, very clear code interpreters built in, as well as other apps with features that don't just kind-of-maybe-sort-of duplicate Apple functionality -- they do so outright. And they're available right now on the App Store. I won't call those apps out here, as I don't want to see them get taken down just to make a point, but there are apps that already fully encroach on Apple's own objectives for the device, and they were most certainly let through.

So why is Apple rejecting some apps and letting others pass? I'm not sure there's any simple answer. Macworld editor Jason Snell wrote on this same topic just yesterday, insinuating that some malicious behavior "can just as easily be explained by incompetence." And given the piss-poor quality and frequency by which many of those apps "duplicate" the functionality of Apple's software (both on the desktop and iPhone), the rules of acceptance seem in many ways more arbitrary than iniquitous. Let that sink in for a moment, though, because it's kind of an unsettling conclusion we're beginning to arrive at: not only are there no known hard and fast rules to abide by when writing a program for the App Store, there's quite likely to a largely subjective smell-test for apps towards the end of the review process. It's not just about playing by all the rules, it might also be a crap shoot -- developers had better hope they get assigned an App Store reviewer who's feeling generous that day.

So it seems to me, you have two possible courses of action to clean up this mess, Apple: one, the bare minimum of courtesy and respect for its developers, and the other, full-on-righteous. If absolutely nothing else, you need to post some very clear, very easily interpreted guidelines as to what will and will not fly in the App Store. No more mystery, no more concern as to whether the investment associated with developing a program will be for naught if some faceless App Store approval technician semi-arbitrarily decides to hit reject. Just lay it out for all to bear and follow. Sure, there will be a lot of hating going on when Apple says in explicit terms that Mozilla has zero hope of ever getting Firefox on the iPhone, but at least the crippling uncertainty is removed from the equation. You shouldn't have to be one of the hallowed few approved by the iFund to be certain before you start work on your app that it will be approved.

Now, if you want to do the right thing -- the thing that may ultimately keep you out of some grumpy developer's class-action lawsuit, the thing that will take away Android's biggest consumer appeal right now -- you'll will simply stop filtering apps based on content, and only look for the kind of code Steve specifically promised to protect users against in the first place: grossly buggy and broken, malicious, or otherwise evil. I'm not exactly convinced of the latter's likelihood, but closed market or open, at a certain point this whole thing becomes about consistency and reliability, and right now you've got neither to wave in your defense, Apple.

In the meantime, groups like the iPhone Dev Team will continue to carry the torch for jailbreaking, hacking, and unauthorized app development. Hell, jailbroken development will even likely gain steam as increasing numbers of users can't find enough apps of any real utility on the official App Store. Even big companies like Sling Media have taken to working around the walled-garden. So here's to doing good by all the good people willing to invest in your platform, and to the simple kind of change that Apple, as a company, can make today if only you think a little harder about tomorrow -- and everyone living in it with an iPhone or iPod touch.

http://www.engadget.com/2008/09/25/e...g-developer-s/