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
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?)
'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.'
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.
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.
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?
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.
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.
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.
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.
There's always the implicit thread of strong reprisals (e.g. being blacklisted for life) if you overtly try to trick them rather than just making a mistake.
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.
I wonder how often apps are rejected and how often they get through for this rule. I'd much rather use an app that uses my ID instead of making me sign up/sign in. It also makes it easier to stop people from posting crap in your app than if you assigned ids on your own.
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.
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.
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."
apple doesn't care what your ads are. they care that you don't use the ad identifier for things that aren't ads. nothing to do with being a "nefarious ad machine"
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.
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.
> 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 :)
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.
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.
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.
>> "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).
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.
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.
"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.
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...
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:
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!")
I recently published my first ever game, Hexiled. It has had some mild success in the first 6 weeks it's been available on the App Store.
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.
Those examples you names don’t have “horrendous quality”. They are also most certainly not ugly. I think they actually have tons of style and their aesthetics are quite consistent and straightforward. I also downloaded them and they all play fine.
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.
2048 is a disgrace ? I actually quite liked the design of it. It has that clean, functional UI that actually lends itself well to what type of game it is.
I think it's worth noting that 2048 itself was a clone—or pretty much as close as you could get—of “Threes.” According to the developers, a year and a half was spent iterating on mechanics and design.
That’s not true. Well, strictly speaking it is, but the 2048 did know about another Threes clone. I don’t think he meant much by it and I don’t really fault the original 2048 author … but these guys … that’s not ok.
Interestingly I mostly agree with your sentiment but I mostly disagree with your examples. There are plenty of examples of apps that are much much worse than those shown. the flappy clone isn't great but it could be worse. the other all have thousands of reviews with an average of 4 star. just because you aren't impressed with the graphics doesn't mean those shouldn't have been approved.
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 don't quite understand what the problem is with the apps you have listed. Is it that because they are "primitive" and the graphics is "ugly" that they should not be popular?
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?
I went to go see if they actually did say "amateur hour" (they do, amazingly) and in the process noticed this: "If you run to the press and trash us, it never helps." It blows my mind that they're willing to say that so explicitly.
Running to the press implies a kneejerk reaction. It could equally be argued that they're saying you should engage them in meaningful discussion about the problems they have with your submission. When an app is rejected I believe there is always the possibility of a two-way discussion with the submission team.
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.
It makes perfect sense for Apple to have standards for publishing software on their store. What complicates the discussion is that they prevent users from installing software from other sources than their store. This is different than most other popular computing platforms except for game consoles.
Metaphorically speaking, I think every app store has slider in its settings panel, with "lots of crappy/derivative apps" at one end, and "subjective/random curation" at the other. You can't decrease one without increasing the other.
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?
It's not "zero curation" with Google, they let anyone publish any app but they remove apps afterwards. For example they recently cleaned up all swing copter clones.
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 don't think that qualifies as curation. Google's market policy is basically identical to YouTube, right? They resolve disputes and enforce the ToS, and that's about it. But one would be hard-pressed to call YouTube curated..
Yes. Also: this recent blog post claims Google is willing to remove apps that increase privacy (not just ad-blocking) in a way that undermines Google's business model: https://news.ycombinator.com/item?id=8240450
Those aren't particularly bad games, they seem to be functional and somewhat entertaining. Actually bad game would be one that has only one level, is impossible, etc. i.e. unplayable as an actual game.
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.
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.
It's not perfect, it just leads to the same distribution of crappy/average/great apps as Google's Play Store, except that submitting apps to the Play Store is instantaneous.
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. 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.
Apple's arrogance towards the developers stems directly from their goal of turning iOS software into a cheap commodity.
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.
Apple's arrogance towards the developers stems directly from their goal of turning iOS software into a cheap commodity.
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.
While those are all suggestions that open up good things, I'd like to suggest that you take a minute to think about those from an attacker's perspective. Most of what you suggest comes at a significant cost. Paying that cost might be on balance correct. But there's definitely a security/user-trust cost to implementing these suggestions.
"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."
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.
It's not so much "waiting until the last minute" as it is "not finding out until the last minute". People should do their research, but on the other hand there's almost no precedent for this sort of thing (you wouldn't expect to need a DUNS number for signing up for Facebook) and people have no reason to think of checking for something like that.
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.
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.
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.
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.
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.
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.
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.
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.
I worked on an app that was rejected for taking an image of the user's Mac, obtained from public NSImage APIs, transmitting it over the local network, and displaying that image on an iPhone.
They weren't real specific (surprise surprise) but quoted the rule that "You may not use the Apple Logo or any other Apple-owned graphic symbol, logo, or icon...."
Almost. In addition to an image of the screen, we superimposed it on top of the image returned from NSImageNameComputer, which grabs an icon-ish representation of the user's computer model (e.g. it produces an iMac image when run on an iMac), and that often includes an Apple logo. We also superimposed the icon of the selected app on the Mac, which was often iTunes or another Apple app. One of those is what they didn't like.
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.
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.
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.
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.
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.
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.
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).
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?
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.
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.
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.
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.
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) for SDKs that are 100% compliant.
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