Join Rene, Chad, and Precentral.net’s Keith Newman for Apple gaming, profit share, OnLive, private API, Facebook fallout, Verizon attack ads and AT&T strikes back, gPhone cometh, Palm Pixi, and all the news, plus your questions answered! Listen in!
All Articles Tagged private api
A little while ago we posted about Apple’s new use of a static analysis tool to find private API calls and reject the apps that make them. Rather than Storm8 or Unity this time, however, it’s former Facebook developer Joe Hewitt’s pioneering Three20 framework that’s getting caught.
Daring Fireball has some details:
One popular open source framework, Joe Hewitt’s Three20 (linked here on DF back in March), played a bit fast and loose with private APIs, and so now there are numerous developers with apps getting flagged for private API calls made from the Three20 framework. This Google Groups thread [link] covers the problem and the work that’s being done to create a branch of Three20 that’s free of private API calls.
Gruber also links to RogueSheep, whose Postage app has gotten caught via Three20, and has some suggestions to help them help Apple help them avoid getting rejected for unintended private API calls in the future:
Making the static analysis tool available to developers would indeed be helpful. But I suspect it wouldn’t work in terms of game theory. Honest developers could make good use of having access to the tool, to help ensure their projects are free of private API violations. But dishonest developers would use the tool to figure out ways to slip private API calls past the checker. Parrish’s second request, for Apple to run the tool against submissions far sooner in the review process, strikes me as a good and reasonable one.
Us as well.
Speaking of Storm8, Unity-engine code, private API, and Gruber, A recent Twitter exchange between him shows just how seriously all of this is now being taken by the App Store:
Hockenberry: Hearing lots of reports about apps getting rejected due to private API usage. Maybe now you’ll believe me when I say it’s a bad idea…
Gruber: Yup: Apple recently started running apps through a static analysis tool to look for private API calls.
Google set off some of the private API discussion when they implemented them as part of the Google Mobile app (though it’s our understanding those API were later made public). Generally, private or unpublished API are kept that way because Apple (or whichever platform maker is supplying the APIs) hasn’t finished working on them, are planning changes, or is otherwise reserving their use — if 3rd parties implement them anyway, any future OS update can break them and cause problems for end users. Public API, on the other hand, are supported and intended to let developers do their thing without worrying about platform-level changes wrecking their apps.
Following our posts last week concerning the lawsuit against iPhone game developer Storm8 that alleged they used private API’s to violate user privacy by collecting their phone numbers, the developer, Storm8, contacted TiPb with their side of the story:
I just saw your post on the iPhone blog that discusses Storm 8 and the Unity games issue, and I wanted to make sure that you saw the statement that we put out to our users outlining the proactive steps we’ve taken to address concerns so it can inform your coverage. This includes updating the applications in August so that current game versions do not download, store or use iPhone telephone numbers when a game is opened.
They further pointed us to a statement they issued on their community forum.
If this issue concerns you, take a read and let us know what you think.
[Updated: Storm8 didn't use the Unity-engine, but they did allegedly use the private API's that allowed access]
It looks like Apple is using its rejection power for good this time — removing games built on the Unity engine which included private-API calls that could be used to steal private user information like your iPhone’s phone number.
Not all of the rejected/removed games were engaged in privacy violations (or even had the network capability to exploit it), but Apple isn’t taking any chances following the Storm8 lawsuit. Touch Arcade has the details:
The Unity engine currently uses the two private API calls that Storm8 allegedly exploited to steal user data, NSGetEnviron and excserver. Mantas Puida of Unity Technologies explains these two API’s utilized by the Unity engine serve the following functions:
_NSGetEnviron is used by Mono runtime to provide implementation of .NET core API method: Environment.GetEnvironmentVariable().
exc_server is also used by Mono runtime to provide graceful NULL reference exception handling.
The Unity engine, however, has been updated to remove the offending API calls, and the games are being recompiled and resubmitted to the App Store. Hopefully this will keep users’ data safe from unscrupulous developers, while the scrupulous ones continue to turn out great games.
[Touch Arcade via TUAW]
No sooner did Apple flip the switch on Pull My Finger but 14 fart-themed apps have hit the App Store and according to Macrumors, leader of the app pack, iFart Mobile, generated $9198 in one day. I need to quit this blog and go make iDoody, or something (don’t tell Dieter!).
Daring Fireball weighs in on the use of private API’s, disagreeing not only with the practice of using them, but with the people who use and tell others hot to use them. A risky practice to be certain, and one that does endanger the user experience, but I like to think (or hope) developers are adults who will make their own informed decisions and take personal responsibility for those decisions, not try to lay blame on code samples or books.
Lastly, we have a rant sent in from PHARTGAMES developer Perry Hart who’s more than a littler frustrated with the continued delays and absolute opacity of Apple’s approval process:
I submitted ZombieMangle over a week ago now, Which was what i though would be a perfect time to release just before christmas. However, A few days after submission apple sends me an email stating that they require “Unexpected Additional Time For Review” with no reason whatsoever for the delay. So I do a search for any other developers who have received this email, and it appears there’s ALOT of them. What this email basically means is that your application has joined a queue which never gets looked at and your app wont be approved, or rejected depending on apples discression for months. One developer has been on the queue for three months, and received absolutely no information about what was wrong.
Emails to support were ignored, phone calls to support were outsourced and scripted, and complaints in the official forums have gotten boiler plate from the mods. Hart’s conclusion:
I think it’s time that all developers and potential developers know that they are working with amateurs.
Did Apple underestimate just how popular the App Store would be? Were they unprepared? And is their newness to the market — the newness OF the market — overwhelming them a degree such that they simply cannot cope? Or is this just Apple being Apple again, saying nothing and leaving people to increasingly frustrated assumptions?
