All Articles Tagged rejected apps

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.

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]

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…

Read the rest of this entry »

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.

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!]

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?

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!

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!]

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!]