Ever since Apple allowed developers to submit apps to their iOS App Store people have had mixed feelings about the app review process. While the general consensus is that app review keeps the quality of apps on the platform high, many developers have run into issues with the process.

As an agency that develops apps for clients we have had to deal with app review quite a lot (about 100 submits in a little over 5 years), so whatever our opinion on the App Store or its review process, we will have to live with it. To handle app reviews we have had to define processes that make the review manageable and that de-risks the process. In this post I’m sharing a few of the things we have learned over the years to ensure a smooth review process. (I will skip the cliche ‘make sure the app is of high quality’, because that’s something that you should be doing anyway, regardless of app reviews).

The most important thing in dealing with app reviews is knowing what’s in the review guidelines. And not just knowing, but understanding what Apple is trying to achieve with their rules. I wouldn’t claim to know the ins and outs of every guideline, but we are generally able to advise our clients on what is or isn’t allowed, and what the grey areas are.

Usually when we do an app project we try to submit a few app versions weeks or even months before the planned launch. This allows us to test the waters and see if Apple agrees to what we are developing. You aren’t allowed to submit half-assed apps so we generally try to submit an app with properly working features that are a subset of the intended end product. This happens to match quite well with our SCRUM process where every sprint is supposed to deliver a working set of features.

A pre-submitted build almost never goes into production; but an additional benefit of the pre-submit is that it is a back-up if the final review takes unexpectedly long (which is quite rare by the way), and we still need to release an app, we could release the previously approved pre-submit. This is useful in projects with hard deadlines (we work a lot in media where an app release might be tied to the start of a show’s season on tv).

We keep an eye on Shiny Development’s http://appreviewtimes.com/ to know what to expect from app review at certain times. In addition to this indicator there are a couple of known influencers on the review length. When Apple releases a new iOS version for example you can expect app developers to start submitting app updates in preparation of the new release. This usually happens around September when we see review times go up. Around the Christmas holidays Apple always closes the store for about a week so before and after that reviews will also take longer. When Apple releases an entirely new product, app review times go up too.

Some developers accuse Apple of being arbitrary or inconsistent in its rejections, but for the most part Apple is pretty predictable. We’ve had a few incidents where an app reviewer didn’t like something arbitrary in an about screen or didn’t approve of a picture a content manager had uploaded right before review, but these incidents have been extremely rare for us. What we’ve learned is that all reviewers are mostly just people; if a feature is confusing or unclear, they might ask questions about it. To prevent any delay, we try to include information in the review that might help the reviewer. If an app is targeted at a specific target audience that the reviewer is likely not a member of (typical in professional apps that target a specific skill set), we tend to include a video demoing the app even before Apple asks for it. They also have this set of questions they ask such as what the purpose or target audience of an app is; stuff that we can easily include up front in the metadata or review notes.

As I mentioned above: app reviewers are just people too. We’ve had a few rejections because the reviewer has simply misunderstood or misread something. Sometimes replying to the rejection is sufficient to get the reviewer to look again, sometimes you need to file an official appeal. But there’s a good chance that if a rejection was inappropriate, you’ll pass review a second time. Tip: to avoid losing time, first reply to the rejection note if you think the reviewer made a mistake. If you resubmit your binary unnecessarily, you’ll end up at the end of the review queue and it will take a while before your app gets another look.

Generally the rejection note will indicate whether a resubmit is necessary or whether an answer will do, but sometimes it won’t. Maybe your app got rejected because your server was ddos’d at the time of review. In such a case simply reply and explain the situation. In our experience the app review team is happy to take another look and very open to reasonable feedback.

Apple’s App Store review board appeal process is still crazy slow, but actually had a good outcome. Bill at Apple saved my bacon. Thanks!

— Brooks Andrus (@babarakus) 13 november 2015

In the end, app review is a project risk like there are many others. You can’t avoid these risks, but you can take them into account in your development process. If you don’t, then yes, you might run into big trouble. But it is very well possible to prepare for and deal with app review.

I hope the above will help people when submitting an app. If I omitted anything, please leave a comment!