Under the Radar

21: App Store Rejection


00:00:00   Welcome to Under the Radar, a show about independent iOS app development.

00:00:04   I'm Marco Arment. And I'm David Smith. Under the Radar is never longer than 30

00:00:08   minutes, so let's get started. So today we wanted

00:00:12   to talk a little bit about App Review and

00:00:16   specifically avoiding App Store rejection. I've run into some

00:00:20   recent challenges with App Review and this is just sort of par for the course

00:00:24   and it seemed like a good opportunity to talk about this. Like, it's

00:00:28   And as much as it's easy and nice and fun to talk about the building an app process,

00:00:33   like the part of actually designing it, implementing it, testing it, and even in some ways even

00:00:39   like submitting it, that process, like at some point your app is going to go through

00:00:44   the app review process if you're an iOS developer.

00:00:48   And there's a very reasonable chance that at some point one of your apps is going to

00:00:54   be rejected.

00:00:56   And it's probably worth saying that this is very common.

00:00:59   Like I've been rejected many times over the years, I've been doing this for seven

00:01:03   years, and it isn't like, you know, so somehow when I get rejected, it's always a bit

00:01:08   sad and complicated, but it isn't something that's like life-shattering and like, "Oh

00:01:14   no, this is terrible," because, you know, it's a process and you can usually work

00:01:18   your way through, like, with a very few exceptions, almost all the times I've had an app rejected,

00:01:23   I end up working with App Review, it's either a misunderstanding or I just need to change

00:01:27   something small and subtle in my app, and you can work your way through.

00:01:32   But there's a lot of things that you can probably do to avoid it in the first place, and then

00:01:36   just sort of some things that I think we're going to talk about too of things to--how

00:01:40   to respond in an appropriate and constructive way when things don't go quite your way.

00:01:46   Because it's a big part of the process, and it's also certainly something you want to

00:01:49   keep in mind when you're planning your release, especially if you're trying to release something

00:01:54   with a specific date in mind, I think right now Apple quotes that 98% of new apps are

00:02:00   reviewed within five days right now, on their support website, which I say, take them at

00:02:06   their word, that's probably true. But that doesn't mean that once you submit, your app

00:02:11   will be ready in five days, because every time you get rejected, you kind of have to

00:02:15   to restart that clock, and so I tend to expect things

00:02:19   to take at least two weeks, like 14 days,

00:02:23   to be, you know, from when I submit it

00:02:24   to when it will be ready for the store,

00:02:26   and by and large, unless, you know,

00:02:28   things are going very problematic,

00:02:30   or it's a really, really, really busy time of the year

00:02:32   that usually sort of seems to work out.

00:02:35   - Yeah, I mean, you know, this is probably a bigger problem

00:02:38   with consulting where you have to,

00:02:40   where the client wants to know, like,

00:02:41   when is this gonna be ready, and you kinda can't give them

00:02:44   a guaranteed date.

00:02:47   But anytime you're planning any kind of marketing push,

00:02:49   which you probably should be with almost any kind of app

00:02:51   you make these days, it is kind of a problem

00:02:53   to not know when it will actually be released.

00:02:56   And if you can have everything kind of uncommitted

00:03:01   and just kind of in draft mode with all your marketing

00:03:04   and everything, then you can just release it

00:03:07   whenever you get approved or within an ideal day

00:03:11   of if you wanna wait 'til it's not a weekend

00:03:12   wait till it's not midnight or whatever,

00:03:14   that's probably a better idea.

00:03:16   But otherwise, if you have to commit

00:03:19   to a firm date to somebody, the only real way to do that

00:03:23   is to set the app for hold for developer release

00:03:26   and get it approved first and then set a date.

00:03:31   And of course, that's very time consuming,

00:03:32   'cause then you have to basically write the entire app

00:03:35   like maybe a month before you wanna actually release it

00:03:37   because you have to allow all these paddings for everything.

00:03:40   And so I think it's just, you know, anything you can do both for your client if you're

00:03:44   a consultant or for yourself if you're not, and anything you can do to kind of reduce

