Google Mobile for iPhone breaks App Store rules

If Google wasn't Google, there's a fair chance that its new mobile application for the iPhone wouldn't be allowed in the App Store.

That's because Google Mobile is tapping into iPhone technology that is supposed to be off-limits to third-party developers, according to research done by Daring Fireball's John Gruber and Ars Technica's Erica Sadun.

The latest version of the search giant's mobile iPhone application has been well received, but it might be impossible to duplicate or improve upon the application, unless developers are willing to break Apple's rules for iPhone applications.

When you make a phone call on the iPhone, a proximity sensor detects when the phone is right next to your head, and it turns the screen off to prevent you from inadvertently hanging up the phone with your face.

Google's application also uses the proximity sensor to detect when the phone approaches your head. That is is kosher under the iPhone application guidelines given to developers, as long as it is used solely for that on-off functionality. But Google uses it to let you search the Web with your voice, just as if you were making a phone call.

Google's application both activates the proximity sensor and delivers an audible prompt to voice your search terms, and the only way it can do this is by using an API that isn't part of the public list Apple has put together for developers, according to Gruber. Think of an API as helpful code that an operating system shares with an application to make it easier for that application to get things done.

Apple lets developers create applications that access some parts of the iPhone--such as the accelerometer for spacial controls and GPS for navigation--but it considers other parts of the phone's technology off-limits to anyone but Apple. Nonetheless, Sadun observes that there are tons of applications within the App Store that do what Google has done with its mobile application: take advantage of technology that is accessible, such as the proximity sensor, but go beyond the basic things you're allowed to do with that technology by using "unpublished" APIs that exist but are not publicized by Apple.

Sadun compares this to jaywalking: Sure, you might get hit by a bus, but you probably won't, if you're careful. And the cops aren't exactly going to launch a three-state manhunt for you, if you make it across the street.

But further research done by Sadun shows that Google is actually going beyond its use of unpublished APIs in the Google Mobile application to call on so-called "private" frameworks that are supposed to be strictly off-limits to anyone but Apple, an offense that can result in banishment from the App Store. A framework is a more general set of building blocks for an application that requires more custom development work than an API.

Of course, Google Mobile can still be found on the App Store. A Google representative said the company had no immediate comment on the reports, and an Apple representative did not return a call seeking comment.

So what can we conclude?

One, as we already knew, the App Store approval process doesn't make sense: applications that don't violate any public guidelines are rejected for nebulous reasons, while applications that violate the rules sail through.

Last week, Apple rejected an update to an application called CastCatcher that had already been approved three times, and then this week, it approved the update without requiring any substantial changes, according to the developer.

Two, if you play by the rules of the developer program, your application won't be able to compete against those created by developers who violate the rules and get away with it because either Apple missed the violation or because they are politically connected industry titans.

"If regular developers are forced to play by the rules, but Google is allowed to use private APIs, just because they're Google, the system is rigged," Gruber wrote.

Three, since Apple is under no obligation to support applications that make use of unpublished APIs or private frameworks, future firmware updates or operating-system releases could break those applications.

iPhone applications are streaming into Apple; CEO Steve Jobs told financial analysts last month that he's never seen anything like it in his career. So it's not hard to believe that Apple is simply overwhelmed and does not have the manpower to comb through each application to make sure that it is toeing the line. However, that was the main selling point for Apple's strategy to completely control iPhone application distribution; that it would be able to prevent poorly written or insecure applications from poisoning the iPhone by vetting every single application.

Google, of course, is a little different than your average iPhone developer. CEO Eric Schmidt sits on Apple's board of directors, and the company has received favorable treatment before from Apple with regards to the iPhone, such as Apple's decision to grant YouTube and Google Maps prominent placement on the home screen of the iPhone before the device was officially open to third-party developers.

Based on most accounts, Google Mobile is an excellent iPhone application. But would a similar application created by an average developer have been allowed to make it onto the App Store?

It seems that Apple has been rejecting applications that compete with its future plans. Might the company also be extending that courtesy to favored partners?