App Store Rejections of the Year

Here’s a list of App Store Rejections “of the Week” publicized by John Gruber on (I did this by googling for “app store rejection” — so I may have missed something).

  • iPhone book rejected for using the trademark “iPhone”. (Resolved: obvious mistake)
  • Congress Bobblehead Dictionary. (Resolved: judgment call)
  • iSinglePayer — app designed to highlight pros of single payer healthcare. (Resolved: judgment call)
  • Podcaster. (Rejected with grounds — bandwidth)
  • Ninjawords dictionary rejected for containing naughty words. (Resolved: obvious mistake)
  • Google Voice. (Rejected but available as a web app)
  • Convertbot rejected for using clock icon to represent time. (Resolved: obvious mistake)
  • Tweetie twitter client rejected because of bad word in trends. (Resolved: obvious mistake)
  • Chess Wars rejected because of chat’s resemblance to Apple’s SMS client. (Resolved: changed appearance)
  • Trillian multi-protocol IM client in limbo for over two months. (Resolved)
  • Airfoil rejected for using Apple’s icons in a reasonable way. (Resolved: policy change/clarification)
  • C64 emulator rejected for being able to run arbitrary code. (Resolved: ability to run arbitrary code removed)

Obviously, there are many other cases, but these are the ones Gruber has chosen to publicize. To me, these all seem like reasonable rejections or obvious (but understandable) mistakes. (Google Voice is unfortunate… let’s find out how Google likes it when Microsoft replaces Windows Mobile with Android + Bing… actually that sounds like a pretty good idea!) After all, these people are handling thousands of apps per week and they’re bound to use heuristics and make mistakes occasionally (“What, the f-word? Rejected!”). And guess what, if you’re dealing with thousands of apps per week, you might not choose to spend a lot of time thinking about a bobble head app.

Here are some interesting lists of things to avoid in your app (yep, Apple sure has scared iPhone developers into silence):

As Gruber points out, developers may fear an app that they’ve worked long and hard on being rejected out-of-hand. But despite flogging this horse for over a year he has yet to find any particularly compelling examples — perhaps the horse is dead.

  • Andrew

    I had a similar case where I whipped together an app to test the 3.whatever clause that used to only disallow interpreting code that had been downloaded.

    It was a simple BASIC interpreter that would allow people to write very simple apps etc. ie since the code had been entered on the device rather than downloaded, it neatly skirted the SDK restrictions.

    Even though I (in theory) managed to convince the relevant person that it didn’t violate the SDK, it was still rejected – because he didn’t think anybody would find it useful. Sigh. Bring on the fart apps.

    In a later SDK they tightened up that clause to remove the loophole – but in theory this also puts a pile of other apps out of compliance (such the the ones embedding Lua).

  • This seems like a pretty stupid rejection. Maybe you need Gruber to take up your cause! (Imagine if you wrote an HP programmable calculator simulator along the same lines — might that be useful? Why would a more general computer gizmo not be useful too?)

    Of course you “whipped up” an app to “test” the limits of policy. So much for sinking X amount of dev time into a project only to be hosed by Apple late in the day…

    Of course much nastier things can easily be deployed as pure web apps, so it seems like a pretty stupid criterion.

    The question is — is this a [bad] judgment call that you could work around, or actually a cloaked policy decision based on such things being “the thin end of the wedge”? Again, HTML5 support in Safari lets you pretty much do anything you like in a web app.

  • Pingback: inconsequence » Blog Archive » Waiting for Jobso()