IOS App Store Submission Checklist - anything else to add? | Hacker News Reader

IOS App Store Submission Checklist - anything else to add?

ontestpad.com

201 pointsstefanbutlin72 comments

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.

I often have my iPad with the home button on top while on the stand. Easier for charging...

(Just in case anybody wonders why they'd want both orientations...)

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.

Yes this is trivial.

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.

Nice clarification. Have updated the list.

Don't believe the crash reports in iTunes connect, they lie, your app does crash... a lot, so add a crash reporter.

The best I found so far is the self-hosted QuincyKit (http://quincykit.net/) or if you don't want to fiddle with your own server, use HockeyApp (http://www.hockeyapp.net/).

This is post-approval, but good to keep in mind. http://crazyviraj.blogspot.com/2011/08/dont-let-apples-laten...

With regards to the HIG:

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

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

Neither of your instances of breaking the HIG made your app better, so yes, what I said is true. It was said by an Apple engineer.

'Better' is arbitrary and entirely up to Apple, but if you have any UI nouse you're going to get it through. They themselves routinely break the HIG.

The 'G' is for guidelines, not rules.

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

Inkling is rated 12+ and seems to have more than one >$100 in-app purchase. (e.g. the Biology text @ $120 and Supply Chain Management Text @ $140)

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+)

Amazing. List updated. Thanks.

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.

Yes, unfortunately. If the app does have unrestricted web browsing then you have to rate it 17+.

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.

True. Have changed to 'does not hardcode any price information...'

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

This item on SO has more details: http://stackoverflow.com/questions/2135081/does-my-applicati...

"Lite versions must not prompt (up-sell) the full or paid version"

Is this true? I play a game that periodically shows an up-sell to the paid version as an alternative to the app's advertisements.

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

That interpretation makes sense.

Here's one to add to the list:

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.

Wouldn't that come under "does not replicate the functionality of a native app"? (not that they're consistent about this one)

Do the developers end up receiving payment for the copies sold before it is pulled from the App Store?

Yes.

You should remember you turn off NSZombies before submitting.

Thanks. Updated.

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.

Surprised to see "does not leak memory" is not on the list. That's a biggie.

I don't think Apple reject apps that leak "a bit". There's this older discussion on SO: http://stackoverflow.com/questions/1136511/does-apple-reject....

If you leak fast your app is unlikely to "not crash" and "remain responsive".

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

> App looks well designed and of high quality

While this is wonderful to have on a checklist, let's be honest: the vast majority of apps fall short of this goal (and that's putting it nicely).

"e.g. Images and icons are not framed with a "polaroid" style (thicker at the bottom) border"

Can someone give me an example of a Polaroid border? Is it just a frame around an image?

It's a fat white border around the image. A variation of this often imitates a photo stack each having such frame.

Google images keywords: polaroid frame, polaroid stack.

Sample: http://blog.simplyjean.com/wp-content/uploads/2007/11/polaro...

What's interesting that this wouldn't be allowed, I think there's many apps using this framing style in the app store already.

I assume that Polaroid has asserted some kind of trademark over the Polaroid-style frame, but I couldn't find any such case on Google.

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

Yes - a frame around the image with the bottom border being thicker: http://3.bp.blogspot.com/-J0yzOfVB7yk/TgC1f_wjVbI/AAAAAAAAE_...

Good list. Would add: Does not include the names of any other competing platform (e.g., Android, Blackberry) in your description or inside the binary.

Thanks. Updated.

Excellent checklist. Thanks OP. I also like how you are keeping it up to date with commenter's suggestions.

> Lite versions must not prompt (up-sell) the full or paid version

That one I see quite a lot. Example: Cut The Rope Holiday Gift (which is free) proposes me to get CTR Original and CTR Experiments on the last tab.

Agreed. I've reworded the Lite version checks a bit.

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?

Ad hoc distribution presumably.

http://developer.apple.com/programs/ios/distribute.html

Here's one:

If you are using Appirater or any other service that uses your app ID for something. Make real real sure you are using the right ID for your app.

Easy to mess up on new apps.

Thanks for this. Double thanks for the fact I can subscribe to that page via RSS (the links at the bottom of the page).

clarification: the RSS link is for the disqus-hosted comments, not changes to the submission checklist contents.

to add: if map is used, do not cover or obscure the Google logo

Thanks. Updated.

Also maybe consider dropping:

> App state is saved when stopping the app and restored on next start

I believe you get this for 'free' with IOS 4 and greater, as the app now never stops, it just suspends to the background when you switch between apps.

Not if the device runs out of memory or on older iOSes. You should always address this case.

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!

Even on iOS 4, the iPhone 3G doesn't support multitasking.

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.

0071 Make a million dollars

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.

And rightfully so. He's a huge Sarah Palin fan. What a wimp. Angela Lansbury could kick his ass.

Reply on news.ycombinator.com