12 ms·

Common App Rejections

220 points by kmfrk 12y ago

marpalmin 12y ago
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 12y ago
  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 12y ago
    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.
helpfuldev 12y ago
"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 12y ago
  It's pretty clear they mean the latter; these are frequently cited reasons for rejection.
  - helpfuldev 12y ago
    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 12y ago
      WTF? Did you even read the article? http://cl.ly/image/0e2Q3m0o2P1I http://cl.ly/image/0e2Q3m0o2P1I
      - helpfuldev 12y ago
        Yes, and you continue to miss the point.
        mikeash 12y ago
        It's difficult to understand your point when it appears to rest on claims that are demonstrably untrue.
deleted 12y ago
[deleted]
pjungwir 12y ago
42% of rejections are for "other reason"--wow. No wonder people feel Apple reviews are capricious.
- simonh 12y ago
  All that means is that 42% of rejections are for reasons other than those in the top 10. They are still for specific reasons that are communicated to the developers though.
  - deong 12y ago
    I would expect the arbitrary and capricious ones fall under the 6% heading of "did not comply with the Developer Program License Agreement". This is where they'd nail you for making fun of a political figure, or the iPhone factory worker game/critique.
- mbesto 12y ago
  I think you misread that. 42% is a combination of a bunch of reasons that contribute less than 2% of the overall pie. In other words, Apple has a long list of reasons why they reject apps, and generally speaking there isn't one area that all developers fail at.
- melling 12y ago
  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?
  - Herald_MJ 12y ago
    fwiw I have been rejected for the same reason. I seem to remember it was a two-line fix for this.
eli 12y ago
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.
- k-mcgrady 12y ago
  Could you turn on the network ads when in review and remotely disable them after passing it?
  - TheLoneWolfling 12y ago
    And this is the problem with any sort of app review - you never can know. Even code audits where skilled people manually inspect code sometimes misses things. It's just yet another cat and mouse game.
  - prawn 12y ago
    Yes, you could. We use a remote configuration in our game to adjust the mix of ads from various providers.
- MBCook 12y ago
  > Such a strange requirement. 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.
  - Sanddancer 12y ago
    What precludes you from submitting the app for review with fairly innocuous ads, then flipping the switch to show malicious ads? Or, perhaps have someone who only wants to show ads every once in a while? For example, an app for handling trade shows where you only want to show ads while the person is at the event space. There are a number of legitimate reasons why you wouldn't want to show an ad right that moment.
lagopodousnull 12y ago
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.
- andrewgjohnson 12y ago
  Jab jab jab...RIGHT HOOK
- melling 12y ago
  Which ad networks cover large emerging market countries like Brazil, Russia, Turkey, and China? Apple's iAd only covers a dozen countries.
bhaumik 12y ago
"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?
- sean-duffy 12y ago
  I imagine this guideline is probably just used as a barrier to apps with no real functionality, to stop people submitting "Hello World" apps and the like.
- gergles 12y ago
  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-isnt-actually-1-million-in-the-bank-2014-6 http://www.businessinsider.com/the-inside-story-of-yo-there-...
  - k-mcgrady 12y ago
    >> "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).
    - andrewljohnson 12y ago
      +1, me too, couple of times.
    - megablast 12y ago
      You can also get in touch with someone at Apple, if you have any mates or any people from Apple work in your company.
buro9 12y ago
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 12y ago
  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 12y ago
    The thing is, they are guidelines for the reviewers, not so much as the app developers.
lyndonh 12y ago
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 12y ago
  Lived in the USA all my life and I have never even heard of "kilopounds"
  - CPLX 12y ago
    Maybe they mean to reference the oddities surrounding tons, short tons, tonnes, and metric tons?
- RaptorJ 12y ago
  kilopounds feels like a weird bastard but I think it makes sense. The actual values of the metric system are just as arbitrary as US Custom/Imperial (a particular mass, 1/10,000,000 part of the quarter of a meridian, such and such hyperfine transitions in a arbitrary atom, &.) The value of the metric system is decimalization -- the centi-, kilo-, mega- prefixes. Really, if americans ditched miles and tonnes and stuck to kilofeet and megapounds the systems would not be meaningfully different. 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).