00:03:49   people's expectations of having a precise release date for an App Store app will help

00:03:54   you there because that's the reality of what we're dealing with here with App Review.

00:03:59   And it's always been that way and it's always been, you know, it's always been you can get

00:04:03   it released within a week most of the time, but not all the time and you can't guarantee

00:04:09   that and it might be longer, you know, and you can't even say, oh, well, maybe we'll

00:04:13   get rejected once and then second time we'll get through. You can't even say that because

00:04:17   second time, you know, first of all, it might take longer. There's occasionally times where

00:04:21   you get stuck in a preview for weeks and you don't really know why and maybe you got like

00:04:25   email developer relations to have them kick it for you and get it going again or something

00:04:29   and sometimes things require manager review if you're like kind of on the edge of something

00:04:33   which we'll get to. So there's, you know, you can never really be sure how long it will

00:04:38   take. And so anything you can do to not depend on that, or to not guarantee that to anybody

00:04:43   else, the more you can do that the better.

00:04:46   Yeah. And it's just sort of part of the process. And it's probably one of the things to keep

00:04:49   in mind with, like, the number one rule of app review in some ways is to, like, keep

00:04:53   calm and try and not have it be a pressured thing, which is very much easier said than

00:04:59   done. And I'm speaking that from very specific experience where it's hard to not be calm,

00:05:05   anything you can do, like you're sort of like to take pressure off that process, to have

00:05:09   it not be like, "But I have to have this out by this particular day." Like that is a, like

00:05:15   asking for trouble because this is the process we have. Like App Review exists for a purpose,

00:05:20   you could disagree with that purpose or not, but like it exists, this is the, like these

00:05:23   are the rules of the store, and so it's just something that we have to, as developers,

00:05:28   keep in mind and plan accordingly.

00:05:29   - Yeah, it's not going anywhere.

00:05:31   Like if you're sitting, I mean,

00:05:34   even the most hardcore developers

00:05:37   who were really super against the idea of the App Store

00:05:39   in the early days, I don't know anybody

00:05:42   who is still fighting the fight of saying,

00:05:44   there shouldn't be App Review.

00:05:46   Everyone fought that fight in 2008,

00:05:48   and I don't think anyone is still expecting that to change.

00:05:52   And ultimately, I like the idea of App Review,

00:05:56   and I usually like the implementation of it.

00:05:58   there are parts of it that I think need to be reconsidered

00:06:02   or need to be improved, but overall,

00:06:05   the concept of App Review and most of the execution of it

00:06:09   I think is actually beneficial to both us and our customers.

00:06:13   And as an App Store customer also,

00:06:15   I appreciate that it's there.

00:06:17   - Exactly, 'cause it's, you know, its goal is to try

00:06:20   and maintain sort of a certain, like,

00:06:22   be this line in the sand to try and say, like,

00:06:25   you have to meet this bar.

00:06:27   And we can argue about where that bar is, but yeah, I'm very glad that there is a bar,

00:06:32   and both it's helpful as a developer to have a goal in mind.

00:06:36   And I think in general I wish the bar were a bit higher in a lot of cases, but it's the

00:06:42   bar that exists that we have to at the very least reach.

00:06:47   So let's probably start talking about that bar.

00:06:51   And there's a couple of links we'll have in the show notes about this.

00:06:53   Like Apple is pretty helpful in terms of their documentation about app review, about what

00:06:58   to expect, and they have a really helpful page that if you haven't looked at, you're

00:07:02   kind of doing this wrong, of common app rejection reasons.

00:07:07   And they have a page where they list out like what are these most common reasons, and they

00:07:11   even include at the bottom like for certain periods of time, they'll say what the most

00:07:16   common reasons were for app rejections.

00:07:18   But before we get into those, the first thing you always have to do when you think about

00:07:22   app review is read the actual app review guidelines. Like, if you haven't read the rules, there's

00:07:28   really no way that you could reasonably expect for your app to pass review except by luck.

00:07:34   And there's a lot of them. I counted them up in preparation for today's show, and there

