 IndieDev Tips #9 - Dealing with App Review Rejections



Subscribe to our newsletter

By subscribing, you agree with Revue’s Terms of Service and Privacy Policy and understand that An indie iOS developer journey 👨🏻‍💻 will receive your email address.

 IndieDev Tips #9 - Dealing with App Review Rejections
By Edouard Barbier • Issue #9 • View online

Submitting an iOS app for review is a bit like throwing a rock (or yourself for the bravest) in a dark well. You don’t know how deep it will be, you don’t know if it’s going to be muddy, full of clean water or if it’s a death trap. 
In my almost 7 years of experience shipping apps on the AppStore, I have dealt with a fair share of rejections. So much so that I started to expect them, especially when launching new apps. 
Today I wanted to share a few tips that have helped me pull through when Apple decided to make my life complicated. 
Expect them or be discouraged.
Whether you like it or not, and no matter how polished you think your app submission is, you’ll face rejections. Not because your app isn’t good or you made terrible mistakes, but because Apple’s Review Team is reviewing tons of app, day in day out, their performance is most likely based on the number of apps reviewed per day and the fastest way for them to close a ticket, is to find something, anything that will let them move on to the next review. Sometimes that will mean an approval after a minute or two and the reviewer has barely had time to explore the app. Other times you’ll get a rejection.
Be ok with them making no sense.
In their quest for closing tickets, they will sometimes make mistakes or not understand what some of your app’s features do. I stopped counting the number of times I had to explain a feature, re-explain it in various ways, send annotated screenshots or screencasts to get a build approved. Don’t get annoyed if they don’t understand what you built, it’s not your UX, it’s their job and the volume of apps they look at every day. 
You’re in control, even if you think you aren’t.
App Review’s job stops in three scenarios. 
1. Your submission gets approved 
2. You give up trying 
3. You get banned from the Developer program. 
Assuming you’re not a shady developer, 3) is unlikely. 
If you decide upfront that your app is worth sharing with the world, or the new feature you’re adding to this update is going to add value to your users, 2) is not an option either. No matter how long it takes, the only possible outcome is for you to get approved. 
Just keep replying to Apple, resubmit builds and keep them working on your case. It pays off in the end. 
Master patience & reactivity.
Sometimes it’ll take 15 minutes to get an update out, sometimes I’ll take days. Just be ok with it. 
If in the middle of an exchange with App Review the reviewer stops replying to you, don’t hesitate to follow up just before the end of the Cupertino working day. If they don’t reply after one or two follow ups, just reject the build, bump it by one and resubmit for review. 
Whenever Apple does reply, be reactive. I tend to drop everything and check what they want, and reply as fast as I can. This way the ball never sits in my corner for too long and I keep them busy on my case as often as possible. That can really make a difference. 
Build yourself a gotcha list.
In some cases, Apple will have good reasons to reject a build. Shipping an app or an update is a huge undertaking and it’s often easy to overlook something obvious.
Over the years, I have faced the same problem many times with many reviewers and I’ve come to the conclusion that some of them can be anticipated. Let’s look at a few examples.
Example 1: Clearly add in your review notes where your privacy policy is located inside your app. They often don’t look very far before saying it’s not there. Even when it’s clearly obvious that it’s pretty much always in the Settings tab somewhere. They sometimes skip reading the review notes and you get rejected anyway but pointing them to information they should not have missed is often a good way to get approved. 
Example 2: If your app requires login, provide test credentials that lead to an account populated with test data so Apple can see a functioning app and not a blank app. 
Example 3: Submit new In-App Purchases or Subscriptions SKU before you actually submit your app for review, and ask them in the Review Notes to approve the new SKUs. It happens far too often that they forget to approve new price points and you end up with an update that will not be able to show your new prices which is a pain. 
Example 4: Don’t mention anything related to pricing (especially the keyword ‘free’) in your title, subtitle or screenshots or they will reject your submission with a classic Metadata issue. 
These are all mistakes I’ve made a few times until I decided to keep a list that I read through once in a while as a refresher. It can really save days to not forget any of these things. 
Ship often & ship small.
It’s way easier to ship small updates regularly and deal with a rejection while you already start working on the next feature rather than spending months on a big update and then feeling horrible when Apple makes it hard for you to release it to the world. Smaller, regular updates generally tend to be approved faster in my case. 
I hope you found this helpful. I could definitely come up with a part 2 to this topic so let me know if this is of interest to you. 
Til next time.
RT Appreciated.
If you’ve enjoyed this series so far or have suggestions or questions you’d like to see covered in the future, feel free to reply to this email.
You can also find me on Twitter @edouard_iosdev or on Instagram @edouard_iosdev.
Did you enjoy this issue?
Edouard Barbier

From ideas to design, to code : learn what it takes to make a living on the AppStore.

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue
From Earth with Love