It looks like Apple might be regaining some of their sanity given the recent update to the iOS developer agreement.

Compilers

Section 3.3.1 has been updated to only restrict the use of private APIs. This is a perfectly reasonable restriction. The clause which stated that “applications must be originally written in Objective-C” (in my mind, the most offensive part of the iOS developer agreement) has been removed. I'm very glad to see it's gone.

Interpreters

They also updated section 3.3.2, the “no interpreters” section. The language has changed but the meaning apparently hasn't:

An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework.

The old version of this rule was confusing and unclear, and the new version, despite being less verbose, still leaves a lot open to interpretation. For starters, what does “install” mean in this context? If the user of the app manually constructs the executable code, is that allowed or not?

The definition of “executable code” isn't entirely clear either. My inclination is to assume that this means a Turing complete language, but one could argue that there are even non-Turing complete languages that count as “executable code”. For example, I wonder if an iOS port of the classic 8-bit educational game Rocky's Boots would run afoul of this rule. In the game you would construct machines out of various bits including Boolean logic gates and then use these machines to solve various puzzles. “Running” the machines in the game requires the interpreting of executable code.

Either way, the restrictions imposed by this section probably don't affect as many developers as the old 3.3.1 restrictions did. However, in some ways this rule is actually worse. The old 3.3.1 only restricted how one could build apps but it didn't really limit the types of apps that one could build. The no interpreters rule, however, actually makes it impossible to implement several classes of useful software on the iOS platform, including:

• Web browsers that interpret JavaScript on the client.
• Emulators of legacy platforms, like 8-bit computers or old game consoles, that allow the user to run their existing software (e.g.: game ROMs, etc.).
• Educational development tools like Scratch.
• Mathematics software like Mathematica or Maple.
• Electronic circuit simulators.
• PostScript or TeX viewers (both are Turing complete languages).

In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code. This should give developers the flexibility they want, while preserving the security we need. [emphasis mine]

It's a pretty sad to see Apple is falling back on “security” as an excuse for limiting what customers can do with the products that they purchased. This is the same thing Sony did a few months ago when they removed “install other OS” (an advertised feature) from the PlayStation 3. In Sony's case the security issue had to do with their DRM. In other words, it wasn't a customer's security they were concerned for, but their profit's. One has to wonder if Apple has similar motives. An interpreter acts as a sandbox, so un-trusted code execution there is generally not as big a deal as arbitrary native code execution, as might result from a buffer overflow or similar bug in native code. Last I checked, Apple wasn't prohibiting string manipulation in native apps.

Analytics

Like 3.3.1, section 3.3.9, the privacy and analytics section, has also changed for the better. The language that specifically forbade Google's AdMob is gone, meaning developers can decide which advertising platform to use.

Why?

Apple says in their announcement:

We have listened to our developers and taken much of their feedback to heart. Based on their input, today we are making some important changes to our iOS Developer Program license in sections 3.3.1, 3.3.2 and 3.3.9 to relax some restrictions we put in place earlier this year.

Apple clearly didn't anticipate the backlash that would be caused by 3.3.1 when the “originally in Objective-C” clause was added. Not only were developers angered by that rule, but since its addition, people have been looking much more closely at what's in the developer agreement. Apple doesn't want this scrutiny as it brings to light already existing ridiculous rules, like 3.3.2, and makes people more likely to question Apple's motives when new rules are introduced, like 3.3.9. It also made many developers (and tech savvy users) who liked Apple (myself included) re-evaluate whether this was really a company they wanted to purchase products from or develop for.

I think there's also a possibility that the recent changes to 3.3.9 were made in order to avoid legal issues.

Neither of these are really great reasons for Apple to change their behavior. I think Steve Jobs preferred the older set of rules, but it became clear that developers, and potentially even the law, wouldn't stand for them.

To iOS or not to iOS

The current developer agreement is a lot closer in meaning to the pre-iPad developer agreement. Back when the iPad came out I had considered getting one so that I could experiment with developing for iOS. I gave up on that plan when the “originally in Objective-C” rule was added. So now that the rules are pretty much back where they were, am I going to get an iOS device?

Probably not. Apple has lost my trust, and in order to win it back they'll have to do more than just change things back to the way they were. For starters, I'd like to see them make a rule for themselves that the developer agreement will apply not just to third-party developers, but also to Apple's own iOS apps. For existing Apple apps that violate the rules they can then choose to revise the agreement for everyone, fix the app, remove the app. Apple already has an advantage over third-party developers, so for them to impose rules whose only apparent purpose is to strengthen Apple's advantage over third-party developers is reprehensible. I'm looking at you Safari.

Better yet would be to make it possible for people to distribute native iOS apps without going through the App Store. I'd care a lot less about the App Store policies are if there were other ways to get apps on iDevices. I'm fine with this being a setting users need to enable (as it is on Android devices), but requiring that the user "jailbreak" their device to get such basic functionality is not acceptable.