00:07:38   are currently 182 app review rules, and they're broken down into all kinds of different categories,

00:07:45   they're all different kinds, like there's ones that are functional, there's ones that

00:07:47   that are more privacy related.

00:07:49   There's ones that only apply to certain apps.

00:07:52   So if you're a health app, there's

00:07:53   certain rules that apply to you.

00:07:55   If you're a insurance company, there's certain rules.

00:07:59   There's all kinds of very-- some of them are very specific.

00:08:01   Some of them are very broad.

00:08:03   And it's one of these things that periodically you

00:08:04   should probably just read through the app review

00:08:07   guidelines and make sure that you at least know vaguely

00:08:09   what's going on there.

00:08:11   It's because ignorance of the rule

00:08:13   isn't going to be a particularly useful defense if app review

00:08:16   back and says, "Hey, you need to change this." And you're like, "Oh, I didn't know." It's

00:08:20   like, well, it's in the guidelines. But on that page, the most interesting thing that

00:08:27   I see that when they break down the typical reasons that people get rejected, at least

00:08:34   a quarter of them are in some ways entirely avoidable. So 14 percent, they said, of app

00:08:40   projections happen because the developer did not provide enough information. That's like

00:08:45   the catchall, more information needed, which I would take to mean you didn't do something

00:08:52   complete in your App Store description or your screenshots, or you're doing something

00:08:57   funny that they need more clarification on, which is, just as a side note, when you submit

00:09:03   an app, there's a little box that says Reviewer Notes. If you're not putting anything in there,

00:09:08   probably sort of doing it wrong because that's your opportunity. If there's anything that's

00:09:16   weird or edge casey or that your reviewer could get confused by, you can write a little

00:09:21   note and the reviewer will read it before they look at your app. And so anytime you're

00:09:27   doing anything that could be problematic, kind of preempt that by saying, "Hey, I'm

00:09:32   doing this in this app, maybe if it requires a certain kind of permission, you can explain

00:09:39   why it requires that permission. So in Podometer++, I have a little note that I usually submit

00:09:44   along with it that says it requires motion tracking permission, and that's what it uses

00:09:49   to count your steps. If you don't provide this information, it shows you an informational

00:09:52   screen in the app indicating that it needs that permission in order to gather the data,

00:09:57   or something like that. But like 14% of app projections are because you didn't provide

00:10:02   enough information. And then another 10% are apps that exhibit bugs, which is typically,

00:10:09   in this case, I think, crashes, is probably the biggest category of bugs. But like, that

00:10:15   ultimately, if you're submitting an app that's crashing in the brief window that the app

00:10:20   reviewer is looking at it, like something's got missed in QA, probably, because they're

00:10:26   really not, it's not the kind of bug that they're going to be importing 10,000 records

00:10:30   into your database and really working, like pushing your app to the limit. I expect they're

00:10:35   probably sitting down with your app and using it for five minutes at most. And so if it

00:10:40   crashes in that first five minutes, you've probably done something not quite right in

00:10:45   your testing phase. You should probably have been able to replicate the crash that they're

00:10:49   having in the first place.

00:10:50   - Yeah, I mean, and this is one of the reasons why

00:10:54   app review is so good for everybody,

00:10:58   because, yeah, I mean, there are lots of crashes

00:11:01   that get through review and that ship to customers,

00:11:03   but I know a lot of developers, myself included,

00:11:07   who app review has saved us from accidentally shipping

00:11:11   something that would have affected a lot more people.

00:11:13   Like, you know, they test a lot about the app.

00:11:16   Like, you know, for instance, like if your new user

00:11:20   or login process is broken and you ship a bug fix update

00:11:24   that you think it's just a bug fix

00:11:25   and you don't test new user logins

00:11:27   because you didn't hit that during your hour of testing

00:11:30   on your own phone, they will hit that

00:11:33   and then you don't accidentally break the app

00:11:35   for all of your customers during the next week

00:11:38   while you can get another bug fix out.

00:11:40   So this is like, the guideline where if your app crashes

