The app just sits there for 6-8 days, untouched, then goes through an approval or rejection process that, as far as I can tell, takes less than 20 minutes for a complex app (and probably much less time for a simple one).
The approval delay has been remarkably consistent since about a month after the App Store launched.
I don’t believe that the delay is caused by a legitimate work overload on Apple’s end. As any developer or server admin will tell you, this is not the behavior of a queuing system that can’t quite handle the inbound request volume. If it were, the delay wouldn’t be consistent — it would grow out of control until nothing was getting served, then Apple would add more capacity, then requests would get served with no delay for a while, then they’d start queuing again. It wouldn’t be almost exactly the same delay every time.
I have a different theory: The delay is intentional. I think Apple has found some good reasons for making app developers wait at least a few days before they spend a second of their time reviewing it. My best guess is that a lot of developers find new bugs, cancel their submissions, and upload new binaries within a certain amount of time on average, and Apple doesn’t want to review them twice. Or they just don’t want developers to be able to issue new versions more than once every week or two to prevent gaming the (broken) “Newest” ranking.
If I’m right, well… let’s just say that doing this would be highly offensive to developers, and I really hope that Apple is better than that in their treatment of the people that are earning them a lot of money. But I can’t think of any other explanation that’s supported by the behavior that I see.
Your theory about intentional delay leads to a model where equilibrium of the queueing system can be reached when using a delay.
Your original model is:
submission rate = approval rate
New model is:
submission rate = approval rate + cancellation rate
The cancellation rate is f(delay) where we get more cancellations when developers have to wait longer for their app to be approved. This simple model means deviation from either side of delay pushes the equation back to a certain delay. If delay shortens:
submission - approval - cancellation > 0
and apps back up and the delay gets longer. Similarly, the queue shortens itself when the delay gets longer and the delay returns to equilibrium.
Obviously the true equations for the app store are more complicated as the submission rate is likely always increasing as more people release apps, and the approval rate is probably increasing as apple hires people to handle more submissions.
Really, at the end of the day, the delay is whatever Apple chooses it to be. They can hire more people and shorten it, or hire less and lengthen it. The length of the delay is a business decision and should be completely intentional. It’s whatever they’ve decided will allow them to marginally get more submissions to bring them more money versus the marginal cost of hiring another reviewer.
