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
...
Catherine: Full Body’s English translation for the Vita