In an unusual move, Apple last week released a statement announcing changes to the iOS Developer Program License Agreement that relax previous restrictions, possibly with the goal of reducing exposure to antitrust scrutiny.
Simultaneously, Apple announced that it would be releasing the App Store Review Guidelines to developers and creating an App Review Board to which complaints about rejections could be addressed. It’s none too soon – I’m sure that 99.99 percent of rejections have been for good technical reasons, but the remaining controversial rejections have been embarrassing for Apple and the entire Apple community. Let’s look at the App Store issues first.
App Store Review Guidelines — Honestly, the App Store Review Guidelines sound pretty reasonable on the whole, while still being sufficiently vague as to allow Apple to do anything it wants. However, they are written in plain English, and Apple clearly differentiates between apps and books or songs, neither of which the company curates in the iTunes Store. If nothing else, it’s nice to have that fact stated officially as well.
Apart from the many specific guidelines that will primarily interest developers, Apple lays out some broad themes that boil down to:
- Since lots of kids are downloading apps and many parents don’t set parental controls, Apple will pay closer attention to apps that might be inappropriate for kids.
- Apple is looking for apps that do something useful or provide lasting entertainment. The money quote: “We don’t need any more fart apps.” Thank goodness!
Put some effort into it. Apple – and serious developers – don’t want the App Store to be overrun with amateurish apps.
Apple will reject apps for any content they believe is “over the line,” where “the line” is defined with a quote from the late Supreme Court Justice Potter Stewart, referring to a no-longer-used definition of obscenity: “I know it when I see it.”
The guidelines are constantly evolving to address new situations.
Finally, you can appeal to the App Review Board if your app is rejected, but Apple goes on to say, “If you run to the press and trash us, it never helps.”
I hope that last bit proves true in the future, because in the past, it repeatedly appeared that the only reason that bans were lifted from certain apps was because of public outcry, and media coverage that made that public outcry possible. (See the Wikipedia entry on censorship in the App Store for links to coverage). Would Apple have reversed those decisions on its own? Doesn’t seem likely.
Shining a light on situations like this is exactly what the press should be doing – the public does not have a right to know everything about Steve Jobs’s private life, but knowing that Apple is rejecting political satire from the App Store is absolutely in the public interest.
App Development Language Restrictions Lifted — Let’s look next at the changes to the iOS Developer License Agreement. First, a clause stating:
has been removed entirely. This clause was added a few months ago to prevent the use of cross-compilers such as Adobe’s Flash-to-iPhone compiler (see “iPhone Developer Agreement Change Bans Flash-to-iPhone Compiler,” 9 April 2010). The ostensible reason for this was to reduce the likelihood of security vulnerabilities and to avoid the poor interface quality of cross-platform apps.
Keep in mind that this all happened during Apple’s dustup with Adobe over Flash, and while Steve Jobs claimed Adobe started it (see “Steve Jobs Answers (Nearly) All at D8,” 11 June 2010), there’s no question that emotions were running high and could have resulted in this blanket ban that still managed to target Adobe’s Flash-to-iPhone compiler.
But why the change, and why now? According to a brief New York Post article, Apple’s ban of cross-compilers generated antitrust scrutiny from the U.S. Federal Trade Commission and from European regulators. While all parties have refused to comment, if there is truth to the Post’s report, Apple’s backpedaling would make sense in an antitrust context.
Interpreted Code Allowed in Apps — Next, a clause that previously restricted apps from installing or launching other executable code by any means has been recast. Previously, it banned plug-in architectures, calling other frameworks, using other APIs, and downloading or using interpreted code other than code that was provided or approved by Apple.
That clause continues to ban the downloading and installation of executable code, but explicitly allows interpreted code as long as all scripts, code, and interpreters are packaged within the app and not downloaded. An exception is carved out for code downloaded and run by Apple’s built-in WebKit framework.
Again, this change would seem to be designed to allow developers to create and use their own interpreted languages within apps, as long as they aren’t downloaded, which would open up a gaping security hole. And again, along with the technical aspects of the decision, it may also make sense in the context of an antitrust investigation.
User Data Collection Restrictions Simplified — Finally, a clause that was previously quite specific about the situations in which user or device data could be collected has been greatly simplified. Previously, this clause carefully laid out when and how data could be collected (basically, to provide a service or function that was directly relevant to using the app, or for advertising, but then only a subset of data designated by Apple as available for advertising purposes). Now, it simply says that apps cannot collect user or device data without user consent, it must be for enhancing the app or serving ads, and that apps cannot use analytics software to collect and send device data to a third party.
According to an earlier New York Post article, there could also be antitrust scrutiny associated with Apple’s iAd service, and this change to the iOS Developer License Agreement can easily be construed as loosening restrictions on third-party advertising services. In fact, Google has already said as much.