00:11:45   or exhibits obvious bugs during review,

00:11:47   you will definitely get rejected.

00:11:48   that is great, and I think that's totally unarguable

00:11:52   whether that should be there or not.

00:11:54   - Exactly, yeah.

00:11:54   Like, that's the kind of, and it's,

00:11:56   I will, like, it certainly happened to me too, yeah,

00:11:58   where you, it's a lovely thing where they'll catch something

00:12:02   that you just, it's usually not hard to recreate,

00:12:04   but it's just a situation that you may not,

00:12:06   you may have missed.

00:12:07   Like, it's on a particular device,

00:12:10   or like on a fresh install on a particular device,

00:12:12   you'll have an issue, or things like that.

00:12:15   And it certainly is a nice thing that it's like,

00:12:16   there's this last sort of sanity process.

00:12:19   Definitely don't rely on it as a QA process.

00:12:21   App Review is not QA.

00:12:23   It's not like, oh, I don't need to worry about doing basic QA

00:12:27   because App Review will find it.

00:12:28   That is entirely the wrong way to look at it.

00:12:31   It's more like it's this last chance

00:12:33   to catch a bug that may otherwise get through.

00:12:39   But once we're through, kind of like those first two,

00:12:41   like you just didn't provide enough information to Apple,

00:12:44   or there's obvious and glaring bugs in it.

00:12:48   Well, then we start to get into rules and things that

00:12:52   become much more squishy.

00:12:56   Things like rule 10.6 is one of these,

00:13:00   "Apple and our customers place a high value

00:13:02   on simple, refined, creative, well-thought-out interfaces.

00:13:07   They take more work, but they're worth it.

00:13:08   And Apple sets a high bar.

00:13:09   If your user interface is complex and less than very

00:13:13   good, it may be rejected.

00:13:16   - Yeah.

00:13:17   - And like 6% of apps are rejected

00:13:19   for not meeting that criteria.

00:13:21   - I wonder, I'd love to see those 6%.

00:13:23   Because if you look at what's in the store,

00:13:26   I would describe many apps that I come across in the store

00:13:30   as having UIs that are less than very good.

00:13:33   (laughing)

00:13:34   So you gotta wonder what else they're seeing

00:13:36   that gets that 6% rejection.

00:13:38   'Cause this is one of those areas

00:13:39   where I would love for the bar to be higher.

00:13:41   - Yeah, exactly.

00:13:42   There are some of the guidelines that are negative, and there are some that are almost

00:13:49   more positive, more aspirational.

00:13:51   I like the concept of this rule, and I like the way it's written, even.

00:13:54   I think that's a really good thing, and being more strict on that is certainly something

00:13:59   that could be helpful.

00:14:01   But it's certainly something to keep in mind, that yeah, Apple is going to look at your

00:14:05   app, and if it really is just kind of shoddy and thrown together, there's a good chance

00:14:10   that it'll be rejected as a result.

00:14:12   And so, you know, like, work hard on your app,

00:14:16   make it look good, you know, try your best.

00:14:17   Like, especially in iOS, since like the iOS 7 stuff,

00:14:20   like a lot of these things are much easier to do

00:14:23   than they may have once been,

00:14:24   to kind of make an app that looks and feels at home

00:14:27   on the platform and, you know,

00:14:29   is good in that kind of visual sense.

00:14:32   But, you know, like know that if you don't,

00:14:35   you might get called on this.

00:14:37   - Yeah, and it's, this is one of those rules

00:14:39   is that it's very hard to enforce consistently

00:14:43   by a large staff of a whole bunch of humans.

00:14:46   And this is part of the problem with that review.

00:14:47   One of the biggest problems they have

00:14:49   is just inconsistency of enforcement.

00:14:52   And we can sit here, as we have, and say,

00:14:55   we'd love for the bar to be higher

00:14:57   on the UI quality rule, but the higher they make it,

00:15:01   the more we're gonna see people getting rejected

00:15:04   for things that are arguable

00:15:06   or that they shouldn't have been rejected for.

00:15:08   and we don't like that and we blog about that.

