The App Store review process and queue theory

The last weeks I have had the mixed pleasure of pushing 19 apps through the App Store approval process for a client. Some updated to improve iOS5 compatibility and some brand new. It might be bizarre that this gave me associations to queue theory, but it did and I will explain why.

I won't claim that I remember much details from the queue theory I had at NTNU exactly a decade ago, in the context of building scalable web apps, but I remember this: If you have a mixture of a few large jobs and a lot of small jobs, you can improve the throughput a lot by introducing two queues[1] - one for the small jobs and one for the large. That way the small jobs can flow through quickly, while the big beasts naturally take some more time, but that is hardly unexpected.

An extension of this principle is exactly what Apple should do. I find it slightly ridiculous that an unchanged app (apart from the fact that it does no longer crash on startup with the combination of iPad1 and iOS5!) can take a week to review, going from version 1.1 to 1.2... So, Apple: Get that high pri queue for small jobs (i.e. minor bugfixes etc.) going and the perceived throughput from the job's (app submitter's) point of view will increase greatly! In practical terms, get dedicated teams (or time) to review updates of existing apps and make them flow through the review process on a less than two day average, compared to taking maybe the bulk part of a week today.

[1] - Or a variant thereof with allocating slices, as in a time sharing system like in modern computers - which de-facto will make small jobs flow through quickly if each job gets an equal amount of time "each round" and the big is not served again before every small job gets its share.