Warning: This is a controversial post. 

Depiction of an Apple reviewer that rejects my app
My depiction of an Apple reviewer that rejects my app.

I’ll first note that we wouldn’t be where we are today without Apple, so yes, I am thankful for that; however, most developers agree that the App Store review process is severely broken and subjective. On one day, you can submit and be fine… the next, you could submit the same app to a different reviewer and be rejected.

Many people, including some of our readers out there, will frown upon the information that I’m about to share with you, which essentially shows you how to avoid some Apple app rejections when submitting apps for review. Others use tricks like these on a consistent basis (although probably not all the tricks, since some we’ve never even talked about until now). We’re not necessarily encouraging or condoning this behavior, but getting kicked in the nuts by Apple Reviewers consistently has led us to wanting to write about it. Some of this material could be classified as Black Hat information for avoiding iOS app rejections. Use it at your own risk.

[Tweet “We’re tired of Apple Rejections. Learn a workaround.”]

This story might sound familiar… you spend days, weeks, and months developing an app and tweaking it so that it’s perfect in your eyes. There’s a huge sigh of relief when you click to upload it to Apple, but then the anxiety starts up again as you wait… and then wait some more… for Apple to review it. Depending on the season, this can take anywhere from 1-14 days. Wanting the app out as soon as possible to hit a current trend, you grow more and more anxious each day, until finally that email arrives with the subject line:

“Your app status is In Review”

Yes! It’s about time!

Sadly, more time passes, as once the app is in review, it doesn’t mean it’ll be approved shortly. More hours and sometimes days go by as you eagerly await the next email… and then it arrives:

“App Submission Feedback”

Ugh, feedback… that doesn’t sound like an approval, and it’s not. It’s a rejection. You feel defeated as you click over to the iTunes Connect Resolution Center to see what the reviewer said. Here are some of the rejections we’ve experienced (paraphrased of course) and some are more ridiculous than others:

  • We don’t like that feature (i.e. offerwalls)
  • Your app has too many ads
  • Your app doesn’t have enough ads (i.e. you use the advertising identifier but I haven’t seen any ads yet)
  • You advertise other people’s apps in list-form
  • You used our GameCenter logo in a small part of your app
  • I’ve seen an app like this before
  • Your app is too simple
  • You mention a giveaway, but I don’t see Terms & Conditions, and you need to say that Apple isn’t involved

…and more. Those are just a handful of rejections we’ve had.

The worst part of Apple’s review process is the inconsistency. You can resubmit the exact same app a week later, and it might get approved.

What sucks about that, though, is that you’re going to have to go through the entire review process again, so you’ll have to wait another 1-14 days, and approval is of course not guaranteed. It could be rejected all over again. It feels like you’re rolling the dice every time, and it’s terrible when you’re trying to publish the app before the holiday break.

Even if you get your app approved, Apple reviewers are known to randomly delete some of your keywords that they deem are inappropriate for your app, and worst of all, they won’t even tell you. Every time you release an app, you should compare your list of keywords to what you originally submitted. You’ll often find missing words. Worse still, many claim that Apple can blacklist your app for specific keywords… meaning the keyword is still there in your list, but your app will not show up at all if people search for that specific word.

That’s shady behavior, and sometimes it’s best to fight fire with fire.

Avoiding iOS App Rejections by Tricking Apple Reviewers

What the app reviewer doesn’t know can’t hurt you… so here’s the basic principle behind this “shady” strategy:

[Tweet “Hide stuff from Apple Reviewers to have a better chance of being approved.”]

This principle can be applied to many areas of rejection. Let’s start with the most basic and easiest to apply.


Problem:

For some strange reason, you’re allowed to advertise other apps with pop-up ads, but once you advertise multiple apps (that are not yours) in a list format, Apple doesn’t like it (wtf?). The rejection will look like this:

2.25: Apps that display Apps other than your own for purchase or promotion in a manner similar to or confusing with the App Store will be rejected, unless designed for a specific approved need (e.g. health management, aviation, accessibility, etc.) or to provide significant added value for a targeted group of customers.