00:15:11   So, you know, I don't know.

00:15:13   I think this is one of those things

00:15:16   where I wish the rule was more strict,

00:15:19   but if it were, it might just cause more problems.

00:15:22   - Maybe, yeah.

00:15:23   And it's probably also where it's like

00:15:26   the reality with app reviews,

00:15:27   and this is something very important

00:15:29   when you are dealing with a rejection,

00:15:31   is the understanding that the people

00:15:33   who are doing app review are people.

00:15:36   Like, they're individuals whose job it is

00:15:38   go to work every day and they sit down and they go through applications and they make

00:15:43   decisions about them, and people are flawed and make mistakes, and if they make mistakes,

00:15:48   in my experience, AppleView is very good about correcting those mistakes, but inevitably

00:15:54   there's going to be subjective decisions that someone has to make. They have to look at

00:15:58   it and it's like, "Is this good enough? Is this good enough?" Something like, if your

00:16:03   app crashes, it's a binary thing. As soon as your app crashes, it's failed from review.

00:16:08   just sort of like the rule. It's something like a, you know, a refined quality interface.

00:16:14   Like finding that line is inevitably going to be more difficult. And so just sort of

00:16:19   give App Review some grace about if we're having a mis—if you have a misunderstanding

00:16:24   with them about what that might be, then, you know, just kind of have to work through

00:16:29   that at a human level that you're just trying to convince somebody who's doing their job,

00:16:34   you know, that your app is actually good enough.

00:16:37   Our sponsor this week is Hover.

00:16:39   Quite simply, Hover is the best way

00:16:41   to buy and manage domain names.

00:16:43   It's my place of choice, honestly,

00:16:44   for registering all of my domains.

00:16:45   I go there first and I just, I stop there

00:16:48   and I buy things there because it's just really good.

00:16:50   It's well designed, it's hassle-free,

00:16:53   it's very respectful of you and your time

00:16:55   and your money and your privacy.

00:16:57   Hover is great for buying domains.

00:16:59   They have all the big TLDs, all the top-level domains

00:17:01   that you might need, all the crazy new ones,

00:17:03   plus all the nice, you know, conservative old ones

00:17:05   that I tend to prefer most of the time.

00:17:07   And they have great prices.

00:17:10   Dot-com domains are now just 12.99 a year.

00:17:13   That includes who is privacy for free

00:17:15   along with all their other domain names that include that.

00:17:19   They also have fantastic customer support.

00:17:20   Hover has a no hold, no wait,

00:17:22   no transfer phone support policy.

00:17:24   So you can just call them.

00:17:25   This is great.

00:17:26   You call them and a human being picks up the phone

00:17:28   and that person helps you.

00:17:29   It's amazing.

00:17:30   It's like the way everything used to work

00:17:31   before everything got horrible.

00:17:32   Hover still has that today for domain registration.

00:17:35   Plus, of course, you can email them if you need to,

00:17:37   everything else, they have great support.

00:17:39   They have volume discounts for bulk domain renewal,

00:17:42   they have custom email solutions,

00:17:43   you can have email hosted there

00:17:45   or forwarded to the domain of your choice.

00:17:47   They even have an awesome new feature called Hover Connect,

00:17:49   which makes it easier than ever

00:17:51   to get new domains connected with various hosting platforms

00:17:54   to make a whole website really nice and easily.

00:17:56   So now from the domain admin panel,

00:17:58   you can select which service you use,

00:17:59   including Squarespace, Tumblr, Shopify, and many more,

00:18:02   and they will automatically configure all your DNS

00:18:04   to work with those things.

00:18:05   So no more weird copying and pasting,

00:18:07   getting the A record right and everything.

00:18:09   Hover Connect is great for getting things set up quickly.

00:18:11   So go right now to hover.com

00:18:12   and try them out for your domain names.

00:18:14   Use code REVIEW, that's code REVIEW at checkout,

00:18:18   and you'll get 10% off your first purchase at hover.com

00:18:21   and show your support for Under the Radar

00:18:23   and all of Relay FM.

