Ever since the App Store launched and the first app developer complained publicly about having his app rejected, Apple’s received a lot of criticism about how it’s run the App Store. Developers have been angry that rejections occur without clear reasoning and are impossible to appeal.
Recently, more developers got up in arms about a change to Apple’s developer guidelines that banned all app development outside of Apple’s Xcode system, shutting out not just Adobe’s Flash, but other tools such as RealBASIC and Runtime Revolution, and throwing into question the status of many apps that use scripting languages as a part of their construction.
In recent months it’s been clear that Apple has been stung by the criticism – or at least, is aware of the bad publicity it’s been getting for its App Store policies. At several public events, Steve Jobs has gone out of his way to explain Apple’s iOS philosophy: that while web-based apps are a completely open playing field, the App Store is a carefully curated environment.
Unsurprisingly, those statements didn’t really satisfy the company’s critics. But the recent announcement that Apple has modified and clarified its app-rejection policies will go a long way toward making developers feel more comfortable about writing apps, as well as taking the wind out of the sails of some of Apple’s App Store critics, including myself.
The decision about development tools is perhaps the most resounding turnabout of the announcement. In April, Apple changed the terms of its developer agreement to ban any app that wasn’t originally written in the C programming language. This happened just as Adobe was readying Flash Packager for iPhone, a tool that lets Flash developers output native iPhone code for submission to the App Store. Essentially, Apple’s move meant that no app designed with Flash Packager would ever be approved for sale.
If you’re wondering what else was going on in April, here’s a reminder: the iPad was released, unsurprisingly without any support for Adobe’s Flash in the web browser. Though Apple hasn’t ever supported Flash on the iOS, the release of the iPad (a more realistic laptop replacement than an iPhone or iPod touch) seemed to explode coverage of Apple’s lack of Flash support. Adobe certainly fanned the flames, portraying itself as a victim while using the coverage to promote its forthcoming Android-based Flash player.
Apple’s amended guidelines occurred against this backdrop, which explains why some members of the media have conflated the two events, leading to many stupid headlines about how Apple has now backtracked when it comes to its ban of Flash. News alert: Flash still doesn’t run on the iOS. Instead, Apple’s amended guidelines allow Flash developers to use Flash Packager to compile native iPhone apps and submit them to the App Store, where they’ll be judged not by the colour of their development environment but the content of their interface.
But this isn’t just about Flash. It’s about other tools that don’t use traditional programming methods. Many game developers use the Lua scripting language for in-app scripting; technically that violates Apple’s previous guidelines, but not the new ones. Google recently generated some buzz with its App Inventor for Android tool, a supposedly easy way to build Android apps. With Apple’s guideline revisions on Thursday, a similar tool could now be built for the iOS. Then there are simplified application-development environments, such as the Hypercard-inspired RunRev Mobile and the BASIC-inspired Real Studio, both of which are now free and clear as iOS development environments.
So while people will make a big deal about the Adobe thing, there are a lot of other development environments out there that could potentially make it much easier for some programmers and even regular people to create iOS apps. Focusing on the Apple-Adobe catfight does not do the story justice.
Why did Apple make this change? My guess is that it has a lot more to do with game developers and even with simplified environments like RunRev than it does with Adobe. I still believe that Apple is concerned that Flash-built apps don’t make good iOS apps, but with the changes the company has made today, it’s saying it will reject bad Flash-built apps because they’re bad, not because they’re built with Flash. I guess maybe Lucy is going to let Charlie Brown kick that football after all.
App review guidelines
If there’s a common complaint I hear from iOS developers, it’s that the rules of App Store acceptance and rejection are mysterious and capricious. There hasn’t appeared to be a rulebook of any sort, when it comes to what’s allowed and what isn’t. Some apps get rejected, others get approved, and nobody really knows why.
Now Apple has taken its first crack at an official rulebook for app review, and it’s a marvellous first step. It gives developers some clear “don’ts”, as well as a few “do’s” to boot. It’s written in a very personal, casual tone (one suspects it was dictated by Steve Jobs or crafted by a very talented ghostwriter) and includes such gems as “If you want to criticize a religion, write a book” and “We don’t need any more Fart apps.” More broadly, it makes the point that Apple has reasons for keeping the App Store closed, and explains why that philosophy exists. You can agree or disagree with that philosophy, but at least now developers have a bit clearer understanding of what it is and how it works.
John Gruber has done a good job of summing up many of the changes, including direct quotes from the document (which is only available to registered Apple developers). I won’t get into details here, but the document truly seems to codify most of what we’ve intuited were Apple’s standards, and added in a few more.
If you’re a developer, clarity is vital. Why invest thousands of dollars (or much more!) in building an app if you’re afraid it will never be approved? The more clarity that what you’re doing is going to be approved, the more likely you’ll be to develop that app. By releasing this document, Apple has done a great job of giving developers clarity.
That said, Apple’s document is also quite clear on the fact that new reasons to reject apps will come along in the future. “This is a living document,” it says, “and new apps presenting new questions may result in new rules at any time.” With any luck, Apple will keep this “living document” up to date, so that developers can be apprised of changes to the standards in a timely fashion. Yes, new rules could appear at any time, so developers don’t have complete clarity – but their view into the process is better than it’s ever been before, and that’s good news.
The review board
Perhaps the most intriguing announcement from Apple is that it’s created a “Review Board” to act as a sort of appeals court for app rejections. Many developers have complained that they feel they have no recourse when their app is rejected. They want to explain why it shouldn’t be rejected, but there’s nowhere to go. Ideally, Apple’s new review board will provide them with a fair hearing and even more clarity about why their app was rejected and what their recourse should be.
Apple’s new guideline document introduces the review board concept and declares, “If you run to the press and trash us, it never helps.” That’s not entirely true, because several times going public with news of a ridiculous rejection has led to the rejection being rescinded. (Consider the reverse rejection of Pulitzer Prize-winning editorial cartoonist Mark Fiore’s app, to name just one example.) But with Apple now providing this new appeals process, developers should be able to get their grievances considered before having to take a final stab at salvation through the court of public opinion. That’s good for Apple, which will suffer fewer black eyes courtesy of press stories about dumb rejections, and it’s probably good for most developers, too.
Will the changes quiet Apple’s critics? Well, that seems unlikely. But the critics that are most important to Apple – iOS app developers themselves – will find Apple’s policy changes and increased disclosure very good news indeed.