As some of you may know, getting Yoink for iOS through Apple’s App Review was, to say it lightly, a bit of a pain.
In the end, I was able to release it, but a month late. Had this been my first app as an indie developer, there’s a good chance I would have had to declare bankruptcy now.
I am fortunate enough to have a couple of apps out already that create a steady income, but still, I spent about two months exclusively on this app, so it’s still scary thinking about how I got rejected over and over.
Long story short, here’s a couple of thoughts I’ve had during all of this.
TestFlight App Review
From the very beginning, I’ve had Yoink available to a couple of (awesome) testers via TestFlight.
Now, when you add a new app or a new version of the app to TestFlight, it has to go through a review before testers can download and test it.
My question, then, is: Why not reject the app right there if it doesn’t comply with the rules in the App Reviewer’s eyes?
If this is not checked, why have a review for TestFlight apps in the first place?
Or if that’s unrealistic for some reason, perhaps TestFlight App Review could give sort of a “likelihood of getting through the ‘real’ App Review”. Maybe on the levels of “yea, good luck with that” to “possibly, tentatively not going to be rejected”.
It would have saved me (and the App Review person) a *lot* of time and nerves had, for example, the File Provider extension been rejected right then and there for not being cloud-storage based. Or the keyboard, for not having a traditional method of input. Those are all things that could have been avoided, had TestFlight App Review caught these things.
Reasons for Rejection
Yoink was rejected for different reasons and in different areas of the app.
But those reasons were given to me one by one, one submission and “Waiting for Review” -> “In Review” cycle after another.
That’s *such* a waste of time (not only for the developer, but also for the reviewer. But *especially* for the developer).
Why not keep going after finding a reason for rejection and see if there are other issues after that? If so, the reviewer could note them all down and give them to the developer all at once, not one by one.
Notice of Escalation
When an App Reviewer isn’t sure about an app, the review is “escalated”, meaning it goes up one instance in the App Reviewer hierarchy to be reviewed by a “superior”.
That would be the perfect time to let the developer know in advance that, “look, review is going to take a little longer because we’ve run into an issue with your app. Please stay tuned, we’re working on it.”.
Not only would the developer know that it’s going to take longer for the app to be reviewed, they’d also have reassurance that the App Reviewer hasn’t forgotten about the app – anybody who had an app “In Review” for more than twelve hours knows that feeling 😉
In closing, I’d like to say that I have nothing but respect for App Reviewers. Their job is difficult and, mostly, unthankful.
But I believe a lot of grievances on both sides could be avoided if some of these suggestions were put in place.
