I've got one you can add: iPad applications don't have to support all four orientations. However, whichever orientation you do support (in our instance, portrait) you must support the top-up and bottom-up variations unless some special circumstance warrants only supporting one or the other. Just had a submission rejected earlier this week for this reason. FYI, here is the response we received from Apple:
10.1
We found that your app does not comply with the Apple iOS Human Interface Guidelines, as required by the App Store Review Guidelines.
Specifically, we noticed your app only supported the top-up variant of the portrait orientation, but not the bottom-up variant.
While supporting both variants of both orientations, each with unique launch images, provides the best user experience and is recommended, we understand there are certain applications that must run in the portrait orientation only. In this case, it would be appropriate to support both variants of that orientation in your application, e.g., Home button up and down.
Addressing this issue typically requires only a simple and straightforward code modification. However, if you require assistance, the Apple Developer Support Team is available to provide code-level assistance.
For more information, please review the Aim to Support All Orientations section of the iOS Human Interface Guidelines.
Another reason is that the speaker is on the side with the home button. Having that edge face downwards when sitting down e.g. in bed muffles the sound. Not sure if this still applies to iPad 2, but it certainly does for the original.
I find that I'm often using the iPad "upside down". It wasn't on purpose, but there are very few reasons to care which way you're picking it up. It would be jarring to discover an app that cared.
Is there not an easy way to just say "turn my app upside down when the user flips the device"? For most apps (i.e. ones that don't use the accelerometer, etc.) this should be trivial, and shouldn't require any real effort from the app developer.
Also, I agree with Apple that both orientations should be supported. Depending on how you're holding or docking the device, and where it's convenient for the headphone jack to protrude, it's quite conceivable for users to want to use both orientations.
Assuming you programmed your app correctly, you only need to override the function shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation to return true for the supported orientations. If you use portrait orientation, you can get portrait upsidedown for "free", as it rotates the view for you. It's the same with LandscapeLeft and LandscapeRight. The only complications come when you want to support both portrait and landscape orientations, which isn't required anyway.
It's trivial to support two orientations, but Apple had (has?) a guideline that said you must support all four orientations. That's not necessarily trivial, although Apple's UI kit has features to help you there too.
Thanks for letting us know. I actually have an iPad app currently in the store (approved in October) that only supports top-up portrait. I guess it really depends how picky the reviewer wants to be. I will make sure I fix it before my next update.
At a recent Apple iOS Tech Talk the engineer giving the session mentioned that breaking the HIG wasn't expressly forbidden, but that you needed to "know the rules in order to break them". Break them, if it's better than sticking to them.
This isn't true. I've had two rejections for HIG violations - one was an unclear error message (authentication failure-style message when no network was available) and the other was orientation problems (one of the official iPad app templates at the time supported three orientations by default, which is against the rules).
Specifically, section 10.1 of the App Store review guidelines states:
> Apps must comply with all terms and conditions explained in the Apple iOS Human Interface Guidelines
It is very much the case that you can often get away with it (see for example all the apps with splash screens), but it is "expressly forbidden".
Here's one to add: if your app has a in-app purchase of more than $100, your app HAS to be rated 18+ because of a fear of teenagers can run up their parents' credit card bills.
It's somewhat unfair because 18+ means adult content, but an app might not contain adult content (as was the case with our client's self-help books/videos).
It could depend on the reviewer, or the app could have been grandfathered in before that policy went into effect? All I know is our client's app got rejected with that as the reason (ours was rated 9+)
Does not "accidentally" contain such material, e.g. unrestricted web browsing, explicit lyrics, unfiltered collections of books.
Is that still true? That is, they will still reject a new e-book reader because it can read the Kama Sutra, and they would still reject an app that allowed the user to navigate to a porn site? I have the Wikipedia app installed, which I think would violate those terms.
Can someone elaborate on the no pricing information within the app point? If we have an in-app purchase, we can't tell people how much it costs? That sounds opposite to what I'd expect.
They specifically mean hard-coded references. For IAPs and the like, you should be querying the server for the localized price.
A good example is a "Share via Email" function that presents a pre-filled Email Composer with "Download this $1 app." This causes problems if you happen to change the price down the road (or if users are in a different economic zone).
I was curious about this too so had a search and found.
http://stackoverflow.com/questions/7109635/is-it-ok-to-show-...
If you use MKStoreKit to localize the pricing then its OK. Apple dont want developers hard coding pricing info or displaying the wrong currency to the user.
This is a fantastic list! Thank you for putting this together.
Question: can you elaborate on what this means exactly, and why it's necessary? "If you use encryption, you have registered with BIS and can provide documentation."
By "prompt" I assume they mean an actual modal popup, or something else that can't be ignored. Advertising seems ok, but forcing the user to make a choice is not.
The "rules" (aka what gets accepted) about Lite versions seem hazy these days - anyone have any up to date "reference material" on this (and I'll update the list accordingly)?
Don't submit any sort of tethering app. Chances are it will be approved and removed within a couple of hours. Apple is 2 for 2 so far: Netshare and iTether.
Is this some kind of cat&mouse game from within Apple? Whoever is approving these apps must know what is going to happen. While it must be stressful for the app owner, as a spectator it's amusing (and granted, it's an issue I'm not affected by).
This one is interesting. If your app does something more than just tethering, it will likely be approved. Your app should change the data in some way for the receiving machine. Automotive telematics systems do this already, for example they use apps to stream music and map data to the head unit (pandora, gmaps) while basically reformatting the data for the head unit.
In other words, don't create a general tethering app, but a specific "service" for another device.
This isn't necessary. It's an environment variable Xcode adds while running the executable, not something that is compiled into the application. Furthermore it only works in the simulator, not on the device itself, so end users wouldn't run into problems with it anyway.
Well, I suppose it's true -- I have submitted apps to Apple that got approved that leaked memory. But the leaks were coming from one of their frameworks (WebKit).
So perhaps what I said should be amended to say: "Your app does not leak memory, at least because of any code you wrote".
It's a worthy goal, but missing it still doesn't cause rejection. BTW, I do include "don't leak memory" in my general-purpose template for testing (as opposed to submitting) iOS apps here: https://ontestpad.com/library/200/ios-app-testing-template
We got a reject from Apple for this very reason.
Don't have an example but the dimensions for the photos below - best advised to avoid using these proportions! Physical = 3.5" x 4.25" 0.25 inch white border at the top, .1875 inches on the sides and .875 at the bottom
I once had an app rejected as it was "not amusing" (it was a "Unicorn Chaser" app). I also have had apps rejected for putting "iPad" in the wrong section of the name. For example "X for iPad" is fine, but "iPad X" is not.
"The app has a reasonably sized market, i.e. is not a tiny niche or for a private audience" ...how do you distribute an app for a niche or private audience?
I didn't consider out of memory condition, thank you. I wasn't worried about older OS as practically speaking there are not that many folks on IOS 3 or older, at least based on stats I've seen for iPhone. I don't specifically target iPods, so maybe there are more of those at 3 vs iPhone. Thanks again - great list!
Good point - I seem to have forgotten that as well as I considered 3GS or greater to be my target. So it is a good point to consider for usability, depending on the app. But FYI, at least in my app's case, it wasn't a determining criteria or test in order to pass app store review.
Any mention of my personal hero Chuck Norris is also an instant rejection. :( I even tried a little s/Chuck Norris/Nuck Chorris/g but to no avail. http://bit.ly/oHvY1b
This actually seems to be true; a dev friend who submitted a Chuck Norris joke app got smacked down hard by Chuck's legal team. Now he seems to be on Apple's list of untouchable content. The same dev had a Keving Smith app (similarly unauthorized) that stayed up for ages.
10.1
We found that your app does not comply with the Apple iOS Human Interface Guidelines, as required by the App Store Review Guidelines.
Specifically, we noticed your app only supported the top-up variant of the portrait orientation, but not the bottom-up variant.
While supporting both variants of both orientations, each with unique launch images, provides the best user experience and is recommended, we understand there are certain applications that must run in the portrait orientation only. In this case, it would be appropriate to support both variants of that orientation in your application, e.g., Home button up and down.
Addressing this issue typically requires only a simple and straightforward code modification. However, if you require assistance, the Apple Developer Support Team is available to provide code-level assistance.
For more information, please review the Aim to Support All Orientations section of the iOS Human Interface Guidelines.