Getting Through iOS App Review

Being a well rounded iOS developer means knowing how to work with App Review. The rarely useful, often infuriating process occurs at the end of the dev cycle when time and tempers are short. This combination makes any rejection at this stage costly and deflating.

However, we are not powerless. Below are some of the tricks I’ve picked up over the years that help to reduce avoidable rejections as well as some advice for dealing with rejections when they do happen.

Read the entire App Review Guidelines.

Apple tries to be transparent about the process, and while uneven in application, all rejections will usually cite the guideline that the app violates. Most of these guidelines are written up in the App Store Review Guidelines, a 9000-word long-read on the dos and don’ts of the App Store. While a bit boring, it is useful to read the whole thing. Being familiar with these guidelines will let you catch issues earlier in the dev process, saving money.

‍

‍

If a tedious document doesn’t excite you, you can read the guidelines juxtaposed with entirely unrelated imagery in the App Review Guidelines: The Comic Book. Why or how this ever got made, we may never know, but when my grandchildren ask me when Apple turned the corner, I may show them this.

This comic book is 2 years old so I wouldn’t recommend using it seriously. The guidelines change rather frequently. App Store Review Guidelines History is great resource for keeping up with changes. They provide dates and diffs so you can easily keep up with the guidelines.

In addition to the App Review Guidelines, you will want to check out the iOS Developer Program information as well as the Paid Applications Agreement that is available through iTunes Connect. Both contain restrictions that could get you rejected.

Review common app rejections.

Another fantastic resource provided by Apple is the Common App Rejections tracker.

‍

‍

This page gives you an idea of where most apps run afoul and provides examples of typical rejections. These stats provide a fascinating look at the state of the App Store ecosystem as well as some guides for avoiding common rejections.

Another useful resource is App Review Watch, a Twitter account that collects and a shares stories from across iOS Twitter about peculiar or unfair rejections.

App Review Observer@appreviewwatch

DM if you’d like to anonymously inform the community about a notable App Store approval or rejection

8:52 PM – Dec 18, 2017

Twitter Ads info and privacy

See App Review Observer’s other Tweets

App Review Observer is a Twitter account that tracks and publicizes odd rejections.

Submit early, submit often

When your business is built on the App Store, getting through App Review is just a part of life. It makes sense to design your development schedule with the App Store in mind.

When you have a build that can potentially be released, perform a quick sanity check and submit it.

Doing this may sound counter intuitive, but you can use the ensuing few days to do your in-house testing. In the meantime, if you discover any issues, you can pull the submission and resubmit a new build. If you don’t find any issues, you will be ready to release much sooner. Over many app releases, this practice can save you meaningful time.

‍

‍

Knowing how long review will take is useful. Apple doesn’t provide this data publicly because of course not, but developers have long shared their review times with the community. It began on Twitter as an informal #iosreviewtime hashtag but has since been automated into the fantastic Average App Store Review Times.

Consider your IAP situation

‍

In-app purchases are a common source of rejection. They are complicated to configure and confusing to implement. Developers often run into rejections around IAP for a handful of reasons.

• IAP products not being available to reviewer: When submitting the first version of an app, the new IAP products must be attached to the submission. IAPs can be attached to submissions through the iTunes Connect new release configuration. If you are submitting a new version of an already released app, any new IAPs must be already submitted and cleared for sale, even if your version in the wild doesn’t support them.
• Improper use of sandbox vs production validation environments: Developers often get sideways when submitting an app the makes use of Apple’s /verifyReceipt endpoint. Sometimes devs will configure the release version of their app or backend to point only at the production IAP environment. Doing this fails in App Review because the reviewers use the sandbox environment for testing. RevenueCat makes this a non-issue.
• Improper legalese or meta-data: In recent months, especially when subscriptions are involved, Apple has started to crack down on the look of your in-app purchase flow. Many developers have been receiving rejections citing the Paid Applications Agreement, Schedule 2, Section 3.8(b). I wrote about it here.

Understand why you were rejected

Eventually, you will have a release get rejected. Probably many times. It is vital that you read and understand the rejections you receive.

Apple will cite a document, usually the App Review Guidelines, explaining your rejection. Read it. Then reread it. Then search around to see how other developers have handled it. Doing this will help you build a better understanding of what will and won’t warrant a rejection.

Just fix the problem

Usually, rather than fighting with the reviewer, it is easier just to do what they want. It may require some amount of pride swallowing to allow someone who has barely any involvement with your project dictate a change. Doing this will often be the fastest way to get to market.

Just fixing it works if what the reviewer is asking for is reasonable. However, there are situations where you may think the reviewer is applying a rule unfairly or is misinterpreting your app or the guidelines.

Send a rebuttal

When you receive a rejection, you will have the opportunity to send a message to the reviewer. If the reviewer simply misunderstood your app, this may be a chance for you to explain the misunderstanding.

Send a kindly worded and straightforward explanation of what the reviewer missed, and explain why you are not in violation. If it was just a blatant oversight by the reviewer, they might just clear it for sale.

In some cases, you might think that the reviewer’s interpretation of the rules is incorrect or that they are applying the rules unevenly. In these instances sending them a message rarely helps.

Don’t take the phone call

If you are stuck in a messaging loop with your reviewer, they will likely offer what seems like a way out, an invitation to “jump on a call.” Don’t take it. What sounds like an opportunity to re-litigate your rejection, will just be a rehashing of your message thread. The reviewer on the phone is unlikely to budge, only regurgitating for you the nature of the violation. It is a much better use of your time just to read the rejection and make the appropriate changes.

Re-submit a new version, try your luck

There is one last resort. If you think you’ve reached an impasse, there is no way you can compromise on what the developer is asking for you can roll the dice and hope you get a new reviewer. Doing this will require changing the major version number and re-creating your release in iTunes Connect.

I don’t recommend this unless you have no other option. Presumably, your new reviewer will have access to previous rejections and may still be influenced by the previous decision.

‍

An unnecessary evil

The App Review process is unlikely to go anywhere. We are lucky that it has gotten faster in recent years, but Apple doesn’t show any sign of letting it go. Investing a little bit of time in understanding the process, and how to work around it, will pay dividends over the long run.

‍