Developer Says He Uses Cover Flow, App is Rejected, Developer Surprised

26 Comments

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.

26 Comments

iWyre

[…] apps rejected for using private methods even though that technique doesn’t, similar to the Coverflow debacle from last […]

Remus

For the record, my application just got rejected for the same reason. I had included a cover flow like view in my UI, build by me from scratch using CALayer and core animation. I did it just for the fun of it, took me some 60 lines of code. Now note that nowhere, and I mean nowhere, in my application or in my description of it did I use the term Cover Flow. Is not even in my app submitted screenshots! I just wrote them back asking to reconsider since I do not in fact use their private API, but just good ole’ fashion Core Animation. I’m waiting for their reply now.

Adam

The app should be allowed in the App Store. The reason for rejection is invalid; he is not using unpublished APIs. Next case, please.

cmfnyc

@ Gazoobee

I also agree on all points but one. And I am equally disturbed about folks on blogs in general and here, too, going negative on authors. I do not think that I ever did. I was just trying to make a point, one that I have started making in comments, about blogs reaching for higher standards.

A bit of background. When I first saw the article in my feed, I was pleased: “Finally, a blog is not going to accept dev complaints at face value.” Alas, it took the app’s rejection at face value. I liked the direction Tom was going in, just not the execution.

And here’s where I respectfully differ on defining blogs. I agree they started out as personal journals. But like so many media, they have morphed into much more. Just as Blackberries grew out of being two-way pagers, I think most blogs have outgrown their personal journal tag. Certainly if this were Tom Reestman’s personal blog, I would have viewed it differently. But it’s not. It’s an online (non-traditional) news-gathering organization devoted to covering Apple. And therefore, I think it should try to at least emulate other more seasoned news orgs. Maybe the Times is too high, but aiming above the blog fray is not.

In the end, I hope that the comments do not discourage Mr. Reestman. I’ve like his past posts (Jobs, MobileMe) and the voice he is developing. And I certainly don’t agree with the harshness of several comments here. Perhaps rather than defend the piece, just amend it and move on.

To Gazoobee, I will look out for you in commentosphere. You sound like a really thoughtful person. I appreciate your responses.

Gazoobee

@ cmfnyc

I agree in principle, but the fact remains that a blog is not “official” journalism in any way. I am one of those that decries the loss of any kid of journalistic principles in the last 20 years or so. There are (by my personal definition) only a handful of actual “journalists” left in the world at this point, but it’s in this new “non-journalistic” world we reside at the moment.

Blogs contain personal information by definition and more opinion than fact. As far as I understand the definition, they are “a personal viewpoint” on the news usually dictated by someone who was there at the time (of the news event) and thus more immediate and viral like opinions tend to be.

Some of the best blogs transcend even the mainstream media and adhere to actual principle of journalism more than such sources commonly do today, but to *expect* that level of expertise from a blog is foolish IMO. This person did more basic fact checking than I find is usual on a blog, and obviously thought out their article. It had a theme, it made sense as a logical argument and there were no facts available to them at the time of writing to disagree with their thesis.

The blog author was then put in the uncomfortable and rare position of having the subject of the article respond to them with information they did not have at the time of writing. This kind of wrecked the article and the author had to do some fancy dancing around to save face, but nothing was misrepresented and no lies were propogated as far as I can see.

Long story short … I think the author was taken to task far too much for a situation that was out of their control and to which they did not contribute. It’s a matter of degree I guess. No one is perfect after all, but to say the author was stupid or wrong or misleading (all implied by various people above) goes much too far in this case.

J.Y.

FYI – the app “Searchme” also falls into the category of approved apps that use a Cover-flow like navigation paradigm.

cmfnyc

@Gazoobee
Was your response meant for Hobbes Doo or me. I guess either way I think blogs and the New York Times have more in common or should have than your comment suggests. To me, if you are going to represent any entity that purports to publish news by putting your words in a public space that is journalism. And you should do so with much care if you want those words and your voice to be respected.

