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.

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

Three20 Framework and More on App Store Screening for Private APIs

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.

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

Apple Using Static Analysis Tool to Find Private APIs, Reject iPhone Apps

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]

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

Apple Rejects/Removes Unity-built Games to Protect User Privacy

After submitting a minor .1 bug fix for Airfoil Speakers Touch 1.0.1 [Free - iTunes link] for iPhone and iPod touch, longtime Mac developers Rogue Amoeba waited for what they assumed would be a routine App Store review. Three and a half months, three rejections, and the unsuccessful intervention of a champion at Apple, the app is finally in the store, but the developer has decided the process is too odorous to continue with the iPhone platform.

Don’t stop us just because you’ve heard this before over and over again.

The issue this time was Rogue Amoeba discovering the type of Mac and exact application that was being used as audio source, and displaying the corresponding Mac OS X-provided image of the machine and icon for the app.

Though standard — intended — behavior on the Mac, Apple’s App Store policy branded this a trademark violation and they requested it be changed. Rogue Amoeba assumed the request was erroneous and tried resubmitting, tried escalating via email, even had a champion inside Apple try help get it through. In the end, the App Store policy was an immovable object, and Rogue Amoeba had to remove the Mac and app icon images. Airfoil Speakers Touch 1.0.1 was then approved and placed in the app store.

(And during the whole process, Airfoil Speakers Touch 1.0, buggy as it was, and using the exact same artwork Apple had issue with in 1.0.1 was left untouched in the App Store for users to download and use).

In the future, we hope that developers will be allowed to ship software without needing Apple’s approval at all, the same way we do on Mac OS X. We hope the App Store will get better, review times will be shorter, reviews will be more intelligent, and that we can all focus on making great software. Right now, however, the platform is a mess.

The chorus of disenchanted developers is growing and we’re adding our voices as well. Rogue Amoeba no longer has any plans for additional iPhone applications, and updates to our existing iPhone applications will likely be rare. The iPhone platform had great promise, but that promise is not enough, so we’re focusing on the Mac.

Add our voice to the chorus: fix. this. More after the break…

While many of these developers point to Apple acting as App Store gatekeeper as the issue, we’d submit right now the actual issue is Apple continuing to act as a capricious, illogical, unpredictable, often stupefying gatekeeper.

Curating a store is just a business model. It may well cost them developers philosophically opposed to the idea, even incredibly talented ones like Facebook’s Joe Hewitt, but every decision has an opportunity cost. Choosing to curate a store, even one growing so fast it has 2 billion downloads and 100,000 apps, and continuing to suffer from poor communications, overzealous legal oversight, unclear guidelines, and the crap shoot that seems ultimately at the core of any given app getting approved on any given day… it just doesn’t work.

Getting rid of the gatekeeper might treat the symptom but is it the cure? Apple legal could just as easily issue a DMCA demand notice for an app using artwork they felt was a trademark violation, and have it taken down — even under Google’s more open, publish-first, investigate-if-flagged App Market system. The problem is Apple shouldn’t think using that artwork is a problem on the iPhone if it isn’t on the Mac. That, and the dozens of other so-obvious-it-hurts-our-brains-issues, are what needs to be fixed, and what are driving developers to question the platform.

Like Palm, Apple could allow developers to skip review entirely, leave them off the storefront, but give them a direct download link to market and distribute on their own. That wouldn’t fix this issue. They could extend Ad-Hoc to infinity so there’d be no update notification or over-the-air (re)downloads, but developers could make binaries available themselves and users could drag and drop them into iTunes to install, along with beefy warning flags for “unapproved apps”. They could create those $999+ “pro” developer accounts, along with dedicated App Store point-of-contact and accelerated review process (levels of partnership program exist on many other platforms and in many other businesses).

Or Apple could just spend some of that 35 billion on hiring a legion of reviewers (rather than just 40ish), training them to the standards of Apple Retail, creating a second team dedicated to communicating with developers, and third team focused solely on whatever tiny percentage of cases, like the one above, spiral out of control.

Yes, Apple is making incremental improvements like email escalation and better review status messages, but every step forward always seems to be met with an equal and opposing step back.

2 billion downloads, 100,000 apps — Apple touts the growth and size of the App Store in press releases, they need to start respecting that size in practice. Observably respecting. It shouldn’t take a champion inside Apple. It shouldn’t take emails from Apple Marketing SVP, Phil Schiller. It shouldn’t take an open letter from Steve Jobs. (Though it might help restore some developer confidence at this point). It should just work, and Apple needs to invest whatever they need to invest at this point to make it work.

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

After 3 Months, 3 Rejections, Airfoil Speakers Touch Ships, Developers Leave iPhone

Umpteenth verse, same as the first — Macworld turned their iPhone ebook into and app and submitted it to the iTunes App Store. It was rejected. Several times. Finally editor Jason Snell expressed his frustration on Twitter and several high profile blogs picked it up. Apple called him immediately to try and make it right.

Good for Macworld. Bad for all the developers who lack the same megaphone by virtue of their job and connections.

Granted, with 100,000+ apps, the non-sensical and erroneous rejections remain a tiny percentage, but even a tiny percentage of 100,000+ represents many developers’ time, effort, and money. It’s frustrating for them and embarrassing for Apple.

Tim Cook and Phil Schiller claim they’re making improvements, and no doubt they are. From a pure perception point of view, however, this is one issue that needs fixing sooner rather than later.

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

How Macworld Got Their iPhone App Approved or How Having a Big Voice Helps

