Google, iPhone, and Thinking Like a Programmer
Yesterday, John Gruber declared that Google Mobile uses private iPhone APIs. Since he wrote it, it must be true, which is why TechCrunch picked up on the article this morning. Nevermind the fact that the only evidence offered by Gruber was that “there is no public API in the iPhone SDK for using the proximity sensor in this way.”
The critical mistake Gruber makes is assuming that because there’s no documented method for trivially utilizing the proximity sensor, there must be no possible way to do it. This is a severe lack of imagination.
Programming is an exercise in creative thinking, especially when working within the context of specific platform. There are always things you, the developer, want to do but don’t seem to be able to. This has always been and will always be true. It’s the reason why plenty of desktop Mac apps use private Apple APIs, and it’s the reason why plenty of iPhone apps on the store are using undocumented APIs.
The essential question, then, is can what Google is doing be done without using undocumented APIs on the phone? I think it can. I spent an hour this morning trying to prove it, and came up with this iPhone app.
To be fair, this doesn’t work as well as Google’s version, or exactly the same way. For one, I didn’t bother to program in the proximity requirement for the trigger. This is well documented, so anyone could easily add it to this project. The other way in which my method underperforms Google’s is that the phone actually has to touch your ear before it will trigger. Google’s just needs to come close to your ear. But, the code does use the proximity sensor, and it only uses the available API method for that sensor, which gives you the ability to turn it on and off. The code uses no undocumented APIs.
How does it work? As I mentioned, it requires you actually touch the phone to your ear. Once you do, the application receives a touchBegan event, and turns on the proximity sensor. It also makes a note that the app is in the middle of a touch sequence, and finally it fires off a timer which makes this trick work. Once the proximity sensor is turned on, it is immediately engaged because the phone is so close to your face. When the proximity sensor is engaged Cocoa turns off the touch sensor, but it doesn’t send a touchEnded message to the application. Thanks to that timer we fired, we can poll for the current number of touches on the screen. If it drops to zero, but we never saw the touchEnded message, we know we’ve triggered the proximity sensor. The project I’ve included will turn the screen yellow and play a little sound, just like the Google application. Here’s all the relevant code:
{
[self setBackgroundColor:[UIColor redColor]];
[UIApplication sharedApplication].proximitySensingEnabled = YES;
_inLiveTouch = YES;
[self performSelector:@selector(checkTouches:) withObject:event afterDelay:0];
}
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
[self setBackgroundColor:[UIColor greenColor]];
_inLiveTouch = NO;
[UIApplication sharedApplication].proximitySensingEnabled = NO;
}
- (void)checkTouches:(UIEvent *)event
{
if (_inLiveTouch && [[event allTouches] count] == 0)
{
[self setBackgroundColor:[UIColor yellowColor]];
AudioServicesPlaySystemSound(_sound);
return;
}
if (_inLiveTouch)
[self performSelector:@selector(checkTouches:) withObject:event afterDelay:0.5];
}
An hour of programming, and three methods get us something relatively close to what Google is doing. I’m far from an expert in the iPhone SDK, but it only took a little bit of imagination to come up with this idea. Google has perhaps a dozen or more employees working full time on the iPhone. It’s not much of a leap to believe they figured out an even smarter trick than mine to accomplish what they wanted to do. Gruber did mention later that at least one other app is doing something similar without using the proximity sensor, but was quick to point out how inferior it was to the proximity based approach.
Now, as it turns out, Google probably is using private APIs to do what they’re doing. Erica Sadun, over at Ars Technica, made a more convincing case.
The ultimate question then, is does it matter? The reality of the situation is that there are a lot of apps doing this that have already shipped. It isn’t just Google, and it isn’t just big companies, it’s everybody. Either Apple knows this and isn’t doing anything about it, or they don’t know. Either way points to indifference. If they know, it’s obvious how not taking action is indifferent towards things, but what about if they don’t know. In that case, it means the review process they’ve built is not designed to catch these cases. To be sure, the dynamic nature of Objective-C would make it difficult to catch all instances of runtime tomfoolery, but it’s not impossible to do so, nor would it be particularly burdensome to catch most of the cases. As it currently works, I believe they are only checking to see which frameworks you link against statically, and denying anyone who includes private frameworks in that list.
Even if Apple was deeply concerned that people were using undocumented APIs, would it be a big deal if Google was granted an exception? Gruber thinks so:
Third-party iPhone development is purportedly a level playing field. If regular developers are forced to play by the rules, but Google is allowed to use private APIs just because they’re Google, the system is rigged.
Rigged? Who said the iPhone SDK was a level playing field in the first place? Apple has never been a company that stands up for level playing fields, nor should they have to be. Every business makes business deals, partnerships, exclusive rights agreements — this is common business practice, at Apple, Google, and everywhere else in the business world. Why should the iPhone be any different? If you had billions of dollars in the bank, Apple would talk to you too.
This isn’t only realistic, it’s also reasonable. One of the reasons to prevent people from using undocumented APIs is not wanting applications to break between upgrades. If Apple knows every single application that will break, because it has an arrangement with the developer, it can make sure to correct the problem in advance. This obviously doesn’t scale to every developer, but it makes perfect sense to do so on a limited case by case basis. In fact, this is how Apple already behaves in the desktop world. Wil Shipley gets his bugs fixed faster than Joe the Indy Developer. Why? Because his app is popular, and because he has connections at Apple.
TechCrunch claimed in their article this morning that “Apple wouldn’t allow Google to use an unsupported call. It’s not in their DNA.” If anything, Apple is more likely to help Google than any other company. After all, Google provided Apple with a special version of maps for the iPhone application, and now the company refuses to license Google Maps to any other iPhone developer, even the ones willing to pay the outrageous sums of money a license costs. Google gave Apple a virtual maps monopoly for the iPhone, the least Apple can do is let them use an undocumented method here and there.
November 20th, 2008 at 12:39 pm
Great post man.
November 20th, 2008 at 10:10 pm
[...] Ross Boucher, founder of 280 North, came back with an interesting blog post called Google, iPhone, and Thinking Like a Programmer where he came up with an alternative technique to detect proximity to the iPhone - with code (and even a full app) included. Despite his clever workaround, Boucher thinks that if Google and some other vendors have been given special dispensation to use special iPhone features, it’s a reasonable tradeoff. [...]
November 21st, 2008 at 6:49 am
You say: “Now, as it turns out, Google probably is using private APIs to do what they’re doing.” Well, it’s a bit more than “probably,” according to Gruber: “a class dump of the application binary would show that Google Mobile does in fact implement proximityStateChanged.”