00:18:24   Thank you very much to Hover for sponsoring our show.

00:18:27   - And of course there are many other rules

00:18:29   that we could talk about.

00:18:31   - Oh yeah, and just like,

00:18:32   kind of like as a guiding principle,

00:18:34   Like in general, I feel like a lot of people

00:18:38   look at the App Store rules as though it's like

00:18:41   a legal contract that you can try to wiggle your way around.

00:18:45   And it's very important to consider that the App Store rules

00:18:48   are not laws, and App Review is not a court of law.

00:18:52   And while you can, like while there are parts of it

00:18:56   that kind of sound like it, like there's the appeal process

00:18:59   and everything, but it's always important to remember

00:19:02   that these rules are broad, usually, they're vague,

00:19:07   they are made to be subjectively interpreted

00:19:11   by the app reviewers and their managers,

00:19:14   and they also are not the complete list of rules,

00:19:16   and the rules can change over time.

00:19:18   So really what matters is the spirit of the rules,

00:19:21   not the letter of the rules,

00:19:23   because they're all being subjectively evaluated,

00:19:25   and you can't guarantee that if you are trying

00:19:29   to skirt around a rule by using some kind

00:19:32   technicality in the wording or interpreting something differently, that probably won't

00:19:36   work. And if it gets through once, it probably won't get through the next time you gotta

00:19:39   do an update. And so it's wise in general to just avoid being near the edges of the

00:19:45   rules. You know, avoid relying on things that are almost disallowed or almost against the

00:19:51   rules but you're living on the edge because it's going to bite you eventually. You know,

00:19:56   again, you might get through this time but then when you need to submit an urgent bug

00:19:59   bug fix, that might get rejected for something the first version passed for. That wasn't

00:20:04   even included in the bug fix, but it just so happened, "Oh, your login screen plays

00:20:08   weird tricks that are kind of against the rules, so we're going to reject this important

00:20:11   bug fix." So generally speaking, this is not a place to try to play fast and loose

00:20:17   or try to live on the edge of a certain interpretation of a certain rule, because that's not how

00:20:22   this works.

00:20:23   >> Yeah, exactly. And especially when you start to get into the next most popular reasons

00:20:29   that people are rejected, start to become things that are very obvious that aren't good.

00:20:34   They tend to start to get into things around being fraudulent or misleading, not dealing

00:20:39   with people's personal information correctly, having misleading or inappropriate trademark

00:20:44   violations. Things that are kind of obvious and problematic. And if you're doing those

00:20:49   things, you really are in trouble. The place to push the boundaries in your application

00:20:53   is not on the policy side, it's almost certainly going to be on the technology side, doing

00:20:59   something new and interesting functionally rather than trying to find some new way to

00:21:05   game the app store. Because like you said, Apple at any point, it's a very one-sided

00:21:11   relationship and you could argue back and forth about whether that's a good thing or

00:21:14   not, but at the end of the day, if Apple doesn't like your app, they don't have to publish

00:21:18   it. It's not a situation that even if you and your heart of hearts could think this

00:21:25   app belongs on the App Store, if Apple disagrees, that's the way it is. And by and large, I

00:21:31   think they're fairly good stewards of that power, but ultimately that's the reality.

00:21:36   And so trying to do things that are gaming or being aggressive against the rules is just

00:21:43   never going to work, and it's just not productive.

00:21:45   Yeah, you basically you can't rely on getting away with it.

00:21:50   You know, like they like if you think you can get away with

00:21:53   things and other, you know, other parts of your life,

00:21:54   because you can live on the edge of rule or you can find a

00:21:57   little loophole. Apple doesn't care if what you do technically

00:22:02   is allowed by the wording of a certain rule. If it violates

00:22:06   what they believe to be the spirit of the rule, you're

00:22:08   going to get rejected simple as that and you can complain as

00:22:11   much as you want. You can you can blog about it. You can get

00:22:14   press about it, but ultimately, yeah, they make the final call

00:22:19   and you just have to accept that and you can argue about it,

