The Airsource Blog

Google using private APIs? Not really...

app-apple

Google recently admitted to breaking the AppStore rules in their iPhone application, which fuelled a growing wave of resentment, prompted by the belief that Google were abusing their position as industry leaders to gain a competitive advantage in the market. The critics claim that a similar application submitted by anyone else would be rejected by Apple and never make it to the AppStore. Why should there be one law for Google, and another for the plebian masses? Shouldn't the Google application be pulled from the AppStore until they abide by the rules, as others have been?

Of course, nothing is ever that clear-cut, particularly where the AppStore is concerned. In the face of it, the SDK agreement is pretty clear. It says, and I quote:

3.3.1 Applications may only use Published APIs in the manner prescribed by Apple and must not use or call any unpublished or private APIs.

However, there's a subtlety here. The technique used by Google does not, as some have claimed, involve calling a private API. It's a public API, but unpublished, meaning that according the SDK, Google should still not be using it. However, by one possible interpretation, Google isn't even using it within. All Google have done is implemented a method like this (based on an article by Erica Sadun at ars technica)

@implementation GoogleApplication
// Override private API
-(void)proximityStateChanged:(BOOL)isOn
{
    // do funky stuff
    [super proximityStateChanged:isOn];
}

What then happens is that when the proximity state changes - i.e. you bring the phone close to your ear - this method gets called, the Google app detects it, and fun stuff happens. Notice that - this method gets called. It's not Google calling the method, it's the iPhone OS calling it, followed by Google then doing something. That's not just a subtle, inconsequential difference. If Apple decide to remove that method in a future iPhone update, then all that will happen is that the Google app will stop switching into voice search mode when you bring it up to your ear. There will be no other ill effects, and the application will continue to work. In terms of "naughtiness" that's not really any worse than what the bizarrely named NaughtyNuts Camera SelfTimer does. They dive down into the view hierarchy, find the appropriate selector to trigger capturing an image - and then call that directly so that they can trigger the camera through a timer. That's getting very very close to calling an unpublished API - but Apple approved it, and presumably did so as a conscious decision because they took ten weeks to do it.

Contrast that with a hypothetical application that directly calls a private or unpublished API. If that API disappears, then the application will crash when you try to use that piece of functionality. The verty worst thing you can do is to link against a private framework - if that framework vanishes, your application won't even start up.

My feeling is that while Google are definitely skating on thin ice, their offence is definitely at the minor end of the scale, and that those people calling for their application to be pulled from the AppStore at over-reacting. You'll note that I have linked to Google's application in several places in this article. That is because I think it is an excellent, innovative application that is good for users and Apple alike. I approve of Google trying to push the limits - because if they don't, who will? Hopefully we will get some clearer guidance from Apple about exactly what is and is not acceptable, and an outcome that is better for developers, better for users, and better for Apple.