I understand the need to for an app review process. Apple doesn’t want to let broken or misbehaving apps in the store. I understand the time it takes to get to each review. It’s a popular store with thousands of updates a day. I know it takes time to have humans look at each and every one of those. Under those conditions I consider the current 4-5 days very reasonable.

What bothers me about the app store review process is the opaqueness. 5 years in, and there is still no indication of WHERE you are in line, i.e. how much longer you need to wait. When an app finally does go to In Review, there is no indication of what that process is or where your app is in the process.

90% of the time (for me anyway) reviews take less than 5 minutes. In the past I’ve gotten the Processing for App Store email before the In Review email, it goes so fast. But that other 10%, oh the 10%. That last 10% of the time reviews can take days. Why? Is there a policy question they’re checking with their supervisor about? Is the reviewer having problems logging in? Did they claim a whole bunch of apps for review off the presumably common review stack and then go home for the weekend? No idea. There is never contact from the reviewer. It’s just In Review. If it is a policy question, then why haven’t they ever contacted my to say “Hey, this is questionable”. I’d gladly change/remove whatever it is they have a problem with.

BTW: The web server logs show that no one has ever logged into the test account we provide for the reviewer(s) in the year I’ve been checking. Not once. How in depth can your review of the app get if you never get past the login screen? My last 3 day In Review time was on a 2-line x.x.1 release to fix a display bug the reviewer never looked at.

Had another great idea come across my desk today that I would love to put into production and push out right away. Newbie Emily would have promised that feature in the next release, scheduled X.Y.Z day, possibly with a smiley face on the end of the mail.

Old grizzled Emily knows better. Old Emily has had too many features postponed or killed by schedules, or management, or politics, or bugs to promise anything to anyone. Here are my 4 basic responses to great ideas now:

1. That is a nice idea.

   That is it for ideas I have not actually written any code for. No estimates, no, “I want to do that”, no “I’ll try to make that happen”. Give any more than this and someone will end up disappointed when it does not happen.

2. Let me think about that.

   You will this response if I have actually written the majority or what you are asking for, and have cleared it politically with QA, management, whomever feels they are entitled to make decisions about what I build.

3. That should be in the next major release.

   You only get this far if I have already landed your feature in trunk/master (depending on your VCS), and our release process is such that we do not have a release branch cherry-picking features from master. Note the complete lack of a time frame on when that release might happen, and the two emphasized weasel words left in statement even at this late stage in the process. Should is there because features can always be removed due to political or technical integration reasons, and major because I need to leave an escape hatch to have a release without the feature (think small emergency bug fixes).

4. Your feature has been available since version X.Y.Z release DD MMM YY

   That is right, the only way you get a specific time frame from grizzled old Emily is if your feature is already shipping, and preferably has had a few days to settle in and get tested by people who were not necessarily waiting for it, that way if they find bugs I have time to fix them before the person looking forward to said feature (you) get to use it.

It seems a little harsh, but I have been bitten too many times by schedules and politics to promise anything more.

So where do you find the motivation to work on the boring stuff? I don’t mean documentation, unit tests, localization, etc. That stuff is fine, if it’s for a product you believe in. I mean having become more of a Product Person, how do you keep working on the projects that clearly are not the thing people will use because they want to, but because they have to?

I am responsible for 2 large products at work. App A is a consumer facing application available for public consumption in the app store. End users choose to download and run it not because they have to, but because it solves a problem for them better than loading a webpage on a PC, or using their bank’s Bill Pay solution. It has a never ending stream of feature requests and I’ve got my own giant backlog of technical improvements to bring it up to date. It is a Product with a capital P.

App B is a B2B enterprise behemoth. It is the kind of thing companies build to use internally, and occationally turn around and sell to others to defray the cost. No one will ever use this thing because they want to. It has a dozen programmers from a half dozen departments working on it because it needs to be everything to everyone. It is the very definition of dull business app. The only feedback it will ever receive is “It doesn’t work like giant system B’, therefore it sucks”.

My problem here is that management has ordered me to work on B full time to help get a prototype out the door, and I cannot force myself to work on it. Even though the objective part of my brain knows I need to work on it to fulfill certain contractual and political obligations, my impulsive side jumps at every single opportunity to work on App A, wether its “emergency” bugs, feature design, or even end user support. Toss in the mental preload time it takes for me to write good code, and I am way, way behind schedule. Even though App B should be all the fun part of software engineering, writing code, I just can’t do it.

So how do I get it done? I don’t know yet, but I’ve got probably got less than a week to figure it out or face some serious consequences.

Update from the future This was & executive dysfunction, because I’ve got undiagnosed/unmedicated adhd.