00:22:24   but that arguing about it won't usually get your app back in

00:22:27   the store unless it's really truly arguable and they are

00:22:32   undecided internally about what the policy should be and then

00:22:35   you can argue for certain things to be changed like when

00:22:37   things are new and they're still figuring out the rules

00:22:39   around certain things, but stuff like the 30% cut and

00:22:41   trying to get around that, which everybody wants to try

00:22:43   around these days trying to have like an app purchase through your website that's not running

00:22:48   through their system and everything like stuff like that the rules pretty the rules are pretty

00:22:52   clear and you you won't skirt them by some technicality exactly and so lastly I think

00:23:00   the place to talk through is the process of when you get rejected what that's like and

00:23:06   then maybe some recommendations around like constructive approaches to it you know and

00:23:12   And so you submit an app and you put it out in the App Store, and it goes into waiting

00:23:17   for review as its status, and then eventually it'll pop over in review, which is always

00:23:22   very exciting.

00:23:23   >> JESSE EISINGER-HAWKMANN It's terrifying.

00:23:24   >> ANDREW WARNER Terrifying, yeah.

00:23:27   You could use that word, it's very similar.

00:23:29   So you're in this terrified state, just waiting for--and you probably should have the iTunes

00:23:35   Connect app installed on your phone, and in that you can turn on push notifications, so

00:23:39   You can be really aware of if anything's happened with your app.

00:23:44   And then you're hoping for, it'll probably come back to processing for App Store or pending

00:23:49   developer release if it's been approved.

00:23:51   That's like, those are the good ones.

00:23:53   Or you may get, your app has been rejected.

00:23:56   Which is a bit of a harsh thing that can mean a lot of different things.

00:24:00   It could be rejected, there's what's called metadata rejection, which is the app is fine,

00:24:05   but there's some issue with your screenshot or description, or something along those lines

00:24:09   or your keywords aren't quite right, or those types of things where it's more of a very

00:24:13   minor fix, like you don't have to resubmit your app, you can just change the metadata

00:24:16   and resubmit. But when it happens, usually the app will provide you a reason in what's

00:24:24   called a resolution center in iTunes Connect. And usually they'll cite a rule, like I've

00:24:30   pretty much always had a rejection that always ties back to some rule. Sometimes the rules

00:24:34   are the very sort of catch-all rules, sometimes they're very specific. They'll say, "This

00:24:39   This is the rule that you violated.

00:24:42   They give you a one or two sentence description about your specific violation, and then they'll

00:24:47   usually give you a couple of sentences about what you'll need to change, if anything could

00:24:52   be changed, to be in compliance with the rule.

00:24:56   When this happens, number one advice, and this is hard-fought advice that I've learned

00:25:00   over the years, is the first thing you need to do is calm down.

00:25:05   It's so easy, at least for myself, for this to be a very emotional thing.

00:25:11   It's kind of like when you read a one-star review in the App Store or something like

00:25:14   that, where it can be very emotional, like you can become very attached to your software,

00:25:17   and then suddenly someone is saying they don't like it.

00:25:20   It's rejected.

00:25:21   It's a pretty harsh thing.

00:25:22   And so you kind of have to just take a step back, take a deep breath.

00:25:25   You don't want to just immediately go to the resolution center, open that up, and start

00:25:30   yelling and screaming and saying, "I can't believe you did this."

00:25:34   reality is you need to be professional. You need to be polite, understand that there is

00:25:39   just someone doing their job at the other end of this, so being polite, considerate,

00:25:43   patient, like writing in full sentences with not full all caps. These are things that are

00:25:49   probably going to help your case, because shouting at them isn't going to help your

00:25:53   case. Being clear and constructive might be, or at least will help. And the thing that

00:25:59   I found most helpful too is to take a step back and try and put yourself in the app reviewer's

00:26:05   shoes and see why they rejected you. Like if it isn't immediately obvious, like if obviously

00:26:09   if they just said like your app crashed, that that's not a big surprise. But if you're on

00:26:14   one of these things where it's more subjective, just being like, well, you're wrong, like,

