The procedure of getting your new iOS application approved at the App Store is a hard piece of work. That’s why it’s very important to have it done by someone experienced. For example, development companies make deployment an inherent part of the development cycle. There is much more that’s required from apps than being consistent and bug-less, not having obscene content, and not copying the functionality of Apple’s default apps. Each and every way to get your app rejected is stated in Apple’s guidelines; here we describe some of the most interesting ones.
1. Offer An App Of Questionable Value
Follow the Apple’s guidelines – they won’t accept an application if it’s basically an advertisement for the sake of advertisement, if it’s a collection of websites, pages, or links. Apps must have some obvious functional value, smooth workflow and useful, relevant content to be approved. And of course, it cannot provide poor and unintuitive user experience.
2. Let The Load Drag
Every platform has a limit for app load time. If it’s more than 15 seconds for iOS, Apple is most likely to send a rejection letter. There can be such additional problem as bad and slow Internet connection, but that’s cured by testing on real devices, not only on a simulator. Another thing is making sure that the app loads fast on older iOS versions and devices – the ones that are mentioned as supported. In general, dragging load brings chances to be rejected not only by Apple, but also by users, if the app makes it to the store.
3. Show That Your App Is Unfinished
This includes screens saying something like ”coming soon”, versions less than 1.0 and indications like ”beta”, ”trial” or ”demo”. Unlike Google, Apple doesn’t accept the uncertain beta versions. You have to offer a polished and finished software product.
4. Mess Up The Permissions
There are two basic ways to mess up the permissions. First, the application mustn’t access the address book, photo gallery, location, calendar, social accounts etc. without the user’s permission. Second, the application mustn’t crash if the access is denied by the user (initially or later in settings). No matter whether the user allows or denies access, your app must run anyway. If the app wants to gather peculiar data about the user for a database, again this must be done with the user’s permission only.
5. Link To Third-Party Payment Systems
Apple offers a system of in-app purchases for selling digital content. Each of such purchases has to go through the iTunes accounts of users. What should be mentioned, is that non-digital content (such as booking rooms at hotels) is not subject to this rule.
6. Mention A Rival Platform
Actually nobody likes mentioning that the app supports rival platforms. Apple isn’t an exception. It’s better to leave this to a promotional web page. If you want to get the app rejected, put this information into the description, or even worse, into the application.
7. Misuse Trademarked Content (Including Apple’s)
Your application won’t be accepted if it contains trademarked content, for example, Apple’s logos, icons, images of products, or even the word ‘iPhone’. It’s also interesting that Apple doesn’t like when Steve Jobs is mentioned within the app, no matter in what context. Just avoid infringing trademark issues, and not only Apple’s, in your software’s name, description and content.
8. Try To Trick Apple
I wonder if anyone is able to do that. For example, trying to hide forbidden content behind a secret gesture. Apple will have your app thoroughly examined, and tricking its testing is an aimless idea. And why would you do it actually?
None of these problems is incurable from the very beginning of building an application, unless a violation is intentional. But again, why would anyone do it? Apple is proud of the way it protects the App Store and its users from low-quality apps and malware. But while some of the reasons are absolutely obvious, others (such as rival platform mentions or links to third-party payment systems) may not be expected. But even if an app is rejected, Apple states the reason and is open to resubmission.
Author: Oleg Lola