App Rejections

Among the rejections for “app that mentions or depicts anything to do with Apple”, I believe this is the most extreme example. But buried in this is also a larger issue (see below).

Our book about the iPhone has been rejected from the App Store BECAUSE IT CONTAINS THE WORD iPHONE.

“iPhone: the missing manual” [] is an e-book version of a bona fide paper book – published by O’Reilly, no less – that contains consumer-oriented tips and advice on how to use an iPhone.

This app was rejected not once, but twice, ultimately for the same reason (but in different ways). Firstly, for using the word “iPhone” in the title to imply that the product was in some way specific to the iPhone. Oh, the irony! Secondly, for using a depiction of an iPhone in the app-icon – same problem.

In this case, the book was from Macworld, the well-known Apple-focussed review site. After several rounds of arbitrary rejections, their Editor – Jason Snell – switched to Classic Tactic:#3, and fired off a series of outraged tweets (1, 2, 3). These got a phone-call from Apple within a few hours and kick-started a rapid appeal.

(read Jason’s detailed post-mortem for the full details of the saga).

The Joy of TRC (Technical Requirements Checklists)

Something came up in this rejection that I think has huge significance on a wider scale: Apple’s parting comments about “published works” and “printed material”.

According to Apple, in a sense *all* the rejections were incorrect: officially, reviewers are supposed to accept titles and icons that are from pre-existing published versions of the same product.

This gentleman said that it was Apple’s policy to approve apps that were based on existing published works,
…
and he also referred to Apple’s no-trademarks policy for icons … he explained that Apple’s policy toward printed material also meant that if we represented our book cover as our icon, our app would be approved.

Interesting. Very interesting. Here we have a “super-rule” that trumps the standard rules on app-naming and app-icons. This makes perfect sense.

But Apple refuses to tell us that this rule exists, let alone what the parameters are.

Think that’s bad? Well, from this example, it would appear that the reviewers at Apple aren’t even aware themselves (and not just one reviewer, but several – even during the appeal process!). I snipped some of the above quote, but if you check Jason’s article, you’ll see that even his “final” reviewer was about to reject the icon, until pressed to investigate further.

In the games industry, we’ve had platform owners dealing with huge volumes of developer-made content flowing through their hands for decades. One of the most basic tools – as used by every game-console manufacturer – is the TRC (or TCR, or similar – Microsoft, Sony, and Nintendo have slightly different terminology).

This document is always made public to all approved developers – it saves developers a lot of time, but it would also save Apple time and money.

I speak from experience: a few years ago I worked for a billion-dollar multinational games publisher where we had no public TRC’s. Myself and a few others started a campaign internally to turn this around and get them shared with our development partners.

Ultimately, IIRC there were only two major counter-arguments, both of them variations on this:

“But what if we (platform owner) know too little about our business to define what should be allowed? We might write the checklist wrongly!”

Um, yeah. Whilst that fear may be well-grounded, it’s not the kind of problem you should be accepting and ignoring.

(I’ll cover TRC’s in more detail later)