App Review: A Modest Proposal

Any working iOS developer has read tens, if not hundreds, of critiques of Apple's App Store Review process over the years. Most take issue with:

  1. Capricious approval decisions,

  2. The walled garden/curation approach, in general, or

  3. Perceived hostility toward indie developers, specifically

While these are thorny problems, they are either not ubiquitous (#1) or simply inherent to the platform (#2 and #3).

On #1, Apple appears to have difficulty deciding what’s permissible with new APIs and technologies. But it also seems like they eventually figure it out and settle down after a few months. (This isn’t to diminish the tremendous frustration the developers of PCalc, Drafts, et al. must have suffered, but most developers—thankfully—don't have to deal with this issue.)

On #2, it’s hard to argue that the App Store has been anything but a monstrous success, and that App Review has helped create the highest-quality, most-easily-accessible collection of safe, stable, software ever built, enriching countless developers in the process.

On #3, the App Store is not the fundamental problem here — it’s just really hard to make money in zero-marginal-cost markets. It's not Apple's fault if you can't. Caveat venditor.

Of these three issues, only #1 clearly needs a “fix,” and it should be a straightforward matter of internal communication at Apple. I hope they are working on it, and I bet they are.

But there is one truly universal, nightmarish, intractable problem with App Review: review times.

At the moment, our app, is in day 9 of the dreaded “waiting for review” purgatory that every developer faces. Based on the best information available, our app is one day away from the pearly gates. Why is this week (or more) of waiting time a huge issue? Glad you asked.

FOR USERS 

1. Long review times means that buggy software stagnates on your devices 

An illustrative anecdote: We once shipped an update that caused intermittent crashing. (We failed to discover this bug despite extensive testing.) When that update was released, we immediately diagnosed the problem and shipped a two-line code fix. We submitted the fix in a couple of hours. The fix waited in review for 10 days. The new code was then summarily rejected because of unrelated caching behavior that had been present in all of our previously approved builds. We changed that code and submitted a new build a few hours later. We waited eight more days. Finally, 18 days after the original bug hit users, the fix was released. Less than 10 lines of code changed during the interim.

The easy rejoinder is, “you should have tested your app more.” That’s true, we should have. But I promise you that no developer has a completely clean record, including Apple itself. Which is okay! But, given that we all sometimes make mistakes, it’s insanely harsh to force us to wait days or weeks to deliver simple fixes. And it's a terrible experience for users who have to suffer through weeks of using a buggy app.

2. Longer development-cycles means that apps don’t improve as quickly

User feedback is the lifeblood of any actively-developed app. We want to hear your concerns, and address them quickly. We want to add the features you want the most, as soon as possible. We want to move incredibly fast — it’s not infeasible for us to ship new features and improvements every few days.

App Review inserts a mandatory 7–10 day period during which none of this can happen. Lengthy review times mandate that our development cycle will take multiple weeks, and incentivizes submitting only huge updates with a litany of features or changes. While this sounds good on its face, any software developer knows that a feature-heavy update is also a recipe for a bug-heavy update. That would be okay, if we could ship fixes for those bugs quickly, but we can’t, so the software spends even more time being poked and prodded internally, which slows down the improvement cycle even further. It’s a truly vicious cycle. For an indie developer or a new startup that is relying on initial launch momentum, it can be fatal.

FOR DEVELOPERS

3. It’s dispiriting and stressful

I’m going to get touchy-feely for a moment here, because this is important. As a developer, nothing is more upsetting than making people’s lives worse through your software. And it is downright brutal to suffer weeks of negative reviews, tweets, messages from friends, coworkers, bosses, and the like, all pointing out a bug you are very aware of. Some of this is deserved — I f*cked up, and earned the pain. But when you fix the problem in an hour and still have to slog through 10 days of explaining to people that you’re really sorry but the fix is just sitting, waiting for approval... it feels like disproportionate punishment. I can honestly say that nothing makes me sadder or causes more stress as a developer than these 10-day-long waiting periods to ship a critical bug fix. I’m sure I’m not alone.

RESOLUTION
 

There’s one “obvious” solution to this problem: Apple could hire a lot more reviewers to bring review times down. While this sounds good on paper, it’s untenable. Apple insists on surprisingly small teams of very talented people, and review is no different. Money is not enough to fix a talent gap. To quote from the linked article:

“People have this idea that there are 100 people in India doing app reviews…It’s just people in a building at Apple, and like every other part of Apple, they can’t get enough really good people. Apple will not compromise the quality of its teams to fill it in. I promise you it’s a lot smaller than you imagine.”

These talented people unfortunately spend their day doing a lot of simple, repetitive work, like identifying apps that contain nudity:

You have to have people sitting there looking at things that may or may not be d*cks all day long. Apple refuses to farm stuff out to massive groups of people. They insist on having actual smart, educated, well-trained people doing the job. So that means they have to have some of their actual employees sifting through a pile of d*cks.

It's a good thing that smart and competent people are doing this job. But there are still ways to make this situation better, for the reviewers, the developers, and the customers.

A MODEST PROPOSAL

How to fix this problem, without requiring Apple to hire hundreds more reviewers? 

My answer: a premium-priced “expedited review” developer account. Apple already charges a $99/year entry price to become a developer. Why not add a $999/year option that guarantees expedited reviews? This premium tier could aim to provide under-48-hour review times (and possibly other pro services).

Developers willing to pay such a steep price up-front will be very serious. Their submissions should be easier to review and will have a much higher quality-to-garbage ratio (and hopefully fewer d*cks). And Apple would make more money!

Hell, I’m 1/2 of a two-man company in an apartment, living off modest savings, and we’d pay that price in a second. If they have to charge $1,499 or $1,999 annually for it to make financial sense, so be it. As we're all well aware, Apple has no qualms when it comes to charging premium prices for premium-tier consumer products. Why is there a one-size-fits-all offering for developers?

Maybe no one cares about fixing the review-time problem at Apple, but I doubt it. More likely, they are either too busy or haven’t come up with a viable solution. Perhaps this particular idea wouldn’t work for some reason, but it's a problem worth solving. Fixing it would engender significant goodwill among developers and make the App Store better for everyone. It’s worth a try.

Previous
Previous

For Complex Queries, Chat Will Replace Search Engines

Next
Next

Apple Watch Pricing for Plebes