Apple

Inside Apple's insane developer agreement

Apple's recently released version of its iPhone Developer Program License agreement has caused quite a controversy. Justin James spoke with Appcelerator's Scott Schwarzhoff about what this really means for developers.

Apple recently released a new version of its iPhone Developer Program License agreement, and it has caused quite a controversy.

I am on the record as saying that the Apple iPhone ecosystem is a pretty rotten deal for developers, and it looks like other folks are finally catching on too, en masse. But this new mess got me curious about the iPhone developer agreement, so I did some digging on the subject. To be frank, I am absolutely astounded at what I found, and I believe that signing this agreement is about equal to selling your soul for a grilled cheese sandwich, considering how hard it is to make money in the App Store.

This is the first time that anyone has ever raised a massive stink about a EULA like folks are putting up about this one, and for good reason. As John Gruber reports, this is the new language in the agreement that has everyone so riled up:

3.3.1 - Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. 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).

That's right folks — Apple is now dictating what language you may write your apps in. Did you use MonoTouch to make your app? Sorry, your app is banned. Oh, you mean to say that you invested months of your time or perhaps invested money making that app? Too bad, have a nice day. But what does this really mean for developers?

I spoke to Scott Schwarzhoff, VP of marketing for Appcelerator to find out. Appcelerator's flagship Titanium product could fall on either side of the line depending on who you ask. Note: Before I go any further, there are two things to keep in mind: (1) I am not a lawyer, and (2) Appcelerator is under a very strict agreement regarding what its employees can and cannot discuss; Scott was very clear about this, and throughout the discussion, we stuck to how they view the situation in general terms.

Appcelerator's belief is that there are four contexts to look at the iPhone Developer Program License agreement:

  • What does it say? See above. Appcelerator, for example, uses Webkit JavaScript, compiles to Objective C and an XCODE project (Adobe's packager bypasses XCODE completely), and only Objective C links to public, documented APIs with Titanium applications.
  • What is the intent? Appcelerator's belief is that the agreement is intended to keep Adobe out of the Apple sphere. Adobe announced it is giving up in this market, so it worked. Appcelerator also believes that Apple wants to ensure that applications on the Apple mobile platform look different from other platforms and make use of the unique features of the platform, and "lowest common denominator applications" water down the value of the Apple products. The overall intention is for Apple to control the value chain and dictate what the Apple experience is and not leave it to third parties.
  • What Apple will try to enforce? Appcelerator thinks that apps that use native widgets and functionality should be accepted, but that platforms that bypass XCODE may be in trouble.
  • What will the law allow to be enforced? Only time will tell.

Within this set of interpretation, Appcelerator believes that Titanium should be fine, because the applications are written in JavaScript (which is run by WebKit), and Titanium developers have full access to the native APIs and the Titanium system leverages the native APIs. Another positive sign is that Appcelerator has had more than 50 Titanium applications approved in the App Store this month; PhoneGap, which is similar to Titanium, was also approved. Scott summed the situation up with the phrase "cautiously optimistic." In the spirit of competition and innovation, I hope that their optimism is warranted.

So we have this absolutely ridiculous clause, and you know some folks are going to say, "this is to keep the iPhone from crashing, it helps ensure a quality experience." And sure, they can point to Windows and say, "look at how many crashes on Windows are caused by Flash or third-party utilities." They will have a point. But the fact remains, it isn't the language that causes stability problems, it is poor coding. In fact, one could argue that the many of the allowed languages (particularly C and C++) are substantially more prone to have system crashing apps written in them than banned systems such as Flash and MonoTouch.

If you do some searching, you will find that the EFF has a copy of the iPhone developer agreement (unfortunately, this is the one from January 2010, not the most recent one). I read it, and I can tell you that I will never sign it. Once I read it, I realized that I cannot sign it. Why? Because it is ridiculous! For example, back to the quoted 3.3.1 where it says "Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs." Isn't this something that Microsoft got sued over? Or 3.3.10, which says, "Applications must not disable, override or otherwise interfere with any Apple implemented system alerts, warnings, display panels, consent panels and the like...". which rules out the chance of actually customizing the phone to my tastes.

Wow.

Article 4 contains this gem:

Apple may change the Program Requirements or the terms of this Agreement at any time. New or modified Program Requirements will not retroactively apply to Applications already in distribution. In order to continue using the Apple Software or any services, You must accept and agree to the new Program Requirements and/or new terms of this Agreement. If You do not agree to new Program Requirements or new terms, Your use of the Apple Software and any services will be suspended or terminated by Apple.

In other words, they can change the rules any time they want, and if you don't like it, you are out.

But to me, this is the worst insult in the bunch (10.4):

You may not issue any press releases or make any other public statements regarding this Agreement, its terms and conditions, or the relationship of the parties without Apple's express prior written approval, which may be withheld at Apple's discretion.

You read that right. This is the Fight Club of EULAs. "The 10.4th rule of iPhone Club is: You may not talk about iPhone Club." And the magic revocation clause (Article 8) allows Apple to pull the rug out if you violate this.

And if you think you've been hurt by Apple, don't worry. Article 14 covers liability. Apple's maximum liability is $50.

It has been a very, very long time since I used this space as a bully pulpit for personal politics, and for good reason. But I am making a special exception here because I want to ensure that anyone considering iPhone development walks into it with both eyes open. A few months ago, I really wanted to look at iPhone development. I can't do it. I can't sign that agreement. Look, I'm a member of the Microsoft ecosystem, by and large, but I felt like Microsoft dropped the ball on mobile (it remains to be seen if Phone 7 can save them), and I think it's down to Android and iPhone. Long-time readers know that I am no Google supporter from the user perspective (I really hate Google's privacy situation), but as a developer, Google is doing it right, all the way. Apple is nuts to have an agreement like this, and you'd have to be nuts to sign it. There are plenty of ways to make money without signing something like this agreement.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.

———————————————————————————————————————————-

Get weekly development tips in your inbox
Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

Editor's Picks