
Common App Rejections - kmfrk
https://developer.apple.com/app-store/review/rejections/
======
bfarrellforever
Here's what happened with an app I was working on: I was working for a startup
with another vendor who has some great experience making iOS apps and our
client was a TV network. We offered full streaming episodes in the app. Like
you'd imagine, the network wanted to protect the streams so nobody can steal
the content. So, we encrypted the streams and had an authentication mechanism
(which Apple recommends anyway)

Come launch time, the app was solid, clients were happy and we submitted to
Apple.

Rejection #1: You must have low bitrate audio only streams for the content.

WTF? Who wants to watch audio only TV? Oh well. Added a new encoding profile.

Rejection #2: You must have low bitrate audio only streams for the content.

What? We did that. We had back and forth with Apple for months. Stakeholders
are getting pissed off. One of the higher ups steps in who apparently has
enough clout to reach out to a real person at Apple.

The real reason for the rejection was that they watched what streaming URLs
were being loaded, tried them out and they didn't work. Yah, they didn't work
for them because they were encrypted/protected. As a result we got a form
letter rejection complaining about the lack of a low bitrate stream

~~~
BSousa
I've worked in a music app that did something similar to what you are doing
(encrypting the content). It was approved without any issue (along with
various updates).

Are you sure the new encoding profile is really low bitrate (as in, playable
in less than 3G connection speeds?)