00:26:19   that's not what I'm doing there. Or that's different or you're, you know, that rule is

00:26:22   stupid. None of those are going to help. But if you can understand why they're doing it,

00:26:25   like where they're coming from, what the spirit of that rule is probably around, and frame

00:26:30   your response to them accordingly, you probably have a much better chance of kind of clearing

00:26:37   it up and just sort of having it be a misunderstanding that gets fixed, rather than being like a

00:26:42   confrontation that just began.

00:26:45   And beyond that, you just kind of have to work the process.

00:26:47   Like it'll take time, you write them a message, and then within a few hours, a few days, you'll

00:26:52   get a response back.

00:26:54   If you need to, you can go to the app review appeal board, which I think would take even

00:26:59   longer if you really are pushing up against something that is kind of gray in the policy.

00:27:04   But in general, you just kind of have to keep calm and just work the process and understand

00:27:10   that it happens.

00:27:12   It's nothing personal in that way.

00:27:15   It's not like, "Oh man, you're a failure.

00:27:17   Your app was rejected initially."

00:27:18   I've had a lot of apps, many of whom went on to be very successful, that their first

00:27:22   submission was rejected for all kinds of reasons.

00:27:26   And so it's just part of the process.

00:27:28   Keep calm, be respectful, and it'll probably

00:27:30   work out okay in the end.

00:27:32   - Yeah, I mean, 'cause we all go through this.

00:27:34   Everyone gets rejected, and even,

00:27:36   not just your first version,

00:27:38   updates can get rejected for all sorts of reasons too.

00:27:41   And I mean, my apps get rejected all the time.

00:27:43   Probably, I would say, maybe 10 to 20%

00:27:47   of my submissions get rejected for some reason.

00:27:50   And that's 'cause, and it used to be a higher rate,

00:27:52   like I've just gotten better over the years

00:27:53   at trying to avoid those issues.

00:27:55   It just, it happens, right?

00:27:57   And we all deal with it.

00:27:58   I mean, right now, like, I'm on edge right now

00:28:00   against all the advice you just gave.

00:28:02   I'm not calm right now because I have a bug fix update

00:28:04   for Overcast that's been in review through a night boundary.

00:28:08   And usually what that means, like,

00:28:10   in review is fine when it lasts one day.

00:28:14   When it crosses a night boundary

00:28:15   and you are in review for multiple days,

00:28:18   what that sometimes means is they're busy.

00:28:21   But what it most of the time means is

00:28:24   you're being kicked out to a manager for something.

00:28:26   And that's usually not good.

00:28:28   I'm probably about to get rejected for some reason

00:28:30   that I consider BS, but I'm just gonna deal with it,

00:28:34   and I'll resubmit, and I'll move on, and that's life.

00:28:36   That's just being an app developer,

00:28:38   and it's no big deal.

00:28:40   - Exactly, and we just make the best of it.

00:28:44   Maybe it's an example of a place

00:28:46   where it's just part of being,

00:28:48   like you use the word professionalism or something,

00:28:51   Like this is an area where that comes very much into play,

00:28:54   that like, okay, it happens, let's just move on,

00:28:57   try and make it as unemotional as we can,

00:28:59   let's be respectful as best we can.

00:29:01   And in the end, like I said,

00:29:02   I've been doing this a long time,

00:29:04   I've been rejected many times, I've had some very,

00:29:06   I've had a lot of feelings about rejections at times,

00:29:12   but by and large, I can look back,

00:29:14   and the reason I'm still doing this,

00:29:16   seven and a half years later, is because in the end,

00:29:20   I very rarely look back at the way that App Review

00:29:22   has behaved and look at it and sometimes I'll disagree

00:29:26   with it, but I can respect it and I can understand

00:29:29   where it's coming from and that helps a lot

00:29:32   in keeping level-handed and being reasonable in this process.

00:29:36   - Well said.

00:29:37   All right, thanks a lot for listening everybody

00:29:39   and we will talk to you next week.

00:29:41   - Bye.

00:29:42   [ Silence ]