Our app got rejected again. We're trying to figure out why.(graffitigeo.posterous.com)
graffitigeo.posterous.com
Our app got rejected again. We're trying to figure out why.
http://graffitigeo.posterous.com/our-app-got-rejected-again-were-trying-to-fig
12 comments
It depends on whether or not the application is resubmitted. If, after the first rejection the developer says "to hell with this" and never comes back then the throughput is increased. However, if the developer subsequently resubmits only to be tripped up on the next item then you've increased the overhead for both the developer and Apple. Each resubmission is more overhead.
agreed. and Apple has the data to make the decision, we don't.
just to say it isn't a sensible policy a priori is incorrect I believe.
just to say it isn't a sensible policy a priori is incorrect I believe.
I don't agree at all. If Taco Bell implemented a policy limiting you to one taco at a time, rather than allowing you to handle all your (stomach-churning) food needs all at once, each order would take less time. They would even increase their "thoroughput" as measured by the # of orders filled per hour. But their line would be ridiculously long, because everyone would have to come back through again to finish their meal. Oh, and everyone would be pissed.
Same deal here. No one (or almost no one) spends 2 months coding an iPhone app, only to just flat-out give up when it gets rejected. They fix the problem (or what they think is the problem after attempting to decipher Apple's rejection notice), and get back in line. By implementing this policy, Apple decreases their efficiency by adding managerial overhead - instead of one reviewer getting assigned one ticket once and handling three problems, those three problems are spread out over (I'm guessing) three different reviewers, which means time wasted dealing with each reapplication.
Anyone who's ever developed software understands this intuitively: If you're fixing a reported bug, and in the process of doing so, discover a related bug which you know will be reported eventually, you don't fix the first and ignore the second. It may seem attractive, but you just know that another full cycle of report -> project manager -> scheduling -> reassignment -> new developer reading & getting caught up -> fixing -> QA is just wasting everyone's time.
Not to mention, making app developers, who are literally walking Apple profit machines, go to the back of the queue time and time again without even telling them why is just stupid business.
Same deal here. No one (or almost no one) spends 2 months coding an iPhone app, only to just flat-out give up when it gets rejected. They fix the problem (or what they think is the problem after attempting to decipher Apple's rejection notice), and get back in line. By implementing this policy, Apple decreases their efficiency by adding managerial overhead - instead of one reviewer getting assigned one ticket once and handling three problems, those three problems are spread out over (I'm guessing) three different reviewers, which means time wasted dealing with each reapplication.
Anyone who's ever developed software understands this intuitively: If you're fixing a reported bug, and in the process of doing so, discover a related bug which you know will be reported eventually, you don't fix the first and ignore the second. It may seem attractive, but you just know that another full cycle of report -> project manager -> scheduling -> reassignment -> new developer reading & getting caught up -> fixing -> QA is just wasting everyone's time.
Not to mention, making app developers, who are literally walking Apple profit machines, go to the back of the queue time and time again without even telling them why is just stupid business.
I'd look at it from the reviewer's side (just to play devil's advocate here).
We know from some reports that they're reviewing 8500 apps per week over (supposedly) 40 reviewers. That's about 10 minutes per app per reviewer per 8 hour workday.
So imagine you're the cashier at Taco bell and you have 10 seconds to fill an entire order. The line is hundreds deep. When someone comes up and says "I'd like a Whopper and..." do you spend time trying to correct that person, or do you yell NEXT! and kick him out of line?
We know from some reports that they're reviewing 8500 apps per week over (supposedly) 40 reviewers. That's about 10 minutes per app per reviewer per 8 hour workday.
So imagine you're the cashier at Taco bell and you have 10 seconds to fill an entire order. The line is hundreds deep. When someone comes up and says "I'd like a Whopper and..." do you spend time trying to correct that person, or do you yell NEXT! and kick him out of line?
> they're reviewing 8500 apps per week
Yes, but the question is: what percentage of those are apps that have already been submitted and rejected, and are back for their 2nd (or 3rd or 4th...) time? Your analogy is a good one, but I think it breaks down when you're kicking a large percentage of people out of line, and none of them are leaving.
Yes, but the question is: what percentage of those are apps that have already been submitted and rejected, and are back for their 2nd (or 3rd or 4th...) time? Your analogy is a good one, but I think it breaks down when you're kicking a large percentage of people out of line, and none of them are leaving.
"Four legs good, two legs bad!" http://www.youtube.com/watch?v=OYecfV3ubP8
sorry if you feel I'm slightly mixing metaphors. Sometimes I feel like I'm chatting in a forum of frogs in a pot of rising heat.
sorry if you feel I'm slightly mixing metaphors. Sometimes I feel like I'm chatting in a forum of frogs in a pot of rising heat.
Maybe it saves time on the reviewer's part, but increases developer frustration. Which is more valuable to Apple?
I'd say that complaint pales in comparison to things like the seemingly inconsistent application of the guidelines and lack of feedback so I think they're absolutely correct to err on the side of getting more apps through the pipeline in that case.
You should read up on the history of the MPAA and the movie rating process. Very similar to Apple's, as in vague on purpose. Think of it this way. If they tell you exactly what's wrong, you will fix exactly what's wrong. If they let you figure it out yourself, you may fix exactly what's wrong, or you may fix more than what's wrong. The second option is always going to be better for Apple because it gives the highest probability that your app will be more "fixed." Now as to the definition of fixed, well you're on your own there.
[deleted]
i like to imagine that in this magical app rejection/approval department at apple, the employees have a whiteboard on the wall and are competing against each other to get the most app rejection tally marks, and one gets special bonus points for each weblog posting found that is made complaining about the rejection.
[deleted]
[deleted]
We have also received ambiguous feedback from an Apple developer program reviewer. With the 2+ weeks waiting period in the queue, developers deserve more detailed responses so they are not waiting with no clue if their next binary submission will appease the inconsistent reviewers.
"1984" Apple ad. http://www.youtube.com/watch?v=OYecfV3ubP8
It really does not matter if you think they are right or wrong. Watch the vid and decide if that's what you want to attach your startup fortunes to. I can understand why some funds would have been motivated to focus on iPhone apps last year. At this point, I wouldn't touch an iPhone startup without an ironclad insider contract with Apple.
It really does not matter if you think they are right or wrong. Watch the vid and decide if that's what you want to attach your startup fortunes to. I can understand why some funds would have been motivated to focus on iPhone apps last year. At this point, I wouldn't touch an iPhone startup without an ironclad insider contract with Apple.
It sounds like Apple's approval process includes a part where they run "strings" on the binary and look for the word "beta".
"Companies succeed with single founders all the time. Just look at Digg, Craigslist, eBay, Netflix, Wordpress, Wikipedia, Amazon, TechMeme, PBWiki, TechCrunch, TechMeme, and Etsy."
Again repetition in short published list. Am I going insane? Do you also see this?
Again repetition in short published list. Am I going insane? Do you also see this?
It seems like the comments you posted from Apple explain pretty clearly why, but according to the App Store, it looks like it's for sale - or isn't it?
We have no references to "beta" or "demo" in our metadata, binary, or application. So I'm not sure what they are referring to there. The "feature limited" part is confusing to us--we're not actually sure if they are referring to the mobs functionality or not.
The current version in the App Store is 1.0, we've since posted 1.1 and are nearing a completion of 1.2 ;) Perhaps we just skip 1.1 by the time this gets approved.
The current version in the App Store is 1.0, we've since posted 1.1 and are nearing a completion of 1.2 ;) Perhaps we just skip 1.1 by the time this gets approved.
This is a legit rejection. There IS a difference between building for Debug and Release and you CAN'T reference the full version.
Did you send them an email, and ask them to be more specific?
Yep =] Nothing back yet.
I know a couple of developers that have gotten their apps published without any major hiccups. I'm working on my own (a Hacker News reader) and I'm being careful to get everything right. It increasingly seems that it's a vocal minority of developers that are raising most of the fuss about Apple's approval process. I didn't see anything vague or arbitrary in the emails the reviewers sent. They were rather specific about why the version was rejected and what to do to correct it.
We need real unofficial app stores. Apple shouldn't be allowed to momopolize the iPhone apps market like that.
Actually for app reviewing throughput purposes, disqualifying the app on the first major thing they catch is a good idea on Apple's part.