Your app displays apps, other than your own, for purchase or promotion, in a manner similar to the App Store, but it is not designed for a specific, approved need. This is not in compliance with the App Store Review Guidelines.

Solution:

When submitting an app to the App Store for review, only show your own apps in your “More Games” or “More Apps” section. You can do this in the ad network that manages it for you. For example, if you’re using Upsight (formerly known as PlayHaven), go into your More Apps widget and change the “Apps to Promote” section from “Advertiser Apps Only” or “Advertiser & Internal Apps” to “Internal Apps” only. Then pick 1 or a few of your apps to advertise.

upsight more games internal apps

Once your app is approved, you can change this back and start advertising other people’s apps again.

If you don’t have any of your own apps to advertise (i.e. this is your first app in the App Store), don’t show any apps, and make a note to the reviewer saying that it is empty because you don’t have any apps to show yet. Our readers have confirmed that this worked for them.


Problem:

You show “too many” ads. Of course like much of Apple’s app review process, this is completely subjective. One reviewer might be having a bad day and get annoyed with a pop-up ad and reject you for this. That same app could easily be approved by another reviewer.

Solution:

Turn off (most) of the ads temporarily. Most ad networks allow you

upsight interstitial ad pause

to pause your campaigns in one way or another. For example, with Upsight, you can find your Interstitial Pop-Up ad, click the arrow next to it, and choose “pause.” After the app is approved, you can go ahead and unpause it.

Note: Don’t hide all your ads, because then Apple will reject you for using the Advertising Identifier in your app without just cause. So show ads, but infrequently.

If the ad network doesn’t allow pausing of ads, there’s another workaround, and this is one that we’ve never talked about before…


Problem:

Apple doesn’t like [insert virtually any feature of your app here].

Solution:

Yes, we found a workaround for that (multiple actually), and this is where the controversial factor gets taken up a notch.

Utilizing our solution & code here can allow you to get many of your features, and even graphics, through Apple Review with a bit of trickery. But read and employ this strategy at your own risk. Without further ado, here’s the biggest trick of them all:

[sociallocker]The original principle remains the same: “Hide stuff from Apple Reviewers to have a better chance of being approved.” With a little bit of outside-the-box thinking, you can take this to a whole new level by essentially hiding specific features of your app or graphics or anything else you choose and unhiding them once your app is approved. Sticking to our blog’s general theme of transparency, I’m going to show you code I wrote myself that achieves this.

Please note that I am not a programmer by trade, so the code isn’t perfect, but it gets the job done:

NSDate *today = [NSDate date];
NSString *futureDateString = @"2015-01-01 00:00:01";
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:@"yyyy-MM-dd HH:mm:ss"];
NSDate *newDate = [dateFormatter dateFromString:futureDateString];
NSComparisonResult result;
result = [today compare:newDate];
if(result==NSOrderedAscending)
{
     //Hide the feature from Apple (or do nothing)
}
else if(result==NSOrderedDescending)
{
     //Show the feature (show ad, etc.)
}
else
{
}

For those of you that don’t read Objective-C, here’s what that code does:

  • It creates a date in the future that you specify (in this example, January 1, 2015 at 12:01 a.m.)
  • It check today’s date
  • If we have not passed the future date (if it is before January 1), we show one thing to Apple or hide something from them. Otherwise, if we are past the date, then we show something else.

The only downfall to this is that you need to pick a date in the future when it’s ok for the app to change over. If you pick a date that’s too soon and Apple takes a long time to review your app, the date might pass, and then this won’t work. However, if you can pick a date in the future (like 2 weeks after submitting the app for review), then it will work.

For example, you can have the code show an offerwall, which is something Apple doesn’t like, if a button is clicked once the date has passed. Before that date, you could hide the button altogether!

Update: 12/6/14 – Pro Tip: Additional Method

There’s another method to this that we didn’t get into because it’s slightly more advanced and requires the user  is using an internet connection, but we want to put it all out there, so I thought I’d add it in… plus a great reader commented about it below as well.