- lyndonh 12y ago
  I've never had my posts downvoted so much as on HN. 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.
thomasfoster96 12y ago
"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)?
- jreed91 12y ago
  Siri technically isn't an app
  - thomasfoster96 12y ago
    I guess not an 'app' as such, but it's still a program on the phone.
- deong 12y ago
  Apple doesn't have to, and doesn't, follow the rules. Their apps frequently use private APIs, for example.
  - tomjen3 12y ago
    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 12y ago
      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.
softdev12 12y ago
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.
stevenh 12y ago
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/guidelines.html https://developer.apple.com/appstore/resources/approval/guid... 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!")
jpatokal 12y ago
"Make sure to fix all bugs before submitting." Good luck with that!
jn4 12y ago
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 12y ago
  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 12y ago
    > 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 :)
willu 12y ago
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.
- weixiyen 12y ago
  Interesting, they've always logged in to my submissions. Process is truly random imho.
  - DrJokepu 12y ago
    In my experience, the app review process is more meticulous the more you charge for the app. Maybe OP's app is free or fairly cheap while yours is more expensive or has expensive in-app purchases?
- beagle3 12y ago
  Is it possible that they registered a different account (without an @apple.com address?) Had I been a reviewer, I would have.
  - hayksaakian 12y ago
    He could be marking user sessions with build numbers
  - willu 12y ago
    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.
themoonbus 12y ago
"...are not ready to be distributed and cannot be be approved." I found a typo, I'm rejecting Apple's App Rejections page.
bfarrellforever 12y ago
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 12y ago
  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/networkinginternet/conceptual/streamingmediaguide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html 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.'
  - bfarrellforever 12y ago
    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.
evanb 12y ago
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 12y ago
  Not strictly nonsense. 'Lorem' is the last part of 'dolōrem,' the accusative singular of 'dolor' which means 'pain' in Latin.
Kiro 12y ago
> Websites served in an iOS app I see apps like this in the App Store all the time.
- hayksaakian 12y ago
  Does that preclude web browsers?
sspiff 12y ago
"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.
nicholassmith 12y ago
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.
pjc50 12y ago
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?
resca79 12y ago
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/guidelines.html 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.

220 points by kmfrk 12y ago

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 12y ago
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 12y ago
  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.

helpfuldev 12y ago

"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 12y ago
It's pretty clear they mean the latter; these are frequently cited reasons for rejection.
- helpfuldev 12y ago
  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 12y ago
    WTF? Did you even read the article? http://cl.ly/image/0e2Q3m0o2P1I http://cl.ly/image/0e2Q3m0o2P1I
    - helpfuldev 12y ago
      Yes, and you continue to miss the point.
      - mikeash 12y ago
        It's difficult to understand your point when it appears to rest on claims that are demonstrably untrue.

deleted 12y ago

[deleted]

pjungwir 12y ago

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

simonh 12y ago
All that means is that 42% of rejections are for reasons other than those in the top 10. They are still for specific reasons that are communicated to the developers though.
- deong 12y ago
  I would expect the arbitrary and capricious ones fall under the 6% heading of "did not comply with the Developer Program License Agreement". This is where they'd nail you for making fun of a political figure, or the iPhone factory worker game/critique.
mbesto 12y ago
I think you misread that. 42% is a combination of a bunch of reasons that contribute less than 2% of the overall pie. In other words, Apple has a long list of reasons why they reject apps, and generally speaking there isn't one area that all developers fail at.
melling 12y ago
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?
- Herald_MJ 12y ago
  fwiw I have been rejected for the same reason. I seem to remember it was a two-line fix for this.

eli 12y ago

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.

k-mcgrady 12y ago
Could you turn on the network ads when in review and remotely disable them after passing it?
- TheLoneWolfling 12y ago
  And this is the problem with any sort of app review - you never can know. Even code audits where skilled people manually inspect code sometimes misses things. It's just yet another cat and mouse game.
- prawn 12y ago
  Yes, you could. We use a remote configuration in our game to adjust the mix of ads from various providers.