I'm not sure what is our lowest bitrate, but according to HTTP Live Streaming
page (
[https://developer.apple.com/library/ios/documentation/networ...](https://developer.apple.com/library/ios/documentation/networkinginternet/conceptual/streamingmediaguide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html)
) it should be 64kbps or lower:

'In addition, you should provide cellular-capable clients an alternate stream
at 64 Kbps or less for slower data connections. If you cannot provide video of
acceptable quality at 64 Kbps or lower, you should provide an audio-only
stream, or audio with a still image.'

~~~
bfarrellforever
At first, yes, we were definitely in the wrong. according to this directive we
weren't aware of. We didn't have the low bitrate stream. But after we got
rejected the first time, we fixed that and continued to be rejected. Once we
got a hold of someone real at Apple they admitted the mistake and that's when
we found out that they were trying to test our streams and giving us the form-
letter rejection.

------
willu
Our app requires you to log in to do anything. We've supplied a test account
to the review team and they have never once bothered to log in but have
approved dozens of updates. I guess our splash screen meets their quality
guidelines? It seems silly that we have to wait 1-2 weeks to push an update if
there's no real review going on.

~~~
beagle3
Is it possible that they registered a different account (without an @apple.com
address?)

Had I been a reviewer, I would have.

~~~
willu
You can't register an arbitrary account because it's tied to your employer's
payroll system. They'd need to use the account we gave them and never have.

------
eli
I once got rejected for having code that accesses the Ad ID when there were
(at the time) no visible ads. We sell our own ads directly and when there's
nothing to serve, the app just has no ads. We had to start running crummy
network ads in order to get the app approved. Such a strange requirement.

I mean, if I wanted to abuse that Advertising ID for nefarious purposes I
would just do it in an app that also runs ads. Seems like security theater.

~~~
Gorbzel
There are a few good comments in this thread, but then this one...what a joke.

Let's recap: Advertiser sells ads, doesn't run ads on App Store submitted
version, complains that they had to run ads so Apple could verify what the ads
are,...?

I'd rather Apple put this app through its places 100x through rather than let
a nefarious ad machine through.

~~~
AriX
You're misunderstanding what the OP is saying. He/she is pointing out a
logical fallacy in the App Review rules.

Developers are allowed access to something called an "advertising identifier"
which lets them track users between apps, for the purposes of targeted
advertising. Apple is very restrictive in terms of user identification, in
order to protect users' privacy, so this is the only way to uniquely identify
a user/device, and the user can optionally opt-out of the advertising
identifier entirely.

Apple doesn't want developers to use the advertising identifier for things
other than advertising. But the way they enforce this is simply by requiring
that an app include ads in order to use the advertising identifier. If you use
the advertising identifier and your app doesn't visibly include ads, it will
be rejected.

This restriction is ostensibly intended to prevent developers from abusing the
advertising identifier, but really it just encourages developers to include
shitty ads in their apps, because if you include ads, you can use the
advertising identifier for whatever you want behind the scenes. It's a
nonsensical way of enforcing this policy. Thus, "security theater."

------
jn4
There is rightly a consensus that iOS Apps are generally better than Android
Apps.

IMO this is mainly because of the iOS SDK/Xcode and not due to the App Store
review process.

The review system is geared for consumer focused apps. Business Apps need
specialized domain knowledge and complex setups to review. That is why there
are so many consulting firms doing this for clients.

The review process currently just drains some resources but may really start
hurting the iOS ecosystem when business Apps become the driver for mobile
platform choice. It already is in the developing world because for many, the
phone is their only computer.

A user may really want to use iOS, but if my key problem is solved by an
Android only App - I will need to use Android.

This is one of the reasons why we ended up with Windows dominating.

iOS now has a robust sandboxing and an excellent permission system - so the
risk of an App doing harm is low. All apps without in-app purchases should be
automatically approved. Approvals can always be revoked later if issues
surface.

~~~
cageface
In my experience this is less and less the case. I think it's largely a
function of developer effort. In fact, at this point I consider a number of
apps (WhatsApp, Wechat, Zalo, Viber, Twitter, all of Google's apps) to be more
usable in their Android incarnations than they are on iOS. This is partly to
do with the greater degree of platform integration Android allows and, I
suspect, the fact that it's just harder to introduce crash bugs in Java than
Obj-C. Text entry on Android is currently vastly superior thanks to Google's
very good stock keyboard and the plethora of excellent third party keyboards.

iOS is clearly ahead when it comes to anything having to do with multimedia
but for a very large class of apps these days it's either a tossup or a win to
Android. iOS 8 will probably close the gap to some degree because it allows
devs to hook into the OS to a degree that was never possible before but I also
expect Android apps to improve now that people can afford to ignore 2.x and
the baseline for cheap phones has been raised by the Android One program.

~~~
gurkendoktor
> it's just harder to introduce crash bugs in Java than Obj-C

I am not convinced. ObjC pointers are _a lot_ safer than C pointers under ARC,
and sending messages to nil won't even crash. It's almost more likely to have
bloody AutoLayout crash your app :)

~~~
deong
ARC is still awfully fiddly. Between all the bridging casts that are often
necessary and the interaction with strong/weak/etc. modifiers you can put on
properties, it's really easy to crash or leak memory with ARC. It's an
improvement I guess, but I'm not sure it's much of one, because it lulls
people into thinking they don't need to understand the underlying reference
counting.

~~~
gurkendoktor
I agree that it's terrible in theory, but it I've rarely had a memory bug slip
into the App Store. Would love to see statistics from HockeyApp or others on
reasons for app to crash.

I've only found statistics about the _number_ of crashes:
[http://www.forbes.com/sites/tomiogeron/2012/02/02/does-
ios-c...](http://www.forbes.com/sites/tomiogeron/2012/02/02/does-ios-crash-
more-than-android-a-data-dive/)

------
bhaumik
"If your app doesn’t offer much functionality or content, or only applies to a
small niche market, it may not be approved."

This reason is a bit vague. Shouldn't "Yo" (and other clones) be rejected
under this criteria? If not, what's the boundary then?

~~~
gergles
Yo was rejected. The other (bigger?) problem with the approval process having
guidelines like this is that you can just play CSR roulette and keep
submitting it until you find somebody that approves it, which is, I suspect,
what the Yo people did in the mysteriously-light-on-detail "fought it", given
that there's no substantive way to fight App Store rejections.

Sure, you have to increment the version number, but you don't have to make any
real substantive change.

[http://www.businessinsider.com/the-inside-story-of-yo-
there-...](http://www.businessinsider.com/the-inside-story-of-yo-there-isnt-
actually-1-million-in-the-bank-2014-6)

~~~
k-mcgrady
>> "there's no substantive way to fight App Store rejections"

You can appeal rejections and argue your case over a phone call. Happened to
me recently and they reversed the decision of the reviewer (who misunderstood
part of the apps functionality in relation to an app approval rule).

~~~
megablast
You can also get in touch with someone at Apple, if you have any mates or any
people from Apple work in your company.

~~~
prawn
You can contact your local developer relations person at Apple. We had a
crucially timed update get canned because the reviewer missed the notes we
included. We contacted dev relations and it was sorted out very quickly.

------
sspiff
"If your app doesn’t offer much functionality or content, or only applies to a
small niche market, it may not be approved."

I realize they have this rule to filter out the fart buttons or temporary
internet phenomena cash-ins, but this sure reads like "the users don't decide
which apps there's a market for, we do."

Most of the stuff I consider fun or useful is probably only of value to a
pretty small niche.

------
stevenh
Apple has always feigned a very strict and even preemptively cynical and
condescending attitude toward developers regarding App Store approval. In
their official statements, they always say things to the tune of "this isn't
amateur hour. You're playing in the big leagues now. If your app doesn't have
a polished feel to it, then it will simply be rejected."
[https://developer.apple.com/appstore/resources/approval/guid...](https://developer.apple.com/appstore/resources/approval/guidelines.html)

Despite this, they'll go ahead and approve apps which are so horrible that
your middle school programming teacher would have failed you if you had
created it as your first project in HyperCard. For example, have a look at
this atrocious pile of garbage, which was allowed to sit at the #2 spot in the
iOS free app charts for nearly three solid weeks earlier this year after
Flappy Bird was pulled:
[https://www.youtube.com/watch?v=7Vk1BnfJ7UM&t=1m50s](https://www.youtube.com/watch?v=7Vk1BnfJ7UM&t=1m50s)

(and no, that's not a poorly recorded video; it's showing the actual gameplay
frame rate.)

I don't think we can have an honest discussion about App Store rejections or
approvals without discussing this elephant in the room: Overly-simple,
ridiculously ugly games. In the past month, all kinds of ugly stick figure and
moving rectangle-based games have reached the top 10 of the iOS free app
charts. The creators weren't even reaching for an 8-bit aesthetic, the games
were just simply horribly made and rushed out the door. These apps were
inexplicably accepted into the App Store despite their horrendous quality.
Some examples of games which reached the top 10:

[https://itunes.apple.com/us/app/the-
line/id880338977](https://itunes.apple.com/us/app/the-line/id880338977)

[https://itunes.apple.com/us/app/make-them-
jump/id900211132](https://itunes.apple.com/us/app/make-them-jump/id900211132)

[https://itunes.apple.com/us/app/amazing-
brick/id905455244](https://itunes.apple.com/us/app/amazing-brick/id905455244)

Those games in particular were created by the same crooks (Ketchapp) infamous
for being the first to port 2048 to mobile without the true creator's
permission. I'm assuming everyone playing that clone of 2048 was shown ads
pointing to their new games, which resulted in those games being artificially
pumped to the top 10. While that is despicable in itself, what is equally as
vexing is that those hideous games were ever approved for the App Store in the
first place.

There is a massive disconnect between what Apple says regarding their review
process and what actually happens. They can say whatever they want, but in
actual reality, it's essentially random and luck-based, and dependent upon
whatever mood the reviewers happen to be in. (And apparently it helps if
you've already been successful on the App Store before. "Oh, your app looks
absolutely terrible? Well, you made us a lot of money with your 2048 rip-off
once, so it's no problem; go ahead and flood us with your worst!")

~~~
moeedm
They set an extremely high standard, but some do get through the cracks. The
upside of that is we get to see some really fantastic apps being made, that
meet Apple's expectations, which simply can't be done on other platforms.

If they didn't set the bar that high, a lot more junk would be getting
through.

~~~
zak_mc_kracken
The junk is already there, as all the articles above yours are showing.

The bottom line is that the App Store has about the same distribution of
crap/average/great applications as Google's Play Store, except that at least,
submitting an app to the Play Store is instantaneous.

------
themoonbus
"...are not ready to be distributed and cannot be be approved."

I found a typo, I'm rejecting Apple's App Rejections page.

------
softdev12
I got rejected this summer under the “too simple” guideline – which was really
shocking for a number of reasons. First, this app took me over a year to
develop and had hundreds of thousands of lines on the back-end. The frontend
UI was purposely developed to mask this complexity, which I’m sure is what the
rejection was based on; however (point two), I had just two weeks earlier had
a second app (that used the same backend) approved, and had basically the same
front-end UI. This second app was for a different use-case, which is why I had
built two apps. In summary, two near identical (99.9 percent) apps. One
approved. One rejected. Fairly capricious.

I don’t want to come off as a negative apple basher (and I’m going to provide
some thoughts on how they can improve their process), but in my opinion,
Google is about a thousand times more developer friendly than Apple. I won’t
go into full detail about how many times I was on the phone with customer
support about problems solely due to Apple. However, I will mention a few
things that struck me as suboptimal.

One: as everyone knows, the time-lag for approval is absurd. PG wrote about
this here
[http://www.paulgraham.com/apple.html](http://www.paulgraham.com/apple.html).
By the time I had submitted my app for approval and was in the hold queue, I
had a new version ready (with new features and bug fixes), but didn’t want to
resubmit and lose my place in the queue. Having to wait two weeks for an
approval was painful. SUGGESTION: why doesn’t apple put a numeric limit on
when apps get reviewed? It doesn’t make sense to me for an app with zero
downloads to have to go through the same scrutiny as an app that has millions.
Most apps, I’m sure, never even cross 1,000 downloads. Freeing up resources to
review apps that most users have, seems to make a lot of sense.

I also don’t understand how Tim Cook, who comes from a supply chain
background, doesn’t see even a 1 week approval as horrible. Best in class
inventory management has a principle called JIT (just in time) inventory
management, which has the goal of making inventory lead times as close to zero
as possible. To me, waiting 2 weeks to get an app approved is the equivalent
of having a 2 year lead time wait for inventory.

Another possible suggestion is that Apple pre-approves certain apps under
certain conditions and then only reviews them once they hit a certain download
limit. This way, new apps that are constantly being iterated, would be able to
get out to users.

Two: the testing process (pre-review) is also absurd. I had to use TestFlight
app, which was a nicely built app (recently acquired by Apple, who then shut
down the Google features…). However, as a giant company, you’d think they
would make beta testing much easier. Perhaps, they could use the same download
limit (allow all users the ability to install say 5 beta apps), without having
to go through getting a user’s device info, etcetera.

Three: I have no idea why Apple outsources their corporate check to Dun &
Bradstreet. If you are a corporation (which I submitted under), this adds
weeks to your first getting your app even reviewed. As a giant corporation,
Apple should not stand for making developers wait weeks just to have their
identities verified before having their app reviewed.

I’m guessing the reason that all these sub-optimal features exists is because
of the duopoly power of Google and Apple. Really, what’s needed is a powerful
software developer union that could force Apple to make these changes. I’d
nominate PG for the role, but I think he’s retired. Maybe dang could take up
the cause.

~~~
maccard
two points -

> In summary, two near identical (99.9 percent) apps. One approved. One
> rejected.

This sounds like the real reason they rejected your app was due to the
similarity.

> I won’t go into full detail about how many times I was on the phone with
> customer support about problems solely due to Apple

Ever tried ringing Google's customer support?

~~~
nolok
> Ever tried ringing Google's customer support?

You understood him wrong. He is not saying he was calling Apple's support,
he's saying he was on calls (probably with his clients) about issues caused by
Apple.

------
jpatokal
_" Make sure to fix all bugs before submitting."_

Good luck with that!

------
marpalmin
I always thought it would be interesting to have an appstore prereview startup
that in 1 day will check and give you a hint if your app would be accepted.

~~~
eli
That would be cool, but I think the review process is random enough that it
would be hard to make really confident predictions about what gets in and what
doesn't.

~~~
deong
You could pitch it as a more general service I guess. "We'll tell you how to
improve your app, including ways to improve your odds of a successful app
review" or something like that.

------
pjungwir
42% of rejections are for "other reason"\--wow. No wonder people feel Apple
reviews are capricious.

~~~
melling
Since this is HN, the best tech site on the net, perhaps we can move beyond
our basic human nature to whine, and dig a little deeper.

I was rejected once because I was copying a large database to the user's
document directory, which would have been sync'ed with iCloud, thus wasting
the user's space. That's probably reason "Other". Apple probably has 1000
little checks (e.g. Private api's), and they don't necessarily want to tell
you all of them.

Does anyone have a "capricious" rejection?

~~~
clarky07
i have been rejected a large number of times for things not on that list that
were also nearly always not true. i've appealed and won at least double digit
rejections for various apps over the 4 years i've had apps on the store. I
think i've had 4-5 updates rejected just in the last 6 months that i've
subsequently gotten approved through appeal.

lots of different things but an example: paraphrasing - "you included the
audio in background setting but don't play audio in the background so we are
rejecting the app"

first off, who cares if i included a setting but didn't make use of it?
second, i did in fact make use of it. there was simply a setting for a certain
feature that could be either on or off.

~~~
beagle3
Apple has the mindset (and they are not entirely wrong) that if a feature in
an app is confusing ("this switch doesn't do anything"), apple/iPhone will get
the blame, either directly or by association.

~~~
clarky07
I'm not sure how that applies here? that's not what they rejected. rejected
for something in settings file that has nothing to do with what a user ever
sees.

------
nicholassmith
First app I submitted to the App Store was rejected, for an edge case I'd not
tested (slow network) and they were concerned that the app wasn't
communicating to the user what was occurring, which was fine. I improved it,
resubmitted it so it was much more expressive and it was rejected again for
the same reason. I immediately resubmitted it with a description of what the
app was doing, why it was doing it, and why it was unavoidable in that
circumstance and they then approved it. It does seem at times slightly
capricious, and it took a lot of reading and rereading the guidelines to work
out what I needed to improve, but it led to a better app overall.

------
resca79
I think the model of review is not consistent. In my experience, Apple
rejected my app for the first time for 'x' and 'y' reasons. The second time
they rejected my app for 'z' reason,that was also present in the first
version, so I waited another 8 days for another review.

Funny is that my app was rejected because it could potentially violates 18.1
and 18.2 in
[https://developer.apple.com/appstore/resources/approval/guid...](https://developer.apple.com/appstore/resources/approval/guidelines.html)
the first time. The mentioned app by the policy, as bad example, is avaiable
in the app store.

------
lyndonh
Interesting how the example image for a bad UI shows the good UI using
"Metric" vs "English" buttons.

In the England and the rest of the UK we use "Metric" vs "Imperial".

And we use a half metric system; metres and miles, litres and pints.

I notice in the USA the system is a different half metric system. Americans
are much more likely to use ounces instead of litres. I also heard they
sometimes use "kilopounds" and other such weirdness.

Anyway, this example image is one big fail to me.

~~~
gresrun
Lived in the USA all my life and I have never even heard of "kilopounds"

~~~
CPLX
Maybe they mean to reference the oddities surrounding tons, short tons,
tonnes, and metric tons?

------
pjc50
Does anyone know how exactly the process of assigning apps to reviewers works?
Is it possible for individual reviewers to cherrypick apps for
favourable/unfavourable treatment? Are there people reviewing the reviewers?

------
Kiro
> Websites served in an iOS app

I see apps like this in the App Store all the time.

~~~
hayksaakian
Does that preclude web browsers?

------
evanb
Did anyone else notice that the "placeholder content" graphic has a
misspelling: "lor_u_m ipsum". I know it's a nonsense word to begin with, but
it still threw me a little.

~~~
WildUtah
Not strictly nonsense. 'Lorem' is the last part of 'dolōrem,' the accusative
singular of 'dolor' which means 'pain' in Latin.

------
thomasfoster96
"Guideline 2.9: Apps that are "beta", "demo", "trial", or "test" versions will
be rejected"

Surely on their website Apple were promoting a few of their own apps as beta
versions (I think Siri was one)?

~~~
deong
Apple doesn't have to, and doesn't, follow the rules. Their apps frequently
use private APIs, for example.

~~~
tomjen3
Wasn't it the mere allegation of doing that that got MS in legal hot water
back in the day?

I mean it is Apples platform and they can crash and burn it as much as they
want, it is just interesting.

~~~
mikeash
It was far from "the mere allegation". It was a _long_ history of doing so,
over many years, combined with overt efforts to break the products of
competitors, combined with owning virtually all of the market for PC operating
systems.

------
buro9
How are they "Guidelines" if they are enforced as rules?

Are there notable exceptions that do pass the review process (and not by luck,
but by being approved)?

In fact, having now skimmed through their guideline documents, it seems that
you could just replace the word "guideline" with "requirement" and leave no
app developer, or their managers, in any doubt whatsoever.

~~~
k-mcgrady
I think they're guidelines because some (especially the UI one) aren't always
enforced or are too vague. You don't have to follow the HIG exactly. People
come up with new UI's that don't conform to the HIG but get through because
they're good.

~~~
tripzilch
The thing is, they are guidelines for the _reviewers_ , not so much as the app
developers.

------
helpfuldev
"Common" can refer to a lack of refinement, thus rejection by Apple.

"Common" can also refer to "the usual", but according to the numbers, the
reasons are all over the place at around 5%.

English is annoyingly vague in this case. Perhaps there is a better title or
point to convey here?

~~~
eli
It's pretty clear they mean the latter; these are frequently cited reasons for
rejection.

~~~
helpfuldev
But there are no frequently occurring types. They are all 5% or less.

I'm trying to make a point here, but it obviously went over your head.

~~~
Karunamon
WTF? Did you even read the article?

[http://cl.ly/image/0e2Q3m0o2P1I](http://cl.ly/image/0e2Q3m0o2P1I)

~~~
helpfuldev
Yes, and you continue to miss the point.

~~~
mikeash
It's difficult to understand your point when it appears to rest on claims that
are demonstrably untrue.

------
lagopodousnull
A very common reason for Apple to reject an app is because of the Ad SDK that
the app is using. Many Ad Network SDKs are not up-to-date with the latest
guidelines issued by Apple. (Same applies to Google Play as well).

If you are fed up with your app getting rejected because of the Ad network you
are using, check out Avocarrot
([http://www.avocarrot.com](http://www.avocarrot.com)) for SDKs that are 100%
compliant.

~~~
melling
Which ad networks cover large emerging market countries like Brazil, Russia,
Turkey, and China? Apple's iAd only covers a dozen countries.