I agree that I don’t think Mr. Reestman’s article is much different than those on many other blogs (and it wasn’t bad just a bit under-reported. But I don’t agree that it makes it OK. Blogs are the future of journalism. And I believe those that grow up to embrace it’s principles will ultimately succeed.

Gazoobee

@ Hobbes Doo

What exactly do you think a blog is? Your critique makes sense if you are talking to a New York Times reporter, but not to a blog writer.

@ Ian Betteridge

You haven’t bothered to read what Tom wrote. The “fact” (that no one knows for sure), is what the thought processes of the reviewers were. You are responding to an argument he didn’t make.

Tom further implied that we don’t even know for sure if the emails Landon mentioned were seen by the person who ultimately rejected the app. That’s a bit more of a stretch, but still possible. We do not in fact really know “for sure” what happens at Apple’s end, and I think that is his main point or the nugget of his retort.

Ian Betteridge

Tom: “Landon responded with information to state why he doesn’t think that’s the case, but the fact is no one knows for sure.”

Except that we do know for sure, because Apple stated quite clearly why it was rejecting the application: because it believed the product used private APIs. The interesting thing is why did Apple state that? Either:

1. Apple knew it didn’t use private APIs, but chose to lie. This is unlikely. Why lie?
2. Apple didn’t know it didn’t use private APIs – Landon’s communications got lost somewhere and someone took one look at the app and *assumed* it used private APIs.

Either way – and option 2 is the most-likely explanation – it indicates a snafu on Apple’s part. No matter what the marketing materials said, Apple messed up. And while Apple making what looks like a pretty simple error doesn’t matter much to you or me, to a developer who’s only legitimate outlet for their work is the App Store, it’s a pretty serious error.

If Apple is going to be the only outlet for applications for the iPhone it *really* needs to be absolutely certain of its grounds for rejecting an app.

Hobbes Doo

@Tom, without having contacted the developer first and/or Apple, your story is nothing more than your personal opinion without anything to back it up. Nothing wrong with that, but it should have been noted as your personal beliefs, not as probable facts.

Hobbes Doo

@cmfnyc, awesome comment and point of view. I couldn’t agree more. Fact finding is an important part of any decent news, be it a news site or a blog. Without it we’re just spreading rumours and personal opinion. A few calls/searches to get all the facts from all the involved parties can’t harm any article that claims to be more than personal opinion.

Tom Reestman

Ian,

“Tom, it would look a lot better if, having been demonstrated to be wrong on pretty much every count in this post, you didn’t try and weasel out of admitting it.”

I claimed that Cover Flow should not have been used in the web copy (Landon agreed that he did not want to use it either). I suspected this was the primary reason for his app getting rejected. Landon responded with information to state why he doesn’t think that’s the case, but the fact is no one knows for sure.

My post was a response to a specific post of Landon’s, which I linked to. The information he brought up in the comments here was not in that post. Having received this new information, I acknowledged it, thanked him for bringing it up, and brought up other potential scenarios based on this new information. I’m not sure what else you would have me do?

cmfnyc

This conversation underscores the need for better reporting of the app store across all blogs. From the endlessly recycled Hockenberry complaint about app pricing (something like 20 blogs ran the story without even offering a critique of the argument) to the lack of detail about rejections (has anyone chronicled the entire process-submission to rejection to re-submission? to re-rejection?), we often are only getting repeated words or commentary without any fact-finding.

I realize that may be too much to ask of blogs. But if that’s the case, blogs should stick to reviews and announcements and leave meatier topics to those who can do it right. If, on the other hand, blogs really want to provide perspective to readers, they should make a few calls/emails and do a little digging.

With the Hockenberry story, it would be worthwhile comparing the app store distribution model with other mobile devices (DS, PSP, phones) and big box stores. Or highlighting quality apps that are failing in the app store that would fare better in Hockenberry’s vision. Or surveying users to gauge how they feel about the app store and apps available in it. (How we feel about the app store and how we find apps may be completely different than most devs think.)

With the app rejection story, it would be worthwhile documenting the process. Most devs I imagine would respond to an inquiry (it’s press, after all). And while Apple might not, the writer could try to play the devil’s advocate if only to really burnish the dev’s argument.

If I were playing that role here, I would wonder whether Peeps comes too close to something that Apple should, could or is planning to implement themselves. (I’m not defending the rightness of rejection based on this, just raising the idea.) Frankly, I’ve been wondering why CoverFlow is not integrated more fully into the entire UI. It seems to me a homepage of categories that you can CoverFlow through would be a much better user experience than the current icon pages. My idea would be Category page in Settings, where you could name your categories and assign them by turning apps on/off in those categories, as well as the ability (like reviews on delete) to assign categories on download.

Ultimately, while we all have our self-interests, devs, users and Apple want the same thing: killer apps in an efficient and useful app store. Blogs have the potential to get us all to look beyond our self-interests to this end goal. So far, in my humble opinion, most have not answered that call…yet.

Ian Betteridge

Tom, it would look a lot better if, having been demonstrated to be wrong on pretty much every count in this post, you didn’t try and weasel out of admitting it.

Landon told Apple several times that he wasn’t using their API. No matter how he described in in marketing material, he was VERY clear with Apple that no Apple-only APIs were used.

You’ve now got an opportunity to talk to Landon and get the real, deeper story. Talking to developers who *have* used private APIs, like those named above, might get you a better story too. I would be really good if, instead of expending time and energy trying to claim your original post is still somehow valid, you took that opportunity to do something deeper.

Wendy

“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?

Tom Reestman

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.

Landon Fuller

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.

Tom Reestman

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.

Flunky Carter

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.

Tom Reestman

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.

Colin

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.

Joe L.

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.

Comments are closed.