Google Voice App uses private iPhone API’s.. But how?

Thu, Nov 20, 2008

Analysis, News

John Gruber over at Daring Fireball has an interesting article about how the new Google app uses an API function call that is otherwise prohibited for developers to use. The feature in question is the ability to initiate a voice command simply by lifting the phone up to your face via the proximity sensor.

“The voice prompt is never triggered by motion alone, nor by covering the proximity sensor without first having moved the phone. The only way it is triggered is by moving the phone and then triggering the proximity sensor. It’s very clever, and the resulting user experience is very nice.

But here’s the intrigue: There is no public API in the iPhone SDK for using the proximity sensor in this way.”

So what gives? Gruber raises three potential explanations.

1. Apple knew about the private function call and gave Google its blessing

2. Apple had no idea what Google was up to


3. Apple knew about it, but given the recent press about the app, wasn’t in a position to reject it, especially after the extraordinary outcry that followed its rejection of other iPhone applications.

Gruber doesn’t believe that Apple would give Google its express permission for that feature, and even indicates that such a scenario would be a blight against Apple as it would indicate that not all developers have access to the same tools when coding their programs.

While his point makes sense, Google seeking and obtaining special permission from Apple wouldn’t be that surprising. If there was any one company for which Apple would make a special exception, it’d be Google. It’s well known that Google CEO Eric Schmidt sits on Apple’s board of directors, so Google clearly would have a more open channel of communication with Apple than your average developer. Furthermore, Google has helped out Apple in the past by encoding its YouTube videos in H.264 format, which makes them playable on the flash-less iPhone.

Apple’s in no rush to make flash capable iPhones, so the H.264 encoding done by Google is extremely significant. Apple knows how popular YouTube is, and it’s easy to see how important Apple thinks its inclusion with the iPhone is. For starters, YouTube has, from the beginning, had its own application icon on the iPhone homescreen (the only non-Apple app by the way). And second, Apple has touted YouTube streaming as a desirable feature in some of its iPhone commercials. Long story short, Google has helped Apple work around the roadblock that is flash, and Apple helping Google out in return by giving it permission to access otherwise prohibited API function calls isn’t that unthinkable.

Also, Apple’s handling of the SDK in the past indicates that it’s not opposed to playing favorites when it comes to iPhone development. And lastly, read into this however much you want, but Apple’s App Store Pick of The Week is, you guessed it!, Google Mobile.

On a different note, Gruber raises an interesting theory suggesting that Apple allowed the app instead of risking a public backlash should it reject it.

“…the Google Mobile team followed the adage that it’s easier to ask for forgiveness than for permission. If this is the case — if — it might explain why Google started publicizing the voice search feature several days before it actually appeared in the App Store. The publicity from John Markoff’s feature in The New York Times put pressure on Apple to accept the app. If there was any internal debate within Apple about whether to allow this, it might explain why the app took several days longer to appear in the store than Markoff’s story indicated Google expected.”

Check out the full article here. It’s worth a read.


, , , ,

Comments are closed.

eXTReMe Tracker