3 ms·

All of these things can be handled once, together, in a single e-mail. Actually for app reviewing throughput purposes, disqualifying the app on the first major

All of these things can be handled once, together, in a single e-mail. Actually for app reviewing throughput purposes, disqualifying the app on the first major thing they catch is a good idea on Apple's part.

arohner 17y ago
Maybe it saves time on the reviewer's part, but increases developer frustration. Which is more valuable to Apple?
- dschobel 17y ago
  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.
wvenable 17y ago
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.
- dschobel 17y ago
  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.
dandelany 17y ago
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.
- joezydeco 17y ago
  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?
  - dandelany 17y ago
    > 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.
jhancock 17y ago
"Four legs good, two legs bad!" http://www.youtube.com/watch?v=OYecfV3ubP8 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.

arohner 17y ago

Maybe it saves time on the reviewer's part, but increases developer frustration. Which is more valuable to Apple?

dschobel 17y ago
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.

wvenable 17y ago

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.

dschobel 17y ago
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.

dandelany 17y ago

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.

joezydeco 17y ago
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?
- dandelany 17y ago
  > 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.

jhancock 17y ago

"Four legs good, two legs bad!" http://www.youtube.com/watch?v=OYecfV3ubP8 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.