The strategy is based on creating a connection in your code to a file somewhere online that you can change at will. Essentially the app code reads this file on the internet instead of being stuck inside itself. That way, you can update the file whenever you want to turn features on and off, and you don’t need to create some type of elaborate back-end system. It’s a very cool strategy and useful even if you’re not trying to trick Apple or for any other shady intentions. As mentioned, the only downside is that the user must have an internet connection for these changes to take place; otherwise the code will be stuck doing whatever it is you specify if there isn’t an internet connection.

When I was debating this method, I was afraid a bunch of users wouldn’t have internet connections so this would be lost, but I think the majority of users are accessing WiFi or a data plan if they’re accessing my apps–if they weren’t, then they wouldn’t be seeing ads and wouldn’t be able to make In-App Purchases, so they’re kind of worthless at that point, anyway!

Because I used the first tactic, I don’t have code to share with you for this pro version, but it shouldn’t be too difficult to write up.

[/sociallocker]

These tricks can work for ads, offerwalls, graphics… you name it.

So there you have it. Don’t let a broken system get you down. If need be, you can always take things into your own hands (at your own risk!).

(April 2016 Update)
If you want to understand where the market is today on the app review process, please sign up below to hear when our upcoming 2016 update is posted + upcoming DEALS. Don’t get rejected because you are using the outdated methods!

Click Here to Subscribe

6 thoughts on “Hacking the Apple App Review Process – How to Avoid App Rejections

  1. Along the same lines as your idea to hide features, you could also download a config file from a website at startup – this could contain flags to turn features on or off.

    I have used something like this in the past to dynamically decide which ad networks to use, and how frequently each advert should show. In theory it could also contain useful things like in-app purchase details (you could change quantities of items, descriptions or discounts).

    This has the advantage of not needing to specify an exact date to re-enable the feature – just edit the file on your website.

    1. Totally! This is actually the other method we tried, but decided to pass because it requires the user (and Apple reviewer) to have Internet access in order to function properly. I guess you could always have the default be the “nicer version” since ads don’t show and you can’t buy IAPs without an Internet connection anyway, but agreed–using that method could be very powerful because it allows you to “switch features on & off” at will. I might just add this in to the blog post. Thanks for the comment!

  2. Funny that your post comes right when we’re stuck in that kind of issues! The 2.2 “you promote apps other than yours” is driving us crazy. We lost two weeks because of this : first time, the “more apps” campaign wasn’t on; reviewer said “it’s a bug, rejected”. We made the campaign on, resubmitted and bam, 2.2. As it was the first app on our account, we couldn’t put other apps. After two rejections we didn’t try the empty list, simply hide the button. Now that we have one live, we’ll be able to submit others with at least one of our own apps… Thanks for sharing this dudes, very instructive!

    1. Thanks for sharing… I feel your pain. So ridiculous. I’ll never understand the 2.2 rejection. It’s completely insane since we’re allowed to advertise other apps with interstitials. But yeah, you most likely could’ve worked your way around the first rejection by telling them that the list will populate once your 2nd app is approved… but I’m glad you finally got it through one way or another.

  3. I have resubmitted my 1st app after the app failed due to 2.25 (showing games not my own)
    I resubmitted and left a note that more of my own games would be avaialbe in the “more Games” button…..right now in my app…if you press the “More Games” button…nothing happens.
    If I wanted to hide the “More Games” button instead…as to avoid the rejection of an empty list…how I do hide the “More games” button altogether?

    1. That’s a tough question, because every code is different and it depends on how it’s set up. If it’s one of our source codes, you can leave a message in the Udemy course and we’ll figure out how it’s done for that specific code. If it’s someone else’s code, I’m not sure I can give you a generic answer to that question without diving into the code myself. I could be wrong–I’m not totally versed in programming, but I’m pretty sure it’ll be too difficult to explain and probably incorrect. Hopefully that note you left for the reviewer will make them approve it! Although with Apple’s craziness, it could go either way. :\

Leave a Reply to Justin Malik Cancel reply

Your email address will not be published. Required fields are marked *