Avoiding iPhone App Rejection From Apple
By 
I’ve been developing apps for the iPhone for over 6 months now. Over this time period, I’ve successfully submitted over 45 apps, the majority under my own company’s iTunes account. Given the large number of app submissions, I’ve had my share of app rejections.
As has been mentioned many many times on the various developer forums, Apple’s approval process can be very frustrating and inconsistent. However, if you are careful, you can greatly reduce your risk of getting an app rejected.
Based on my own experiences, here’s my list of things to be careful about:
1. The dreaded HIG Violation of Apple’s Human Interface Guidelines (HIG) is probably the most frequent cause for an app to be rejected. As an iPhone developer, you definitely need to read the HIG and follow the guidelines! Take every single item mentioned in the HIG seriously. Yes, many apps demonstrate gross violations of the HIG (after all, splash screens are a no-no according to the HIG), but you can never claim “App X does this and is already in the store” as an excuse when Apple rejects your app. Well, you can claim that, but Apple will not accept it as a valid justification.
There are certain items in the HIG to which Apple does seem to turn a blind eye (splash screens probably being the most obvious), but unless you like taking chances with your livelihood, avoid going against any of the HIG guidelines.
2. Matching icons Believe it or not, Apple is now requiring the 512×512 iTunes Store icon match the 57×57 icon displayed on the iPhone. As a reason for rejection, Apple will state having unmatching icons is in violation of the HIG. There’s nothing in the HIG that states these two icons must match, but since it’s Apple’s store, you basically need to play by their arbitrary rules. So, unless you want unnecessary delays in your approval, make sure your icons match. The icons don’t have to be identical, but there should be something shared between the two. Just having them both be pictures that are of a similar theme is not enough.
3. Simulating failures Apple doesn’t like anything that pretends the iPhone or iPod Touch is failing. So, simulating a cracked screen is a good way to get your app rejected. Any other idea of faking a failure of the iPhone which you might think others would find amusing will probably also be a reason for rejection from Apple.
4. Button images must be consistent If you decide to use one of the existing images Apple provides for buttons, be careful you use it for an identical function. While the HIG states you can use a standard button in a non-standard way if your app is providing a “immersive environment”, you are better off creating your own custom buttons to avoid the risk of rejection. If you use the “action button” image, make sure tapping on it brings up a menu with choices. If it doesn’t, Apple may reject the app.
5. Bandwidth usage over cellular networks If your app downloads data over the cellular network, ensure you do not use too much bandwidth. How much is too much? Well, there isn’t an exact number, but a tech support person from Apple advised me to not exceed 4.5 meg of data per 5 minutes of activity. You can test your app’s usage by going into your iPhone settings, choosing the General->Usage menu and clearing the stats. Then run your app for 5 minutes, return to this screen and see what the stats say. Also, to get the most accurate numbers, you should turn off any other network activity on your phone while you run the test (such as Email or MobileMe updates).
6. Popup for network detection If your app requires the use of the Internet, you must detect when the network is unavailable and provide a pop-up message informing the user. Just having the spinning busy icon display and a message saying “trying to connect” is not sufficient. Apple will reject your app if you don’t provide a message informing the user that they need a network connection.
7. False claims of a missing network On a related note, make sure you don’t have any false positives in your network detection. There’s a bug in the “reachability” functions provided by Apple. If you don’t first try to perform a network connection but instead just do a reachability test, the code will always report the network is unavailable. Apple will reject your app if they discover you have this false positive case.
8. Political lampooning Don’t make any jokes about political figures, past or present, in either your app or the description in iTunes. Apple will most-likely reject your app.
9. Ensure your app description is accurate Spend some time proof-reading your app description for iTunes. This description is the only information the reviewer is going to have about your app. Make sure there isn’t anything ambiguous in the description. If there is room for misunderstanding a feature, you run the risk of the reviewer rejecting the app because they felt the app does not behave as described.
10. Keep your “what’s new” descriptions brief Whenever you submit an update, Apple requires you to provide a description of what is new in the app. Related to the previous note above, try to be as clear and concise as possible. Don’t go into too much detail describing what has changed, otherwise you introduce more opportunity for the reviewer to misunderstand what has changed. I’ve had an app rejected because the reviewer misunderstood what I said had changed in the app.
11. OS compatibility If you claim your app works with OS 2.0 and higher, you better make sure you test whether your app really does work on all the OS versions between 2.0 and the current one. The reviewer most-likely will! There are some anomalies in the behavior of certain functions across the different versions of the OS (for example, reachability code returns a slightly different set of flags under 2.0 vs. 2.2, UILabels don’t respond to the Touch events under 2.1 and earlier, etc.). If the reviewer finds the app does not work properly with a certain version of the OS, the app will rightly be rejected. However, don’t expect the reviewer to mention that they were testing using a different OS. That little detail is usually not mentioned in the rejection email, leading to the potential for lost time trying to find a bug while testing with a different OS than the reviewer. Again, test the app with every version you claim to support.
This is by no means an exhaustive list. It’s just the things I’ve personally run into in my app submissions and is a laundry list of items I keep in the back of my mind whenever I’m developing a new app.
If you do find your app is rejected, the best advice I can give is try to remain calm. Remember there are thousands of other developers in your shoes. We feel your pain. It often feels unfair, and perhaps it is unfair at times. It can be a terribly frustrating experience, especially when you’ve done your best to follow every guideline Apple provides and you might be convinced Apple is wrong in their assessment of your app.
But, it’s Apple’s store. They can do whatever they want in the end and don’t have to be fair. If you feel your app has been wrongfully rejected, the best you can do is be courteous and try to outline your position, quoting from whatever relevant Apple documentation applies. But, in the end, don’t expect Apple to yield to your request, or in many cases, even acknowledge your request. Apple is generally very brief in their email responses and sometimes totally silent. The best bet for an approval is to implement a change based on Apple’s reason for rejection and move on. Trying to win an argument because
you feel you are right is not going to be productive.
And if you do get a rejection, add it to your list of things to avoid for the next app.
Editor’s note: we collected all the comments and email this post generated and produced a second part to this article.
Thanks for the article, nice tips, I wasn’t aware of some of them (the 512×512 having to match the 57×57 being a surprising one!), useful to know and save time.
On a related note, I have a rejection story. My free app which sends multitouch information over wifi (using OSC formatted as the standard TUIO protocol) got rejected for ‘minimal user functionality’. The description may sound like a mouthful, but it’s actually quite simple – TUIO is an opensource OSC protocol for transmitting multitouch information (amongst other info) originally designed and used by the reacTable, now adapted quite widely amongst the multitouch community. There are opensource client libraries for many languages/platforms to receive and parse incoming TUIO messages for simple and rapid integration into multitouch applications (see http://www.tuio.org and http://www.nuigroup.org for more info).
Videos and more info on the rejected app can be found at memo.tv/msaremote_for_iphone
In Apple’s defense, I must add that none of the videos were online at the time, and I’m guessing Apple’s simply didn’t understand what the app was or how widespread Tuio was. After being rejected I uploaded the videos and contacted Apple, but haven’t head back yet (been about a month) 🙁
I must say I am very disappointed that Apple rejected this app simply because they think that people won’t want it.
Great list! We all appreciate it.
Speaking of unfair rejections, Apple has just rejected Peekababe, a sexy new app you can check out on YouTube, & the only thing you see is that the user can take the clothes off the beautiful models to leave them in their lingerie. Peekababe doesn’t have any kind of nude or pornographic pics.
So why did Apple reject it??? Apple rejected the app for claims of excessive sexual content. Oh, so it’s not OK for Peekababe’s models to show some skin and their lingerie, but it’s OK to kill, dismember, and chainsaw a game character on the iPhone?! Check it out at: https://www.youtube.com/watch?v=6-Wy0KyJ8I8
https://www.downloadsquad.com/2009/04/14/apples-double-standards-keep-too-sexy-app-out-of-itunes-store/
I’m glad to see this topic addressed in a practical way, without a lot of self-righteous indignation.
My app, BellyButton, was rejected for a disabled Lint button. It was deliberate on my part, who in their right mind wants a Lint button enabled! 🙂 It was intended as a joke but Apple wasn’t amused.
BellyButton was accepted after removal of the Lint button and is available in the AppStore now 100% Lint Free. 🙂
This might be obvious to most developers, but it bit me so it might be worth adding your pre-flight checklist: remember to test a “clean” install of your app. In other words, delete the app from your testing device and re-install it. Many apps have at least a little bit of code that only runs on the first launch. Luckily for me, the reviewer who caught a first-launch bug in my app generously provided a crash log and a helpful description of the problem that allowed me to fix it quickly.
The hardest type of rejection is based on a value judgment. Our upgrade was rejected due to a short urination sound clip in the same week an app dedicated to urination sounds was approved. It was the same sound that was approved in the currently selling version. Instead of arguing, we removed the sound and resubmitted. It was the 3rd rejection for our upgrade and we were feeling pretty sore, but they hold all the cards so there’s not much point in arguing.
Please add to the list the “in review for indefinite time” case as well. My app is in the queue since January.
Ezt beszoptad Gábor.
This also might be obvious: don’t rely on Apple announcements to have an influence on the review process. Case in point: Apple recently announced support for subscription-based apps. This validated the business model of our app in progress, which relies on very powerful (and expensive) search technology.
So we submitted 2 versions of our app: a lower priced one that expired in 30 days, and another that expired at the end of the quarter (June 30). Neither used any SDK 3.0 parts, and the app themselves would remain fully functional indefinitely – the only thing that happened after expriation is you couldn’t do any more searches. This was implemented on our servers, outside of the apps themselves, yet both apps were rejected.
This article is right – arguing, even politely, is fruitless. The reason the App Store exists is to sell more iPhones. There are already more than enough apps on the store to fulfill that objective. They don’t really *need* more apps, so if you paint outside the lines, your drawing just won’t be looked at.
Oh, in case you’re wondering, I resubmitted the app with no expiration. When StoreKit 3.0 is released, I’ll create a new subscription-based version and remove this one from the store. The initial buyers will be getting a heck of a deal.
My app has been stuck in the review process for over 4 weeks.
Here is what has happened:
* Submit app to iTunes Connect then wait a week.
* Rejection because of mysterious vague UI Human Guidelines baloney.
* Upload revised app next day.
* Wait a week to get message the review will unexpectedly take more time.
* Wait a week to get told an icon may infringe on Polaroid. This icon is two white rectanges and has been in the app since day one. You will find similar icons in nearly very app in the photography section. If this is really an issue it should have been flagged in the first review 3 weeks previous.
* Respond to tester that there is no infringement.
* Wait and hope (This is mostly what I do after uploading an app.)
I’m now trying to decide if it is a good or bad idea to pull the app down, change the dumb icon and resubmit. This will take 5 minutes, but I’ll have to wait another week to hear the next excuse for delay. My fear is that if I self reject the app it could just start the whole mess over again from the beginning.
The app has now been in the process for over 4 weeks and I have no idea if it will ever be approved. It is not breaking any guidelines, but someone in testing has decided they don’t like it and they just keep coming up with absurd reasons for rejection.
The frustrating part is that there is absolutely no 2 way communication. If someone would just email or call me and tell me what it is that they object to I could fix it, but they are playing games with me. There is zero transparency in the review process. Zero accountability. If someone decides they don’t like your app they have the means to delay it indefinitely, and as far as I know there is not anything I can do except wait a week to find out what silly reason they are going to use for the next rejection or delay.
We invested several months of work and expense in this product and my business success is at the whim of some tester who has decided to block it. I don’t understand how Apple allows this to happen to it’s developers. The tools and APIs are great. The approval process is very broken.
I made a database to share the reject case. I hope this will be useful for everybody.
https://iphone-rejectdb.appspot.com/
A helpful insight, thanks!
Thanks for the handy point, Brian. Any chance we could get some more details on the HIG gotchas? The bit about not using their buttons incorrectly is a good one.
The point about not fighting with Apple and just doing as they say is good advice here, but I do find the whole business depressing.
1984 revisited.
Only this time it’s not Microsoft.
Big Brother is Apple.
Why bother writing apps for the iPhone.
Having done a few, and dealt with cryptic rejection letters, it is a royal pain in the arse.
So why write them?
Because, as a masochist, this it the best way to artistically express myself…………
Forgot to add.
Wouldn’t be complaining if the whole iPhone developer program was free.
Now I paid my $99.
And suspect that along with many others, will never recoup that original cost.
At least the bots at Apple should reply to emails…they don’t. Even though I paid $99 to become an apps developer.
Eventually, my hope is that someone will file a class action lawsuit against Apple, allowing me to get back my $99.
Frankly, this whole thing as been nothing more than a royal ripoff.
I paid $99 to submit apps down a rabbit hole…
Other companies that have offered similar programs have had their businesses shut down by the FTC. Due to not delivering what was promised.
You know what I mean…the old “make money stuffing envelopes at home”.
How is Apple’s developer program any different if they take your money, and then no longer communicate with you on any meaningfull level?
When I had my credit card out, they were more than willing to help, with any glitches in the buying process.
Now having paid, I am just another ghost to them.
My local gym has the same program.
Join em up, take their annual fee, and hope they never come back to use the facilities.
These are isolated cases, or in some cases may be warranted if your app’s UI looks like garbage. I had a client whose app kept getting rejected for various reasons. He didn’t seem to understand when I told him why some of his design decisions were bad ideas. Then I just took free reign, changing his decisions to the correct ones – following the HIG, using an attractive design for the background – and it was accepted. Yes, if they don’t like your design, they may reject it. So don’t rule out the fact that you may not have any design taste.
So – if your app is hanging in review limbo (as mine is), does it make sense to self-reject which is meant to restart the process? Does it actually restart it, and do you get a new reviewer? I had a rejection after one week for a minor UI issue and re-uploaded within the hour. Now it is over 2 weeks later and I’d really go for that initial week turn-around again. Sigh.
Fcuk Apple for their censor control freak policy. Let’s hack them to the stoneage!
Or, well, to some degree HIG is very good and effective, but let’s just make a stamp “Apple approved” on approved apps and the rest is up to you the user to judge. I am an Apple fan but for one thing I will NEVER forget Apple for this stupid daddy abuse “knows best” attitude. They are also abusing this monopoly power by refusing e.g. Opera Browser as alternative to built in Safari , or Java, flash, or Silverlight runtimes. I will bust them hard for this whenever I get the chance.
Cheers!
I must admit, as both of my apps list all the fonts installed on the iPhone, I was expecting them both to be rejected because of this.
I submitted them anyway and both got approved!
The font chooser allows the user to choose a font to be displayed on the main screen.
Cheers
Graham
https://twurl.nl/ifoh2c – iAboutClock
https://twurl.nl/21g3ad – iTextClock
My first app CLBrowser was rejected many times for “contains objectionable content” violations. It clearly did not ‘contain’ the content as it was reading user generated content on CraigsList – Personals and Services sections had to be removed and also a keyword list omits any postings containing certain ‘bad’ words. We hope that we’ll be able to switch these limitations off with a parental security switch but I’m not sure about how that might work just yet. It took some months to get the application accepted because we got one rejection at a time, and didn’t really know what we should do at each juncture. Some phone calls with Apple people helped. It finally shipped but each update is at the whim of a tester who sometimes finds content they object to and we have to resubmit the update! I doubt this happens to the Facebook app or any user-content reading app from a large organization, but that’s life!
Is there any restriction of puting links into the app? The ideea is that i already made an app and i’m ready for submission but i want to follow this guide.
So i have several links into the APP that go to the site , and from the site you can buy subscriptions (not using Apple’s payment API ).
Will i get rejected for that because i’m puting links? or because i’m not using Apple’s payment API ?
Will it be better just to make an intermediary blog to link with? or just some labels with the http://WWW.MYSITE.COM without any functionality , or is providing link just prohibited
Thanks for the replyes guys. I apreciated!
great post! i will say make sure you do NOT put dollar amounts in your app description, that was a really dumb move on our part. It’s a localization fopar to say, “just $.99″… i can’t blame apple for that one. i fixed this just hours after they informed me of the issue and now it’s been almost a week and no more info. it almost feels like one mistake and you’re put in the slow queue.
Before my first app submission I have read the HIG and was very concerned about my splash screen. But because everbody else is doing it I submitted anyway and till now I had no problems. When Apple decides to change this the App Store will be half empty very soon 🙂