Common Apple App Store Rejection Reasons

Spread the love

This is a reskinned game.” That statement could be explanation enough but there’s nothing in the App Store Review Guidelines that says that reskinned apps are outright banned. There’s only a mention of “App looks like it was cobbled together in a few days…” which doesn’t really describe all app reskins. That’s why it can’t be denied that the review process is creating a paradox. Some even say that some of the Review Board’s decisions are hypocritical. Sometimes rejected apps get through the next time it is submitted even without any changes in the code or interface. Reviewers are also notoriously known to delete keywords without even hinting that he/she “changed something” in your app.

But hey, “If you run to the press and trash us, it never helps” (that’s a direct quote by the way from the introduction of the App Store Review Guidelines). But are these rejections really done at random? As 56% of the total app rejections are actually from the common reasons for app rejections, maybe it’s time to review what can and can’t be accepted to the App Store before passing in an app for review.

 

Reasons Why App Submissions Get Trashed

Apple cites these as the most common reasons why apps get rejected:

  1. Bugs and Crashes. App performance should be thoroughly tested and any bugs should be fixed before submission.
  2. Broken Links. User support and privacy links should be alive and kicking during the review process.
  3. Placeholder Content. They’re paranoid on what you’re going to place there so better show them beforehand.
  4. Incomplete Information. Provide all information, fill in all the fields that need to be filled in, sign in if asked, set necessary configurations – in short, provide what is being asked during the submission process so that reviewers will not tell your app: “It’s not about you, it’s about your developer.”
  5. Inaccurate Descriptions. Maybe you shouldn’t put “amazing adventures” in your app description because we can’t be sure; what if the reviewer finds it boring and says: “This is not accurate!” But in all seriousness, descriptions and screenshots should not be showcased in a way that diverts from its true function.
  6. Misleading Users. Your app should be as it is advertised. Only specify features that actually exists within the app. This can be applied to emulating an app’s interface that has a different function as your app or appearing as part of brand when it’s not.
  7. Substandard User Interface. Some say that toolbars should be placed at the bottom part of the screen and that vibration should be only for alerts. Just follow Apple’s UI design tips and guidelines to be on the safe side.
  8. Advertisement. Ads should display properly. If you indicate during the submission process that your app do not use Advertising Identifier (IDFA) but it does, the app will be placed under the “Invalid Binary” status. Ads should not also be in list form especially the ones advertising other aps (since it emulates the App Store listing somewhat). Having too much or too little ads can also get your app in trouble.
  9. Web clippings, content aggregators, or a collection of links. In short, don’t make your app into a web directory of some sort.
  10. Repeated Submission of Similar Apps. This is where app reskinners can hit a snag. This guideline seem to be somewhat directed to reskinners specifically (or it could be just me). Reskins have more chance of getting through the review process if not submitted consecutively (especially those who are reskins of the same source code). This could be the reason why some submissions are specifically addressed as a “reskinned game” since it is quite similar to the past submission.
  11. Not enough lasting value. It is true that apps that offer limited functionality and content is quite disappointing, but apps that are targeted to small niche markets are also under “not enough lasting value” category. So reskinners should be careful not to select a niche too small that Apple doesn’t even consider it a market.