MBCook 12y ago
> Such a strange requirement. 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.
- Sanddancer 12y ago
  What precludes you from submitting the app for review with fairly innocuous ads, then flipping the switch to show malicious ads? Or, perhaps have someone who only wants to show ads every once in a while? For example, an app for handling trade shows where you only want to show ads while the person is at the event space. There are a number of legitimate reasons why you wouldn't want to show an ad right that moment.

lagopodousnull 12y ago

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.

andrewgjohnson 12y ago
Jab jab jab...RIGHT HOOK
melling 12y ago
Which ad networks cover large emerging market countries like Brazil, Russia, Turkey, and China? Apple's iAd only covers a dozen countries.

bhaumik 12y ago

"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?

sean-duffy 12y ago
I imagine this guideline is probably just used as a barrier to apps with no real functionality, to stop people submitting "Hello World" apps and the like.
gergles 12y ago
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-isnt-actually-1-million-in-the-bank-2014-6 http://www.businessinsider.com/the-inside-story-of-yo-there-...
- k-mcgrady 12y ago
  >> "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).
  - andrewljohnson 12y ago
    +1, me too, couple of times.
  - megablast 12y ago
    You can also get in touch with someone at Apple, if you have any mates or any people from Apple work in your company.

buro9 12y ago

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 12y ago
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 12y ago
  The thing is, they are guidelines for the reviewers, not so much as the app developers.

lyndonh 12y ago

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 12y ago
Lived in the USA all my life and I have never even heard of "kilopounds"
- CPLX 12y ago
  Maybe they mean to reference the oddities surrounding tons, short tons, tonnes, and metric tons?
RaptorJ 12y ago
kilopounds feels like a weird bastard but I think it makes sense. The actual values of the metric system are just as arbitrary as US Custom/Imperial (a particular mass, 1/10,000,000 part of the quarter of a meridian, such and such hyperfine transitions in a arbitrary atom, &.) The value of the metric system is decimalization -- the centi-, kilo-, mega- prefixes. Really, if americans ditched miles and tonnes and stuck to kilofeet and megapounds the systems would not be meaningfully different. 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).
lyndonh 12y ago
I've never had my posts downvoted so much as on HN. 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.

thomasfoster96 12y ago

"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)?

jreed91 12y ago
Siri technically isn't an app
- thomasfoster96 12y ago
  I guess not an 'app' as such, but it's still a program on the phone.
deong 12y ago
Apple doesn't have to, and doesn't, follow the rules. Their apps frequently use private APIs, for example.
- tomjen3 12y ago
  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 12y ago
    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.

softdev12 12y ago

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.

stevenh 12y ago

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/guidelines.html https://developer.apple.com/appstore/resources/approval/guid... 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!")

jpatokal 12y ago

"Make sure to fix all bugs before submitting." Good luck with that!

jn4 12y ago

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 12y ago
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 12y ago
  > 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 :)

willu 12y ago

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.

weixiyen 12y ago
Interesting, they've always logged in to my submissions. Process is truly random imho.
- DrJokepu 12y ago
  In my experience, the app review process is more meticulous the more you charge for the app. Maybe OP's app is free or fairly cheap while yours is more expensive or has expensive in-app purchases?
beagle3 12y ago
Is it possible that they registered a different account (without an @apple.com address?) Had I been a reviewer, I would have.
- hayksaakian 12y ago
  He could be marking user sessions with build numbers
- willu 12y ago
  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.

themoonbus 12y ago

"...are not ready to be distributed and cannot be be approved." I found a typo, I'm rejecting Apple's App Rejections page.

bfarrellforever 12y ago

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 12y ago
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/networkinginternet/conceptual/streamingmediaguide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html 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.'
- bfarrellforever 12y ago
  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.

evanb 12y ago

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 12y ago
Not strictly nonsense. 'Lorem' is the last part of 'dolōrem,' the accusative singular of 'dolor' which means 'pain' in Latin.

Kiro 12y ago

> Websites served in an iOS app I see apps like this in the App Store all the time.

hayksaakian 12y ago
Does that preclude web browsers?

sspiff 12y ago

"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.

nicholassmith 12y ago

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.

pjc50 12y ago

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?

resca79 12y ago

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/guidelines.html 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.