John Gruber of Daring Fireball had an interesting find on Google’s latest (and much-publicized) update to its mobile iPhone application. Much to Google’s credits, the update features a very clever interaction design for the voice search feature. Users can either manually tap the on-screen button to initiate a voice search, or, as illustrated in the publicity videos, initiate a voice search by simply lifting the iPhone to the ear and speaking the search terms.
Now, we all know that lifting the iPhone towards to the ear actually triggers a proximity sensor which is built next to the speaker at the top of the iPhone. What we do not know is, there are actually no APIs available to use the proximity sensor in such a way.
An API, which is the abbreviation of Application Programming Interface, is a set of routines, protocols and tools for building software applications. Most APIs are provided by the operating environment manufacturer. A good API makes it easier to develop programs for the target operating environment by providing all the necessary building blocks. A programmer then simply puts these blocks together to form the software application.
The iPhone SDK’s API only allows applications to turn the proximity sensor on and off. Majority of the applications available on the App Store leaves the proximity sensor turned off by default. Switching the proximity sensor on would turn the screen off and disable the touch input, useful when holding the phone to the ear especially during phone calls.
Gruber summarized that:
If you use something like the command-line strings utility to examine the UIKit framework, you can see that there’s an undocumented (and therefore private to Apple) method named proximityStateChanged. And if one were to strip the FairPlay DRM from the current Google Mobile application binary — which, of course, you wouldn’t do, because you’re not supposed to strip FairPlay DRM, but I’m just saying if one were to do this — a class dump of the application binary would show that Google Mobile does in fact implement proximityStateChanged.
Now, the big question(s) here are:
- did Apple failed to notice that the application is using a private API call
- they (Apple) knew about it but approved it anyway, or
- Google leveraged on their partnership with Apple, asked for it, and was given permission to do so by Apple
I’d personally hope that the reason is as #1 above, but that could potentially render the application useless in future firmware updates should Apple do away with the said APIs. #2 and #3 purportedly shows that Google is not playing on the same level as the other developers out there.
UPDATE: the iPhone Blog has an update on the find. Ars Technica investigated and found out that Google did not only use private and unpublicized APIs, they’d also linked to Private Frameworks, which is a further violation of the SDK guidelines. Now, what would Apple do, considering the state that things are now wide open in the public?
Related Posts
