26 Comments

Summary:

So a new app for the App Store was rejected for using private APIs. Let’s see if I can get in front of this before all of the “OMG!! Apple wrongly rejects another iPhone app!!” articles begin to appear. Please keep in mind that none of this […]

So a new app for the App Store was rejected for using private APIs. Let’s see if I can get in front of this before all of the “OMG!! Apple wrongly rejects another iPhone app!!” articles begin to appear. Please keep in mind that none of this is meant to disparage the app itself, which appears quite nice.

In truth, the app does not use any private APIs. Rather, the developer built his own implementation for displaying and swiping pictures that looks just like Apple’s Cover Flow. If you look at the demos, you’ll see that it appears to be a very good copy of the CF effect. Given that, I can almost agree with the developer when he says: 

I suppose I should be flattered that Apple mistook it for their own implementation

Certainly, the nice implementation had something to do with it. But maybe there was some other factor at work? You know, like the fact that the developer claimed it was Cover Flow! 

Let’s take a look at a portion of the app’s description taken from its web site (emphasis mine):

Rotate your phone to morph into Cover Flow. Just like album art in iTunes, you can scan through photos with the flick of a finger…

Right there, it blatantly says the app is using Cover Flow. Contrast that to the initial description that simply calls it an “animated photo album.” So, let’s see, we’ve got an app that says it uses Cover Flow, it’s implemented like CF, and certainly appears to be CF, so the app gets rejected for using CF. Is this really a surprise? It may have been an honest mistake, but it wasn’t wise to claim use of a specific Apple feature that isn’t being used. 

Should Apple be digging through the code to verify this? Even if it does so on some occasions why should this be one of them? The developer says he’s using Cover Flow. Besides, Apple might take exception to using the term “Cover Flow” when in fact it’s something else. 

It seems to me the developer should have named the feature, parenthetically mentioned that anyone familiar with Apple’s Cover Flow will know how to use it, and then referred to it only by whatever name it was given, never mentioning Cover Flow again. Would this have meant acceptance in the App Store? I don’t know, but if not, the developer might at least have a point about being rejected. As it is, there’s no point in complaining about being rejected for using a private API he claims to use.

You’re subscribed! If you like, you can update your settings

  1. you’re basically arguing semantics and Trademark.
    They obviously said they use Cover Flow because to the end user, it doesn’t matter. If Apple doesn’t want them to use the words Cover Flow, then Apples Trademark department should take it up with them. But it should be pretty damned easy for the App Store screeners to get some clarification first.

  2. Well…. if it weren’t for the fact Google got accepted and then bragged on their blog about using unpublished APIs, whereas this developer was told his rejection was for using private APIs, then you might have a point.

  3. Joe L.

    To my knowledge, “Cover Flow” is not trademarked. I see no such symbol next to it in Apple’s copy. Using the term, however, clearly implies you’re using that feature. As for it being “damned easy” for the App Store screeners to get clarification, huh? Why the heck should THEY have to get clarification? The developer says he used it, that should be all the clarification they need.

    Colin,

    My point was that he claimed to use a private API and was rejected for it. That point is valid no matter what Google did. For a developer to think he has similar “power” to Google’s for using various APIs would be stupid.

    I suppose we could piss and moan about Google getting special treatment, but welcome to the real world. It doesn’t make this developer’s case any stronger, nor will it get his app in the store. I think the misunderstanding is largely his own doing. Don’t call it Cover Flow (especially since it’s not), explain to Apple it’s your own implementation, learn from the episode, and move on.

  4. Tom apparently hasn’t heard of Google.

    http://www.macnn.com/articles/07/02/21/coverflow.aperture.patent/

    Cover Flow is trademarked.

  5. Why couldn’t he just say, as the article suggests, that it works JUST LIKE “Cover Flow” ™?

  6. What do you have to say about that TOM! (Coverflow in fact being trademarked)

    Nothing, that’s cuz it’s hard to talk with your foot in your mouth you big bully.

  7. Whether Cover Flow was trademarked is not relevant to my argument, which is why my article made no claim one way or the other, nor did I need to look it up. It simply doesn’t matter.

    Thanks to “dude”, we see it is trademarked. That changes my article… how? If anything, it strengthens my argument. My point was valid trademark notwithstanding because it’s clearly an Apple feature (and private API) the developer claimed to use.

    Seriously, people, turning this into a Google or trademark issue is beside the point. The Cover Flow APIs are private, the developer stated that he was using it, so the app was rejected. He should not be surprised for getting an app rejected that appeared to use a private API he claimed to use.

  8. Tom —

    I e-mailed Apple (and called) multiple times throughout the month as we waited for approval of our application. I informed them of how we had implemented our own version of Cover Flow, and I even offered to share the source code with them so that they could verify that we had done so.

    I requested our web designer not use “Cover Flow” in any of the marketing materials, but the references seem to have escaped the edit. That said, I think your point is a bit odd.

    Apple could have read my many e-mails, or responded the support requests I placed over the phone. They could have asked what I was using, or they could have *checked* the binary I submitted to see that it does not actually use UICoverFlowLayer. “Cover Flow” is a marketing term — not a technical term — that defines a user interface model. There are ways to check whether I used the UICoverFlowLayer API.

    Prior to Peeps being rejected, I checked for exactly that in Safari Books Online’s Bookbag application, which *is* using the private CoverFlow API and *was* accepted into the app store: http://landonf.bikemonkey.org/code/iphone/iPhone_Private_API.20081206.html

    In conclusion, Apple’s review process is an technical engineering review. Using the term “Cover Flow” in marketing material is absolutely not — in technical terms — equivalent to saying “we use the UICoverFlowLayer private API”. Moreover, there are ways to check.

  9. Landon,

    Thank you for your thoughtful response. I appreciate it.

    Your web designer would have done well to heed your advice.

    I’m not unsympathetic (indeed, I understand) your frustration. One does have to wonder if, in the machinery of the approval process, all emails are seen by all necessary individuals. I suspect it’s pretty hectic behind the scenes in the App Approval Dept.

    Your story re: Safari Bookbag is a good overall comment of the App Store approval process itself. Perhaps similar to another story where one app is rejected a couple of times and then finally approved without ever being changed.

    So, is this a case of the many App Store “approvers” doing their jobs at various levels of efficiency? Kind of like the difference between getting a knowledgeable support rep on the phone as opposed to an a-hole? In other words, had your app been placed in a different approver’s hands would it have gone through? I think we have to acknowledge that that’s a possibility.

    Maybe we like to think Apple’s best and brightest are working on these technical reviews. But, seriously, if you were one of the best/brightest would you want to use those skills as an “app approver”? I doubt it, just as the most knowledgeable product people don’t typically want to man support lines.

    While I think using the term Cover Flow does imply the use of that API, sensible people can disagree over that. However, even if you’re technically correct, maybe NOT using the term would have kept Apple from looking in that direction to begin with? Still, that may be moot since you say other documentation was sent to clarify the situation.

  10. “I’m not unsympathetic (indeed, I understand) your frustration.”

    Yeah, right. Hence the phrase, “I suppose we could piss and moan about Google getting special treatment, but welcome to the real world. It doesn’t make this developer’s case any stronger, nor will it get his app in the store. I think the misunderstanding is largely his own doing.”

    Mr. Fuller makes a compelling case that what you allege is not true. And “real world” issues aside, rules are rules.

    How’s that crow taste, Mr. Smarmypants?

Comments have been disabled for this post