One of TiPb’s favorite iPhone games, indeed the game that cost some of us fingerprints on our index fingers, StoneLoops! of Jurassica has been pulled from the iTunes App Store following a copyright infringement complaint from Luxor-maker MumboJumbo. According to the developers’ blog Casual Games Harmony:

About 3 weeks ago we have learned that MumboJumbo supplied Apple with a formal complaint and a request to remove StoneLoops! from the AppStore. The reason? Infringing Luxor copyright, confusing customers, stealing Luxor’s look & feel and even stealing their source code! This might sound absurd to anyone who knows both games but apparently Apple decided otherwise as we’ve been requested to prepare a formal response, which we did. We described how ungrounded each claim is and supplied various materials to back our claims.

The developers responded, denying all but one complaint (the word Luxor appeared in the text of a quoted review, which they offered to remove). Apple, it seems, removed StoneLoops of Jurassica anyway. This led to the developer further pondering that:

if Apple stands by its decision this will create a dangerous precedence. If you are a developer and have an application in the AppStore you should quickly request Apple to remove the apps of your competition, before someone else requests to remove you! I don’t believe this can get any more absurd, but this is exactly where this reasoning is getting us.

Copyright and infringement is a messy, litigious business, one which Apple puts itself squarely in the middle of by virtue of acting as sole App Store custodian. How can they determine merit all on their own, and avoid action by either affected party regardless of what they decide?

We love StoneLoops! We want it back immediately, but more than that — we need a better way for these disputes to be handled. Is there one?

[via AppAdvice, thanks Tyler!]

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

StoneLoops! of Jurassica Pulled from App Store Due to Copyright Complaint?

In a post on their official blog, Google has let the world know that, “in the interest of transparency,” they’re allowing the FCC to comply with a Freedom of Information Act request to fully publish their response about the whole Google Voice Rejection Brouhaha, and it’s an interesting read, to say the least. You can grab the PDF of the letter right here.

The letter, which had been previously redacted, claims that not only did Apple fully reject both Google Voice and Latitude, but the rejection came after conversations between top executives, including Phil Shiller. This contradicts Apple’s claim that they had not rejected the apps, but merely reviewing them in a more extensive way.

The reason for the rejections (as Google calls them) is what you probably expected: “duplicate functionality.” Google writes:

Apple’s representatives informed Google that the Google Voice application was rejected because Apple believed the application duplicated the core dialer functionality of the iPhone. The Apple representatives indicated that the company did not want applications that could potentially replace such functionality

The story is much the same for Google Latitude, but has a bit more shadenfreude to it since the functionality that’s being duplicated is “a version of Google Maps.” Google also details the dates of calls, emails, and in-person conversations between Alan Eustace of Google (VP of Engineering and Research) and Phil Schiller of Apple (VP of Worldwide Product Marketing, but you knew that).

So… the worm and turned and Google’s letting the world know they feel rejected. How do you feel after this latest development?

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

Google Says Apple Did Fully Reject Google Voice

Rhapsody [free - iTunes Link] is now available in the iTunes App Store. It was less than a month ago that we told you about the submission of RealNetwork’s Rhapsody iPhone app, well Apple may have been scared straight by the FCC because it’s been approved and is now available as a free download.

Now don’t don’t forget there is a $15/month subscription fee you must dish out if you want all of that music streaming goodness over AT&T’s data network or Wi-Fi. Sorry folks, no off-line access like Spotify here.

In a strange twist of fate, PreCentral.net tells us Palm has rejected their first App Catalog app, NaNPlayer, a (superior according to PC) replacement for the built-in Pre music player. Why did they do this? The developer used an undocumented API and that violates the SDK agreement. Sound familiar, iPhone users? Will Palm now get the same grief Apple does?

Sound off in the comments!

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

Apple Approves Rhapsody App, Palm Rejects NaNPlayer

As of this writing, while the C64 emulator app still shows up in the iTunes App Store, attempting to buy it results in the above error message:

The item you tried to buy is no longer available

The availability of the item changed while you were using the store. The same item may be available with a different price or elsewhere on the store.

Whether this is just a glitch in the system, or a result of Apple pulling the app due to the BASIC interpreter still being accessible via a workaround (which would likely be a violation of the SDK license agreement), is unknown. If the latter, hopefully the developer can update and return the app to the store ASAP. Given how fast Apple has been processing Facebook updates lately, it shouldn’t take long to get a revision up, right?

[Thanks to @clayrussell for the head's up!]

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

C64 No Longer Available in App Store?

According to developers Bjango, Apple is now telling developers to remove the “Free Memory” function — the ability to clear data from RAM without force quitting or rebooting — from their iPhone (and iPod touch) applications or those applications will be removed from the App Store.

Bjango, who makes iStat [$1.99 on sale - iTunes link] had to do just that for their latest version:

Stat’s Free Memory function was removed at Apple’s request. This decision was completely out of our hands. Please note that all other apps with Free Memory appear to have been removed or updated without their Free Memory function too.

After eliciting feedback and considering their options, Bjango went ahead and removed the feature. (Bjango advises users who want the feature to NOT UPGRADE their copies, and reminds Mac users with Time Machine how to downgrade to the old, “Free Memory”-enabled version if necessary.)

To rub salt on their wounds, negative reviews are now piling up for iStat in iTunes, of course, despite Bjango explaining Apple requested the removal in the app’s “What’s New in This Version” section.

What Apple’s rationale may be (if Phil Schiller deigns anyone with another email) is unknown.

[Thanks Scott for the tip!]

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

Apple Telling Developers to Remove “Free Memory” Function from App Store iPhone Apps?