Marco Arment raised a flag on the iPad App Store field today and called foul over Apple using private APIs in their first-party iBooks app.

Private APIs are meant to be exclusive to Apple’s OS and built-in apps (like Safari, Mail, iPod, etc.) because they’re experimental, transitional, or otherwise not something that developers should count on being there in the same form in the next OS update. They’re still works in progress. Public APIs on the other hand are an agreement between Apple and developers that they can be used to build apps safely and confidently because they won’t be changed in a future update (Apple won’t break existing apps).

Up until now, Apple has played by their own rules and all of the apps they’ve not built into the iPhone (Remote, Keynote Remote, MobileMe Gallery, etc.) have been based on public, no private APIs. Reportedly Pages, Keynote, and Numbers were careful to stick to public APIs as well. That’s only fair. If Apple could do things in the App Store that competitors like QuickOffice or Documents to Go couldn’t, developers could rightly call it unfair, and that could lead to trouble.

However, according to Arment and backed up by oldmanuk, iBooks does make use of private APIs for functions like the in-app brightness control, a feature that would get a competitor like Amazon’s Kindle app rejected from the App Store.

Developers are understandably upset about this seeming break in Apple’s policy.

Thing is, Google famously got away with using private API for their Google Mobile App in late 2008 only to have those API made nice and legal in 2009.

So for TiPb’s part, we’re going to wait for the iPhone 4.0 event in 2 days and see if the private vs. public API landscape doesn’t change when the next SDK beta hits the streets.

[Thanks Dev for the tip]

Cult of Mac reports that Apple has begun removing apps from the iTunes App Store that scan for Wi-Fi access points. It looks like these apps are being removed due to their use of private APIs, which is prohibited by the iPhone SDK agreement. This would make it similar to the recent removal of apps that misused the iPhone camera DCIM folder to store and exchange documents.

There’s been some suggestion, however, that list reflects a policy change from Apple closer to the recent removal of sex-based apps.

Our speculation is that Apple has either added the Wi-Fi private APIs to their static analysis tool, or has just finally gotten around to checking for them. That would make it appear like a new policy when it’s actually the originally agreement finally being enforced.

Some developers believe long term lack of action by Apple equals tacit approval for private API use. Those beliefs likely have to start changing. When Apple makes an API public, they’re guaranteeing that developers can use them and have faith Apple won’t break them (and the apps built on them) in a future update. Private APIs are the opposite — Apple can and will change them at any point, breaking apps that try to use them when they shouldn’t. In some cases Apple is working on public versions of private APIs and will release them in future versions of the iPhone OS. In other cases they aren’t — sometimes for security, other times just for proprietary reasons.

In either case, this isn’t the first and likely won’t be last set of rejections. While we feel for developers, we feel more for users who may have come to depend on the functionality of these apps.

If you’re a developer who’s dealing with this and have a better take on the situation, please let us know!

[Thanks to everyone who sent this in!]

9to5Mac brings word of Unity’s latest update:

Unity iPhone 1.5.1 includes improved XCode support and improved AssetBundle support, but more importantly Native APIs (NSGetEnviron and exc_server functions) have been removed to comply with new Apple requirements.

“The main reason for this is to avoid problems with applications breaking when Apple releases new versions of the iPhone OS,” the company explains.

In case you hadn’t been following the story, Apple is using a new static analysis tool to find and reject apps using private APIs, and in so doing flagged a bunch of them caused by some calls inside the Unity game development engine (and the Three20 framework, perhaps among others).

On the flip side, it’s possible the same static analysis tool is also generating false positives when it comes to apps using Apple’s own recommended backward compatibility guidelines.

According to Apple’s Dev Center:

By using “weak linking” in your Xcode project, you can include frameworks you’ll need for the newer features, and check for API availability when your application is running. This technique provides you with the broadest possible audience for your application.

Yet developer Juicy Bits Software speculates that:

we’ve been bitten yet again by the static analysis tool. 3D Camera Lite runs on iPhone OS 3.0 or later, and we check the OS version before calling any of the new 3.1 APIs…

So, basically, Apple’s not acknowledging the OS check, and rejecting based on 3.1 APIs being used for apps that run on earlier versions of the iPhone OS that don’t include those APIs as public.

If correct, that’s certainly “frustrating” as they put it, and yet another sore point Apple will need to address and quickly.

[Thanks to Jordan for the Juicy Bits tip!]

• Our podcast feed
• Download Directly
• Subscribe via iTunes

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!

Credits

Thanks to the the iPhone Blog Store for sponsoring the podcast, and to everyone who showed up for the live chat!

Our music comes from the following sources:

• I Called You — iPhone Remix by Pete Leidy
via Sneakmove iPhone Ringtone Challenge

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?