How to Fix the App Store

(page 2 of 2)

Some go so far as to say it's not worth the risk of committing resources to develop for the iPhone and risk a rejection by Apple for vague and often inconsistent reasons. A software developer who asked not to be named but is known for a popular series of Mac applications tried developing for the iPhone but was turned off by the approval process. "It's just not worth the trouble," he says.

maddeningly unhelpful feedback

Apple rightfully boasts that it has approved some 65,000 applications and that 95% of apps are approved within 14 days of submission. But the 5% of developers whose apps are rejected get precious little information about why. There are accounts on various blogs about maddening conversations with Apple employees who say nothing useful about what needs to be fixed in a rejected app.

Here's an example: Mark Jardine has blogged about how his iPhone app ConvertBots, which does quick conversions for currency and measurements and other things, was rejected by Apple. The reason: One of icons in the program—a graphical element meant to visually describe what a feature does—is a tiny line drawing depicting a clock. It's too similar to an Apple icon found elsewhere on the iPhone. Despite the fact that the two clocks appear in vastly different contexts that would confuse no one, Apple argued that users might become confused. "It does worry me that our product has to be held back for another 1-2 weeks for something so trivial," Jardine wrote.

What's missing from Apple are clear and unambiguous guidelines for building iPhone applications. Of course, it's difficult to envision all the various permutations of applications and thus difficult to lay down rules that will apply in all circumstances. But surely Apple can come up with some inviolable rules for building iPhone apps.

Next, Apple says it has 40 full-time apps reviewers and that all apps are reviewed by at least two of these reviewers. Fine. Adding more reviewers would certainly help. And rather than simply adding more, it should assemble a team of senior reviewers whose sole task would be to deal with developers whose apps have been rejected and help them fix the problems that caused the rejections. We'll call them "app rejections specialsts." If the rejection rate continues to run at about 5% of applications submitted, then 15 or 20 employees should be able to handle job easily.

prevent leaks with nondisclosure pacts

The next thing Apple should do is dispense with its less-than-helpful communications to developers whose apps have been rejected. Part of the lousy communication, I'm told by developers who have gone through the process, is that while the app reviewer knows exactly what the problem is, they're forbidden to convey that info. It's not clear why, but maybe Apple is afraid that some sensitive part of the process will leak.

The answer: Have all communications regarding app rejections covered by non-disclosure agreements (NDAs). Apple has been criticized for requiring developers to sign overzealous NDAs in the past. This one would be specific and limited, meant to give developers a means to communicate clearly with Apple and vice-versa, with no need for either party to mince words.

Finally, make this entire endeavor a two-way process. Give developers a channel through which they can offer feedback to Apple on what's working and what's not working in developer process. At the next Worldwide Developers Conference, convene an iPhone Developers Panel, where instead of telling developers what they need to know, Apple can listen to what they have to say. Let the developers vent their frustrations, and where practical, improve the process based on these concerns.

But before all this? Get Google Voice on the App store.

Hesseldahl is a reporter for BusinessWeek.com.

Business Exchange

Track and share business topics across the Web.