Today Apple lifted the clauses that restrict the use of certain tools for development. That is a big plus for Adobe and also AdMob. Developing for Apple takes patience and diligence, and even the most professional and detailed developers, like the ones on the Vensi team, can sometimes face initial rejection from Apple for an application.
It’s not that developing for other mobile platforms is easier; it’s just that Apple’s standards are so much more rigid – and sometimes seemingly arbitrary. Everything must be perfectly in place prior to submitting an application. We rarely have our applications rejected by Apple, and it is typically just a minor issue with the details of the description. Apple has some of the highest quality standards in the mobile application industry, and it speaks to the level of quality Vensi is capable of offering that the success rate of our developers is so high.
When we submit the application, our developers work hard to make sure everything part of the process goes through several checks. Even when a developer has everything in place, however, it is still possible to get rejected by Apple because of their stringent standards, particularly when you are submitting as many apps each month as Vensi does.
There are a few common reasons Apple rejects applications that developers should remain aware of:
- Violation of Apple’s Human Interface Guidelines (HIG). Apple has a very strict HIG which should be adhered to closely. For example, you cannot include any Apple specific images in the application, like the icons Apple uses. Create your own images rather than using Apple icons for your applications.
- Many applications are rejected by Apple because developers fail to carefully review their own description and correct errors. Proofread, proofread, proofread.
- Compatibility failures. If you claim that your app is compatible with a certain OS, be sure you’ve done the testing to make sure it will really work. It’s a swift rejection from Apple if it does not work as promised.
- Failure of the application to work as promised or to deliver the value promised. Obviously, the best way to avoid this issue is to ensure that you do plenty of testing.
In comparison, it may seem easier to develop for Android and Blackberry. Android does not do any review and the app is available almost instantaneously after it is submitted. Blackberry has similar review policies to Apple but does not conduct the same level of testing that Apple does.
We consider the Apple review process to be an excellent way for developers to enhance quality control. Receiving a rejection from Apple is a great way to help enhance quality, because Apple will often catch some minor detail that the developer can correct which will allow the application to be resubmitted. Developers can also address rejections internally to prevent that type of error from occurring in the future.
In our next post, we will provide additional tips to help developers navigate the Apple application process.