Sometimes you really care that your app is in the App Store on a specific date. You might think that submitting a week before is enough time, but it’s not if you get rejected. You can’t prepare for every eventuality, but there is one thing you can do that might help.
It’s a week before your launch, and you take a quick look at appreviewtimes.com. It’s been hovering around 2-3 days, so you submit with some confidence that you’ll be reviewed in time.
A few days pass and you are still “Waiting for Review”. You know the drill, so you don’t panic. Still, it’s disheartening when you get rejected a couple of days later.
“Why can’t Apple reject us faster,” you wonder. Or why don’t they “tell me the exact problem” or “tell me all of the problems at once”. “Did they even look at my actual app?”
I know. I’ve been there. Last year, I helped out a local conference by writing their conference app. We submitted with what I thought was enough time. Then I got rejected. Twice.
To be clear, the rejections were my fault. In the rush I didn’t fill out the app record completely. Also, they didn’t tell me I had two problems to fix on the first rejection, which is very frustrating, but I have no one to blame but myself. The good news is, we got accepted in time. But, I learned my lesson.
I started feeling less frustrated by Apple when I started to think of them like weather. Sometimes, it’s nice outside and everything is fine. But sometimes we get hurricanes. You can’t reason with a hurricane, and there’s no reason to get mad if it doesn’t understand you.
Like weather, there is a reasonable explanation for everything that happens. But you can’t affect weather, and weather doesn’t care what’s convenient for you.
If you care about being in the store on a specific date, don’t count on a fast review time or that your app won’t be rejected (even though the vast majority are accepted quickly).
I’m not just suggesting the obvious thing like submit early—of course you should do that.
You should also do trial submissions before you are completely done. In iTunesConnect, set your app to need manual release, and submit apps that you never intend to release.
The reason you are doing this is to see if there are any obvious problems. This is much more important for new apps as you might find out that your specific In-App Purchase doesn’t meet a guideline—you want to know that as early as possible and the only way Apple will tell you is to submit an app.
Just remember, you need to submit apps that look complete and definitely do not crash. But, that’s a low bar—you can submit apps where there might be some minor design work left, or where parts of it aren’t done yet. We’re talking about an app that is six weeks from being ready to release.
Again, most apps are not rejected, so if you think yours is edging close to the guidelines, then double-down on submitting early and submit the minimum app that implements the controversial feature. Call it out in the app description and the note to the reviewer.
Being accepted doesn’t mean you won’t get rejected later, and all of this won’t even be something you can use to convince Apple later (you can’t convince a tornado to stop throwing cows around). A release a year later can be rejected for exact features that were accepted in the past (even if the guidelines haven’t changed).
But, you can know earlier in the process that something you want to do will never be accepted.