Apple iOS app rejection and resubmission

Lessons learnt and what happens

We’re working on a new app which we’ve been polishing and preparing for launch. Finally we decided that it’s “good enough” for a first release and ready to test in the wild further.

After our last app submissions took almost 2 weeks for approval, we were pleasantly surprised to see it only took a couple of days for it to enter review (part of Apples initiative to reduce review times https://www.macstories.net/news/apple-shortening-app-review-times/ ). In the past our experience has been that Apps enter review and then within a day or so, they are approved.

But not this time. We were rejected. If this hasn’t happened before, it may come as a surprise (it did to us), but I’m pleased to say that it’s not the end of the line.

First steps

1. First understand why you were rejected. The interface in iTunes Connect is not the easiest, but you will find reasonably detailed information on the rejection.
2. Ask questions. We had some questions for the Apple Reviewer and we found that they were very responsive (within a couple of hours) and provided us some guidance.
3. When we resubmitted with a potential patch, it seemed like we were at the “top of the queue” and the app re-entered review within a few hours.

We were rejected a second time.

Apple do a good job of providing the information on exactly why they rejected the app (which in our case was to do with a new IPV6 testing requirement), but it can take a while to translate that broad policy to the specific problem within your application. Initially we were confused by the iPad specific results they provided and that mislead us as to the cause.

After the second rejection we took the time to dig deeper and we were able to replicate the same testing environment that Apple say they are using and duplicate the same bug.

Unfortunately the issue was very low down inside the WebRTC framework.

We decided to take two approaches here.

1. Work with WebRTC to raise the bug and try rectify it there.
2. File an appeal with Apple on the basis that the IPV6 issue was not specific to our app (we can duplicate it with other apps known to be using WebRTC).

Filing the appeal with Apple was easy enough. Within 24 hours I received a direct phone call from Apple to discuss the issue and provided them with more background and information. After further review, they came back and agreed to forward it “up the line” for a potential exemption.

The good news here is that Apple’s review process seems to work — you do end up with someone to talk to and they do seem to listen, that was a positive experience.

In the mean time we managed to work with WebRTC and another group with the same bug to resolve the issue, patch our WebRTC build and resolve the issue. So we’ve resubmitted again, this time with a build that (at least on our end) passes the IPV6 test as applied by Apple. You’ll find the bug report and conversation here https://bugs.chromium.org/p/webrtc/issues/detail?id=5976

We don’t know the outcome of the “up the line” review, and in reality it shouldn’t matter now because we no longer require the exemption, but if you do find yourself in this situation here’s some lessons learnt.

Lessons learnt

1. DO familiarize yourself with the Apple Review guidelines. They are applying these. At WWDC they released this “Comic Book” version which is a neat reference https://devimages.apple.com.edgekey.net/app-store/review/guidelines/App-Review-Guidelines-The-Comic-Book.pdf
2. There’s clearly wriggle room. We could see big name apps that are known to use WebRTC that obviously didn’t pass the review guidelines (specifically they also failed on the IPV6 testing environment). If I’m uncharitable, I’d say it’s Apple showing favoritism, but I’ll give them the benefit of the doubt and suggest it shows that you can get exemptions if you can justify it.
3. While it’s frustrating in the moment when you want an answer today, the Open Source community is highly responsive, our problem was clearly acknowledged, taken seriously and people generously worked with us to help us resolve it.
4. As a whole the experience left us with a general impression that Apple wanted to help us get our app improved. Sure, they aren’t there to debug and test for us, but the rejection process was overall clear, next steps were easy to access and Apple was communicative and listened to us (but perhaps not agreed with us) when we escalated things further.

UPDATE Feb 2017: This post gets regular attention and I realised I didn’t ever follow up with the resolution. It was positive on both fronts. Our patch was successful and we now pass the IPV6 requirement from Apple. In addition, although we didn’t need it, our review came back successful as well — being able to document and show other apps with similar exemptions seemed to help, of course having patched the root cause, we no longer needed it.