Common App Rejections
developer.apple.com
developer.apple.com
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
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... ) 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.'
Had I been a reviewer, I would have.
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.
It's just yet another cat and mouse game.
Surely they need to be able to see the ads in the app to make sure they comply with the various guidelines Apple has. Otherwise all they could do is 'take your word for it', and there have been plenty of apps in the store that provide how trustworthy that is.
It would be really easy to just show the reviewers a completely different app from what users see. All you have to do is detect the review process and alter your behavior. This could be something as simple as pinging a server which returns "yes" or "no", and you flip the switch on the server after you pass review.
But nobody does this, because the implied consequences for doing it are not nice.
Clearly you can change the ads being served after it is reviewed, but all they can do is check the ads during the review process.
One of the things they also check for is that the ads aren't too obtrusive.
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.
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."
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.
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.
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 :)
I've only found statistics about the number of crashes: http://www.forbes.com/sites/tomiogeron/2012/02/02/does-ios-c...
This reason is a bit vague. Shouldn't "Yo" (and other clones) be rejected under this criteria? If not, what's the boundary then?
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-...
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).
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.
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
(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/make-them-jump/id900211132
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!")
The larger subtext is that this is their platform, and they want to keep the quality bar high. Therefore, publication of your app is their perogative, not your right.
On that note, yes it is not amateur hour. If you want to publish an app, Apple provide all the resources to help you do it - but if for example your app is buggy, it's amateur and will be rejected - seems fair enough to me.
Or is that the rankings have been frauded in some way? And exactly how is that done? Is there anything wrong with using an existing popular game to market a new game?
If they didn't set the bar that high, a lot more junk would be getting through.
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.
there are far far worse examples that could have been used, most of them never got into the top 10 in the store though. the fact that he had another popular app doesn't mean people are just going to click on the ads and automatically install their other apps. clearly you haven't advertised mobile apps before. it's not just trivial to drive that many installs even for good apps. doing it for terrible apps would be impossible unless you are using bots.
I’m a bit baffled why you consider them to be so horrible …
They aren’t beautiful, they aren’t complex and they are derivative. 2048 is a disgrace, obviously, but those apps are fine.
I think Apple steers away from rejecting games because there just aren’t HIGs for those. So you can’t reject them based on those, and also not really their aesthetics. Games are explicitly allowed to have aesthetics and even UI elements different from other apps because of their very nature. They are tricky territory.
http://www.polygon.com/2014/3/28/5557840/threes-creators-exp...
About 2 weeks ago, a clone appeared on the App Store. It wasn't just copying the original game play, but boldly used the same game name, which Apple approved.
It's now been removed. The process was to contact Apple, who then provided us with a point of contact for the offending game. We then had to ask the developer of the offending app.
Thankfully, they took it down without any fight, but why should we have to even go through this dance?
On a side tangent, a recent update was "Metadata rejected" because the reviewer couldn't find the ads in our game when we stated there were ads.
Ads only appear after 5 games, which was clearly stated in the "Review Notes" that you can submit in iTunes Connect. I guess the reviewer didn't bother reading these though.
Of course Google leaves their slider pushed to zero curation, treating apps like web pages (index them all and bury the crappy ones low in search results). But Apple seems to like their slider in the middle, which is why it seems so random to developers. After all, even when applied consistently, subjective rules appear random once you modulo by the difference between the observer's and the reviewers subjective viewpoints.
Personally I much prefer the Google approach, but then that's probably because I'd like for app stores to become commoditized. Apple probably doesn't agree. ;) Their slider does seem to have moved over the past few years though - perhaps it's post-Jobs drift; perhaps pressure from Google?
If a developer account makes too many apps that end up suspended, they can ban the user account. Then they're pretty good at detecting same physical persons using multiple accounts (credit card, IP address, etc.)
I found a typo, I'm rejecting Apple's App Rejections page.
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. 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.
> 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?
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.
They make their money on hardware. They want to keep it that way. Treating developers with respect and making their life comfortable runs contrary to this, because devs may start to think to much of themselves and, god forbid, decide to charge reasonable money for their creations. Putting developers down is imperative to making them feel as second class citizens, even guests on Apple's majestic platform. As someone who's been reluctantly allowed to benefit from it, someone who needs Apple more than Apple needs them.
This is exactly right. What gp, and other devs, need to understand is that all of the listed problems, which have been problems for a very long time, are your (gps, our) problems. They are not Apple's problems.
Apple solves Apple's problems. It's up to us to solve our problems.
Maybe if you're a corporation working on an app for months, you could get a DUNS number proactively instead of trying to save $15 by waiting until the last minute.
Good luck with that!
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?
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.
Were you doing this to avoid having the app killed when it went to the background?
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... the first time. The mentioned app by the policy, as bad example, is avaiable in the app store.
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.
On the other hand, having your prime factors be 2 and 3 rather than 2 and 5 are nice when you divid things into quarters and thirds regularly (inches).
I'm more or less on topic. I'm not engaging in a flame war. I'm not trolling.
Is it the "kilopounds" thing? What can I say, I heard that this kind of Greek prefix gets used with non Metric meaurements. So I said sometimes.
I see apps like this in the App Store all the time.
Surely on their website Apple were promoting a few of their own apps as beta versions (I think Siri was one)?
I mean it is Apples platform and they can crash and burn it as much as they want, it is just interesting.
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.
"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?
I'm trying to make a point here, but it obviously went over your head.
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) for SDKs that are 100% compliant.