I've worked on a fair number of apps for iOS and Mac at this point. Every time I take on a client who wants an app built, I hear the same question:

How do we make sure Apple doesn't reject the app when it's done?

You can't. Everyone gets rejected.

The blunt truth of Apple's review system is that everyone will get rejected, no matter how strictly they try to follow the rules. Rejection is part of life so long as we're all forced to play in the walled garden.

(On that note, a caveat. This post is not an endorsement of Apple's walled garden approach, of any of the specific rules they've set up, or of how they choose to enforce or not enforce them. "Don't hate the player, hate the game," as they say - I am not here to advocate for this game, just to tell you what I've learned about how to play it. Feel free to share in the comments the silliest reason you've been rejected, but don't attack me for Apple's policies - I don't and have never worked there.)

The good news is that rejection is far from the end of the world.

My January mini-app project (check it out if you want the easiest way to convert photos to manageable JPGs on your mac) Photo Tamer was rejected 5 times before it was ready to be downloaded. Luckily, I persevered using the gameplan for rejection we'd developed at Foursquare.

For those of you without billions in the bank or millions of followers on Twitter to fight a rejection, you need this gameplan too.

The Rejection Gameplan

Our plan has two phases. First off, we avoid rejection by knowing how to play the game (steps 1 - 3). Secondly, when we're inevitably rejected anyway we respond effectively to it (steps 4 - 6).

Step 1: Know the rules of the game

As with any game, we can only play effectively if we know the rules. This starts day 1 of your product cycle with planning to be hard to reject. The rules that Apple uses to judge apps (or at least most of them) are posted publicly for anyone to check out. Pour yourself a wine or a kombucha and take yourself on a leisurely read through them.

Ok, done? I'm hoping you weren't too surprised. Turns out, most of the rules are here to ban things like over racism, computer viruses, or apps that steal user's data. And as for the rules that seemed to directly ban your app...

Step 2: The Pirate's Code: More like guidelines, anyways

"Ok, sure, but since app does X wouldn't that technically be a violation of Rule 32.5151.14191?"

The good and bad thing about the app review process is that humans are the ones choosing what rules to enforce at the end of the day. The good thing here is that their incentives are usually aligned with yours. Remember Apple wants apps like yours in the app store. Apple makes money off of them - both directly by taking a cut if you monetize it and indirectly because the app ecosystem drives device sales.

So check your fears if you start building the legal case against your app by finding every technicality by which it could be rejected. With only a few exceptions, Apple's app review team is actively trying to avoid being an existential threat to your app. Just know that they have some rules that are firmer than others where they will firmly reject your app. These rules group into three main categories:

1. Apps that are a danger to users. If your app can harm a user or their device or it does shady things with their data, you will probably run afoul of some rules.

2. Apps that are a danger to Apple's PR. This is mostly apps who run afoul of the "Safety" rules. This definitely includes egregiously bad apps pushing bigotry or fake medical advice. But it can also include apps that are just "edgy" enough to lead to a PR nightmare for Apple. For example, GTA San Andreas is in the app store. It probably breaks some of these rules, but it's also a 16 year old multi-platinum game so it's unlikely to get too much bad press attention. But, if you made a new game today with the same broad characters, that's when you face rejection.

3. Apps that are a danger to Apple's earnings. This is mostly the companies who try to skirt around Apple's cut of sales like Epic Games or Hey. This is usually not going to hit companies like Spotify. They definitely have a harder time in App Review than most of us, but Apple is not going to give them a hard rejection for being a competitor.

Step 3: Stay one step ahead

Now that you know the rules and you have a general sense of where Apple takes them most seriously, you can stay one step ahead of app review as you build your app.

You can do this by remembering to follow Apple's guidelines when it's feasible to do so. For example, getting user consent before sending analytics or crash reports back to your servers.

But the most important way to stay one step ahead is during submission in the "App Review Information." This is your chance to steer the app review to the "happy path" through your app. If your app has a login experience, be sure to include it here and give them the login to an account with the best, fullest-featured experience you have to offer. In your message box, be sure to outline the basic flow of the app and anything they might be confused by. For example, my app Photo Tamer lives in the menu bar, which isn't the most common experience for apps. So, I was sure to call this out in the notes field so the reviewer wouldn't be surprised:

Step 4: Plan for Rejection

Great, so you've learned the rules of the game, you've carefully designed your app so that you push the limits of the App Store's rules a little but not too much, and your reviewer is well informed and well equipped to test your app. That means you're sure to be accepted, right?

Nope. Sorry. Your app will still be rejected sometimes. You can miss something and Apple catches. Apple might miss something on one version and then catch it on the next. Worst of all, because your reviewer is a human they might just make a mistake.

Account for this possibility in your scheduling. I try to submit apps with at least 3 days lead time. If it's a new app, where the kinks are still being worked out, I try for a full week. (A decade ago, when review was slower, we would have to budget two full weeks of lead time!)

The secret weapon here is the "version release" scheduler. If you need to make sure your release happens when you want or after a certain date, you can control that here. Then you are free to submit as early as possible without having to push up any other timelines.

Step 5: Bargaining

If your app is rejected, you'll get emailed that Apple has "sent you a new message about your app" and that "you can view it in the Resolution Center." This message will include the section of the App Store Rules that you have been flagged with and sometimes will include a message from the reviewer with greater context.

For example, let's say you build an app with launch-at-login functionality. You are trying to follow the rules about user consent so you put this behind a prompt with a disclaimer, checkbox, and OK button. But because you left the checkbox checked by default, your app will get rejected citing "Guideline 2.4.5(iii) - Performance" and the reviewer will note "Your app sets itself to auto-launch at startup without express consent from the user. You can resolve this by leaving this option unchecked by default."

Womp womp.

You have three options now:

1. Give up app development, move to Iowa, become a farmer. No one will blame you for walking away from this circus where we're so beholden to these rules if we want to share our apps to the public.

2. Appeal the decision. This is usually not the right call, especially in a case like this where the issue is clear-cut and fairly reasonable. But, if you're being rejected for being a Hey or a Spotify, then an appeal (and maybe some Tweets) might be the fastest way out.

3. Fix the issue. Usually this isn't actually difficult! I'd guess a full 90% of rejections are for things that are extremely quick and easy to fix. If you want to fix this rejection as they suggest it will take you 5 seconds to switch the default from true to false. You could also switch to a different UX while meeting Apple's demands, like replacing the checkbox and "ok" button here with an explicit "allow" and "deny" button pair.

Step 6: Try Try Again

Make your fix, build it, and resubmit. Then come back to resolution center and send a brief message back to the App Review team with:

1. What you changed (or didn't change).

2. How this resolved the issue they flagged.

3. How they can confirm this.

It's as easy as that. I've seen PMs send 5 paragraph essays about the morality of the Human-Interface-Guidelines and then at the end tack on "oh and we made the change you wanted." Don't be like that. Keep it short and sweet and you will get a faster review turnaround time.

Sweet Release

If all has gone well, your app is now "Pending Developer Release". It might even have been automatically released while you were reading this. Congratulations.

I do wish we lived in a world where we didn't need blog posts to explain the playbook for getting approval from a trillion-dollar company, but here we are. Hopefully this guide will help you, whether you're trying to calm down an overly paranoid PM or figure out how to respond if your app has been rejected.