Google's Mobile App Breaks iPhone SDK Rules
While Google's new version of its Mobile App for the iPhone has been warmly received, it appears, according to a report, that it uses an undocumented API, which would be a no-no in Apple's book. However, the use of the API results in a great user experience, so one has to wonder: did Apple let the app into the App Store because it was great, because Google is so powerful, because the NY Times pimped the app, or because Apple just missed it?
As you probably know, the new version of the app uses voice recognition: no more typing in search queries unless you speak with a British accent, and the app is smart enough to realize when you are raising the phone to your ear to speak, and prompt you.
But according to Daring Fireball, Google used an undocumented API to detect when the iPhone is approaching your head, via the proximity sensor. Normally, when you make a phone call on the iPhone, that sensor detects when the phone is next to your head, and turns the screen off to prevent you from hanging up the phone by touching it with your ear or face. But, if you follow the rules, that proximity sensor is only supposed to be used to turn on / off the screen, nothing else.
Use of the sensor for Google's reasons is off-limits, and technically impossible using public APIs. So Google used an undocumented API to do its work.
Obviously one bad thing about using a private API is that it can be changed at any time. Another is that, seeing as how Apple is pretty rigorous about what it lets into its App Store, it could get your app booted. But this app wasn't. Why?
The theories are obvious:
On the other hand, if Apple did miss it, might they pull the app? Who knows. Probably not, because of 1) above, which in and of itself creates a uneven playing field.
As you probably know, the new version of the app uses voice recognition: no more typing in search queries unless you speak with a British accent, and the app is smart enough to realize when you are raising the phone to your ear to speak, and prompt you.
But according to Daring Fireball, Google used an undocumented API to detect when the iPhone is approaching your head, via the proximity sensor. Normally, when you make a phone call on the iPhone, that sensor detects when the phone is next to your head, and turns the screen off to prevent you from hanging up the phone by touching it with your ear or face. But, if you follow the rules, that proximity sensor is only supposed to be used to turn on / off the screen, nothing else.
Use of the sensor for Google's reasons is off-limits, and technically impossible using public APIs. So Google used an undocumented API to do its work.
Obviously one bad thing about using a private API is that it can be changed at any time. Another is that, seeing as how Apple is pretty rigorous about what it lets into its App Store, it could get your app booted. But this app wasn't. Why?
The theories are obvious:
- The New York Times article announcing --- and praising --- it put so much pressure on Apple they approved it.
- Apple didn't notice the user of the undocumented API.
- Google's connections alone, sans the NY Times article, were enough to pressure Apple into approving it.
- Google made a deal with Apple.
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.We've already seen the App Store approve, then ban, then reapprove, and ban again apps before, so the process isn't perfect. But errors are OK; treating some developers differently and not having a level playing field is not. So let's hope they just missed this.
On the other hand, if Apple did miss it, might they pull the app? Who knows. Probably not, because of 1) above, which in and of itself creates a uneven playing field.
