Incipia blog

7 Steps To Not Be Rejected From The App Store

Gregory Klein | October 12, 2017

This is a guest post by Olivier Destrebecq, who provides iOS app strategy and development for teams creating their first app (MVP or v1). Join him at the French Riviera Mobile Development meetup to grow your understanding of the mobile development world, or read his contributions to the iOS App development publication on Medium and his blog

I'm always impressed by how much control Apple has over the AppStore. It's their own, so they can write whatever rules they want. You don't like those rules, go to another platform.

The catch is, there are a lot of people using Apple's devices. So more likely than not, you want to play by their rules.

So here is my advice to get on the AppStore smoothly. When you first start your app project, go over the rules yourself. I mean take the time to read Apple's guidelines. The rules were updated after WWDC and are written in a language that is easy to understand (aka: not legalese).

It's actually not that long. Here, I'll wait for you for 5 minutes so you can read it. Go on...

Then read the page Apple created to layout common rejection reasons. Make sure you scroll to the bottom to see the fancy graph. Again, I'll wait for you.

Does anything catch your eye?

The rules are actually fairly reasonable and the only times I hear someone complain about it is when their app is getting rejected from the App Store.

There are two rejection scenarios in my books.

The first scenario: a team submitting a brand new app to the App Store and the launch is delayed because they get rejected a few times because of bad metadata.

To avoid this first scenario, the best remedy is time. The second remedy is to be prepared. So with that in mind here are 7 steps to avoid this initial rejection which ends up delaying your launch.

  1. Once you know your intended launch date, make sure you create your app in iTunesConnect at least a month before launch. Set up all the metadata as if you were going to launch right away (including images). Make sure you got rid of any placeholder string, images or link in the app.
  2. Then get your developer to run the guideline checks included in Fastlane's tool (https://github.com/fastlane/fastlane/tree/master/precheck#readme).
  3. Re-read those guidelines thinking about your metadata. Anything seems borderline? Fix it or be willing to lose a few days. Average review time varies from 1.5 to 4 days according to AppReviewTimes. Keep in mind that new apps tend to take longer too.
  4. Do more testing. If anything fails badly during a review, Apple will reject it.
  5. Provide Apple with all the information you can. Better to give too much than too little. Include a username and password if your app requires signup, make sure the reviewer will be crystal clear about what the app is intended to do.
  6. Then submit the app for review for TestFlight (Apple beta testing service) as soon as you can. This will submit your app for a mini review that will catch quite a few things.
  7. Then finally submit your first final version to Apple a couple weeks before the final release. That will give you time to fix any issues Apple might still find. Once the first review is done, the following reviews are usually quicker, so you'll still have the opportunity to submit another version before your final release.

The second scenario: an application whose business model is based on something Apple does not want.

I met someone in this particular scenario a couple of weeks back. He has worked on an application which allowed people to rate pictures. Human beings being human, they soon uploaded selfies and people started rating those.

On top of that the rating scale used was not necessarily the most flattering and once their app grew enough, Apple shut them down. With all the concern about teen self-image and suicide, Apple does not want an app which could make people feel really bad.

After talking with that person for a little bit, he admitted he knew this was borderline acceptable.

He knew the risk of being shut down. He just thought he would be ok. He's still pissed about it because he worked so hard on this project going.

The moral of the story is to make sure that when you start your project you know if you’re treading in dangerous water and be prepared. Or simply do something else.

It would be a shame to work on your app for a few months only to find out that your app will not be accepted.

So read those guidelines carefully and very early in your project, don't expect your development team to know them all.



Do you want to shorten your path to the App Store? Sign up for my 5 day idea to App Store email course to get you there faster!