Landon Fuller's Peeps application was rejected from the App Store for supposedly breaking rules that Google was allowed to violate.
(Credit: Plausible Labs)
Apple has rejected an iPhone application that supposedly uses off-limits technology just like Google's mobile application--only the developer swears it's not true.
Landon Fuller, who developed a photo contact management system called Peeps, said on his blog that Apple had rejected Peeps from the App Store because, "Peeps cannot be posted to the App Store due to the usage of a non-public API. Usage of non-public APIs, as outlined in the iPhone SDK Agreement section 3.3.1, is prohibited." The thing is, Fuller insists that Peeps does not use any programming tools but the public ones Apple exposes to developers as part of the iPhone SDK, saying "the last thing I would do is deliver time-bomb code to a paying customer." (Thanks to Daring Fireball for the link.)
APIs are tools that applications use to exploit parts of a computer's operating system. Operating system developers usually label some proportion of the various APIs in the OS as "public," meaning they'll support the use of those APIs well into the future to ensure applications will not break with future OS updates.
There are usually lots of other APIs lying around that the OS vendor doesn't make public, but that developers can see if they poke around a little bit. Google used such an API to trigger a voice prompt from the iPhone's proximity sensor in its Google Mobile application, which the company admitted was against the rules of the App Store.
Fuller seems to believe this is all just a misunderstanding, since his application looks an awful lot like Apple's Cover Flow feature but doesn't actually use the same implementation Apple does to display album covers in iTunes. Maybe he just needs a bigger market cap: Google Mobile is still available on the App Store, and a Google representative said he had no updates on whether Apple had ordered any changes to Google Mobile or if Google planned to make any changes on its own. An Apple representative did not return a call seeking comment, but Apple representatives have never returned any calls seeking comment about the App Store approval process.
Sometimes it really does seem that getting your iPhone application approved or rejected for the App Store comes down to whether or not you draw Inspector No. 1 or Inspector No. 2 that day.
Google acknowledged breaking the official rules of Apple's iPhone software development kit when it created the latest version of the Google Mobile application for the iPhone, but denied a more serious charge.
A Google spokesman confirmed Tuesday that Google Mobile uses undocumented APIs (application programming interfaces) in order to use the iPhone's proximity sensor to prompt a verbal search. iPhone developers were only supposed to use the APIs that Apple published in its SDK when they create their applications under the terms of that agreement.
Google has denied, however, a more serious charge that it was linking to private or dynamic frameworks in the Google Mobile application. That's considered a big no-no in the development community.
The problem with using undocumented APIs is that your application code could break in the future as Apple updates its software, but a lot of developers appear to have taken that risk in order to deliver a cool feature, such as Google's verbal search prompt.
Under the original terms of the SDK, however, applications using such techniques were not supposed to make it through to the App Store. As a result, other developers who played strictly by the SDK rules would not have felt it possible to create an application that duplicated Google's voice prompt using the proximity sensor, whereas those who had the resources to quickly rewrite anything that ran afoul of the App Store gatekeepers could push ahead and test Apple's limits.
Given Apple's uneven process for approving applications onto the App Store, the question has continued to come up as to whether Apple's ability to keep up with the flood of applications into the App Store has been stretched to the breaking point. It's not clear whether Apple knew Google was using the undocumented APIs when it approved Google Mobile, or whether it simply missed that code.
Google might be forced to rewrite the code for Google Mobile or change the way the application uses the proximity sensor if Apple decides to enforce the terms of the SDK. A number of Apple representatives appeared to be on vacation this week, and so requests for comment are not likely to be immediately returned.
Google Mobile lets you search the Web using your voice in a way that is technically off-limits to iPhone developers, according to a report.
(Credit: Apple (App Store))If Google wasn't Google, there's a fair chance that its new mobile application for the iPhone wouldn't be allowed in the App Store.
That's because Google Mobile is tapping into iPhone technology that is supposed to be off-limits to third-party developers, according to research done by Daring Fireball's John Gruber and Ars Technica's Erica Sadun.
The latest version of the search giant's mobile iPhone application has been well received, but it might be impossible to duplicate or improve upon the application, unless developers are willing to break Apple's rules for iPhone applications.
When you make a phone call on the iPhone, a proximity sensor detects when the phone is right next to your head, and it turns the screen off to prevent you from inadvertently hanging up the phone with your face.
Google's application also uses the proximity sensor to detect when the phone approaches your head. That is is kosher under the iPhone application guidelines given to developers, as long as it is used solely for that on-off functionality. But Google uses it to let you search the Web with your voice, just as if you were making a phone call.
Google's application both activates the proximity sensor and delivers an audible prompt to voice your search terms, and the only way it can do this is by using an API that isn't part of the public list Apple has put together for developers, according to Gruber. Think of an API as helpful code that an operating system shares with an application to make it easier for that application to get things done.
Apple lets developers create applications that access some parts of the iPhone--such as the accelerometer for spacial controls and GPS for navigation--but it considers other parts of the phone's technology off-limits to anyone but Apple. Nonetheless, Sadun observes that there are tons of applications within the App Store that do what Google has done with its mobile application: take advantage of technology that is accessible, such as the proximity sensor, but go beyond the basic things you're allowed to do with that technology by using "unpublished" APIs that exist but are not publicized by Apple.
Sadun compares this to jaywalking: Sure, you might get hit by a bus, but you probably won't, if you're careful. And the cops aren't exactly going to launch a three-state manhunt for you, if you make it across the street.
But further research done by Sadun shows that Google is actually going beyond its use of unpublished APIs in the Google Mobile application to call on so-called "private" frameworks that are supposed to be strictly off-limits to anyone but Apple, an offense that can result in banishment from the App Store. A framework is a more general set of building blocks for an application that requires more custom development work than an API.
Of course, Google Mobile can still be found on the App Store. A Google representative said the company had no immediate comment on the reports, and an Apple representative did not return a call seeking comment.
So what can we conclude?
One, as we already knew, the App Store approval process doesn't make sense: applications that don't violate any public guidelines are rejected for nebulous reasons, while applications that violate the rules sail through.
Last week, Apple rejected an update to an application called CastCatcher that had already been approved three times, and then this week, it approved the update without requiring any substantial changes, according to the developer.
Two, if you play by the rules of the developer program, your application won't be able to compete against those created by developers who violate the rules and get away with it because either Apple missed the violation or because they are politically connected industry titans.
"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," Gruber wrote.
Three, since Apple is under no obligation to support applications that make use of unpublished APIs or private frameworks, future firmware updates or operating-system releases could break those applications.
iPhone applications are streaming into Apple; CEO Steve Jobs told financial analysts last month that he's never seen anything like it in his career. So it's not hard to believe that Apple is simply overwhelmed and does not have the manpower to comb through each application to make sure that it is toeing the line. However, that was the main selling point for Apple's strategy to completely control iPhone application distribution; that it would be able to prevent poorly written or insecure applications from poisoning the iPhone by vetting every single application.
Google, of course, is a little different than your average iPhone developer. CEO Eric Schmidt sits on Apple's board of directors, and the company has received favorable treatment before from Apple with regards to the iPhone, such as Apple's decision to grant YouTube and Google Maps prominent placement on the home screen of the iPhone before the device was officially open to third-party developers.
Based on most accounts, Google Mobile is an excellent iPhone application. But would a similar application created by an average developer have been allowed to make it onto the App Store?
It seems that Apple has been rejecting applications that compete with its future plans. Might the company also be extending that courtesy to favored partners?
A new report surfaced Tuesday that Google's hell-bent on making its own mobile phone operating system, adding to the rumors that a prototype could be released soon.
Engadget is reporting that we could hear official news from Google about its plans for a handset-optimized operating system in September. The newest report falls into the more likely category--at least in my opinion--that Google would be working with existing phone companies on a device that uses a Google-developed operating system and suite of mobile applications, not building its own hardware.
The appeal for Google is simple: mobile phone growth is exploding, and it's the future of computing. It's not a perfect analogy, but it's almost like the early days of the PC industry when Microsoft hadn't yet come to dominate the industry and there were several different ideas for software to run those new-fangled PCs.
Google's OS is supposedly based on Linux, and designed to work well with its existing applications. If the rumors are true, Google will find itself in new ground competing against Microsoft, Palm, Symbian and its good buddy Apple.
- prev
- 1
- next





