The Google Voice stalemate highlights the problems in Apple's iPhone app approval process. Here are some ways Apple can make the process smoother
Anyone who reads my blog, column, or Tweets—or who calls me for work or any other reason—likely knows by now that I have become an avid user of Google Voice. I tap the Web-based call-management service to handle work and personal voice mail, receive audio messages from readers, and even record interviews with sources while on the road.
Fortunately for us smartphone addicts, Google Voice is available as a downloadable app on Research In Motion's BlackBerry. You can also use it on Apple's iPhone via Web browser. But if you want to download it onto the iPhone, you'll need to await the resolution of a controversy that underscores the increasingly thorny relationship between Apple (AAPL) and Google (GOOG), as well as the troublesome process whereby applications get reviewed for use on the iPhone.
To recap, while Apple hasn't formally rejected app for distribution via iTunes, it has raised objections about the potential for some Google Voice features to supplant certain iPhone features. Google Voice's mail offerings compete with Apple's visual voice-mail tool, for instance. It also has a dialer that looks a lot like the traditional phone-dialing screen for the iPhone. Plus, the contract that makes AT&T (T) the sole U.S. iPhone carrier forbids applications that connect Internet calls over the cellular data network. Bottom line: There's enough potential overlap to make Apple and AT&T antsy about giving Google free rein.
the fcc also wants to know what the holdup is
Apple has said it "continues to study" the issue, which I take to be code for "our lawyers are talking things over with their lawyers." The Federal Communications Commission also has said it may take a closer look at whether wireless carriers, in deciding which applications run on their networks, are taking steps that inhibit competition.
Meantime, in moves that smack of inconsistency if not a double standard, Apple has given the green light to other calling applications for the iPhone. Vonage (VG), a provider of Internet calling, has announced that its application has been approved and is going through testing. The Vonage app's features aren't known, but Vonage's service has several aspects similar to those found on Google Voice.
Another app, Line2 from Toktumi, has also been approved recently, and RingCentral, which I reviewed recently, has an iPhone app with many features that are nearly identical to those found on Google Voice.
There are compelling reasons why Apple might want to restrict these applications. Contractual restrictions are one. Users of the iPhone are voracious consumers of data services, and it would be unfortunate if a too-popular Internet calling application overwhelmed AT&T's data network. And Google Voice's free text-messaging feature undercuts AT&T's very profitable texting service.
vague and inconsistent
Why do so many other call-management apps get the green light when Google Voice doesn't? Quite possibly it has something to do with the growing potential rivalry between the two companies. Google, for instance, is spearheading the alliance behind Android, a mobile-phone operating system that competes with Apple's.
But the Google Voice controversy is also indicative of the convoluted nature of Apple's application-approval process. A growing number of software developers have made no secret in the blogosphere that they find the process opaque and unpredictable.
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.