Julian Lepinski

So a few weeks ago everyone was aflutter about the new Google iPhone app. Not only was is pretty damn great (my first voice search, “pizza near me,” was one of those moments where the world seems to change forever), but Google was apparently doing something dirty.

See, for maximum slickness the Google app would automatically trigger voice detection when your phone was held in close proximity to your face. (In academia we’d use this as an example of a multimodal interface, but that’s neither here nor there.) The Google app was using the same API as the iPhone uses to turn off the display when you’re holding your phone to your face during a phone call. So what’s wrong with that?

Well, like many useful APIs on the iPhone, the proximity sensor was only accessible through a private, undocumented API. 3rd party apps can access these APIs, but they’re not supposed to. In fact, many people were operating under the belief that using an undocumented API would be grounds for an app rejection. (Apparently not!)

What was extra strange about this situation was that Google almost immediately admitted to using the private API. And then… nothing. The app never got pulled, and everybody continued to receive directions to nearby pizza. At the time some opined that this was a case of Google’s clout winning over, but I don’t think that was entirely the case. All evidence points to Google submitting much in the same way as any other developer has to — they certainly didn’t skip the process or jump the queue. (In fact, Google was left somewhat red-faced as they excitedly announced the launch of their app only to have it not launch on time. So goes the opaque app review process Google; perhaps you and aren’t so different after all.)

Fast forward to today and there is some other API-related news — this time considerably more bitter. Apparently Apple has just rejected the Peeps app for using the unpublished/private Cover Flow APIs in their app. The dirty here is that Peeps isn’t using cover flow at all — they recreated it themselves without touching the API.

And that’s potentially the most important lesson to take away from this whole mess: Apple has no way to formally check whether you are using private APIs or not. This is not something Apple probably wants you to know. Obviously if your app does something super-egregious, it can be expected that someone will pick up on it during the review process, but there are numerous apps that are already flying under the radar. (Case in point: the original launch version of Phanfare used very-disallowed direct access to the camera so they wouldn’t have to go through the UIImagePicker, which is a lumbering nightmare. The app was approved, then pulled some time later when someone at Apple finally clued in.)

But how does Google figure in to this? Well, for one thing Apple certainly knows that Google is using a private API. For all we know the app may be staying up simply because of the clout that Google has, but I’m not sure that’s the whole story. You see, Apple has more than one reason to keep some APIs private. Sure, they don’t want your app secretly grabbing frames from someone’s camera and sending them out over the interblag, that’s obvious, but considering the half-finished state of the iPhone SDK release I think it’s likely that Apple left some APIs private/undocumented simply to shorten their to-do list before release. There doesn’t seem to be much reason for Apple to keep the proximity sensor private until you realize that not opening it up means one less API to maintain, one less API to document and one less API that has to be kept consistent and compatible between firmware updates.

Knowing this, I’d expect that Apple may turn a blind eye to some API access violations because, really, they don’t care if you know what the proximity sensor knows. (I’m not sure if there are any other apps that make obvious use of the sensor, but I have half a mind to throw one together and submit to Apple to test my thesis.)

And, after all this headache, it seems that Apple can’t prevent some developer from spying on you through your camera… that’s somewhat troubling.

* * * Julian is one of the three guys who make Pano for iPhone. We don’t use any private APIs, Apple. Please don’t kick us out. * * *