People are calling foul on Apple and Google due to the use of private iPhone …

Share this story

Tonight, our peeps pointed us to this Daring Fireball post that suggests that Google Mobile got an application by Apple that uses private iPhone APIs. Said peeps asked me whether Google is getting a better deal than most devs, or whether Google just pulled something over on Apple. The answer is, to say the least, complicated.

First of all, Apple is a private company. It can do whatever it wants to stock its App Store shelves however it pleases. There's nothing that says the company must treat Joe Q. Developer the same way it treats Moneybags J. Google. So, Google could be linking to private palooza and it wouldn't be a problem if Apple was cool with it.

Having said that, I wanted to clarify that there are two very different ways that developers use non-standard calls. These are:

Linking to private frameworks. This is the bad, the evil, the Sauron of App Store. Apple offers two sets of frameworks, or libraries that contain linkable routines for developers. There are Public Frameworks, which are fine and dandy to link to, and Private Frameworks, which are not.

That's not to say that developers don't do so. It's really easy to tell whether an application is likely doing the naughty. From the command line, enter the App bundle and grep for "dlopen." This reveals whether the Application makes calls into frameworks that it normally cannot link to at compile time. The dlopen call opens a library during runtime, a feature that's not needed when the library is public.

As you'll see with unpublished APIs, using private APIs can mean that your code may break without notice as Apple updates its libraries. Worse, should your application be found to be using said libraries, it can be kicked out of the App Store without recourse; you will not be able to update that application and resubmit it.

Using unpublished APIs. If linking to private frameworks is unacceptable, unpublished APIs play the role of a minor jaywalking. You might get a ticket, a citation, and a talking to, but you're not going to jail forever. The App Store is absolutely littered with unpublished APIs. I've learned to spot them pretty well. When you see applications doing things that you know they can do but that they're not entirely supposed to be doing, you can lay odds that the developers have gently called unpublished but public routines.

Using unpublished APIs means that your applications can break at any firmware upgrade; Apple does not guarantee that routines will not change the way they stand behind the published APIs. However, developers use these routines for all sorts of good reasons both for items in App Store as well as out. And, often, the routines don't break and have been stable for a long long time. Using them is clearly a risk but it's not crossing the private-public framework bridge.

So what is Google doing?

Surprisingly enough, Google appears to use both dynamic linking and calling unpublished APIs. First, the linking. I unzipped the Google ipa file, which is nothing more than a renamed zip file. I then ran a few diagnostic tests on it and looked for the telltale dlopen. Google failed.

But the question that John Gruber raised was not about linking to private frameworks, but rather whether Google was using UIApplication's unpublished proximityStateChanged: call. This is an unpublished call in a public framework. So I turned to iPhone hacker Drunknbass. It was easy, he told me, to catch those proximity state changes by subclassing UIApplication.

Based on Drunknbass's suggestion, I put together a simple test application, using nothing but the standard SDK Public Frameworks. Once compiled and deployed onto the iPhone, it caught all the proximity update events, exactly as he had promised. Here is the code that I tested:

In the end, it looks like Google decided that it was better to get the job done and provide a richer user experience to the end user than to live according to Apple's exact dictates. Was Apple aware of these shortcuts? Hard to say. But truly the Application is really nifty, assuming you don't speak with a Texas or British accent, and it's a real delight for the end user. Which is, of course, why developers write these things in the first place.