While I was developing the Palladio’s app, I was wondering if it would be accepted by Apple. I was worried about the discussions about Flash and third parties’ tools rejected from the App Store.

When it was time to do the submission, I carefully read all the tips from the Apple Developer center and I searched other possible causes of rejection. As a result, I discovered that you should pay attention to the following advices:

Core functionality issues and crashing

The two most common reasons for applications’ rejection deal with core functionality and crashing. You have to pay particular attention to:

  • both all the features written in the marketing text and release notes should work as described
  • all the buttons and menu items within the application should be fully functional
  • you should test your application on iPhone and iPod touch in addition to the iPhone Simulator. Various types of crashes, including crashes on launch, could be found if you test the app on an actual device.

Respect third party terms of service

If your application includes an external service, you should be aware of respecting its TOS. For instance, including Google Maps service requires Google’s logo inside the view.

Make sure you have the rights to your content

Ensure that you have the rights to all content used within your app, including code, icons, images, music, and the overall concept. If your content is questionable Apple will require proof of ownership.

Be careful transmitting user data

You can develop synchronization systems which send user generated data to a server, but before that you have to warn users. You are not allowed to send private data outside the device without informing users, so if you do not comply with this rule, your application will be rejected. Apple’s privacy rules are very strict.

The correct “Lite” version

Using a “Lite” version is permitted, but you need to follow these rules :

  • make sure the functionality you decide to include is complete
  • do not set time limits on your “Lite” version, either for run times or life times
  • only display the UI for what your “Lite” version will do. Avoid grayed out menu commands and do not reference to features which are not implemented or up-sold to the full version
  • information about your full application may be included either in your application’s About section or in the splash screen.

Include network error alerts in your code

If your application provides functionality which requires access to a network, it is very important that your code includes a customer alert or notification when the network is not available.

Specify the devices your app runs on

The App Store requires you providing metadata about your application before submitting it. If your app relies on features which are specific to a device, such as the compass on iPhone 3GS, you need to add the UIRequiredDeviceCapabilities key to your app’s info.plist file to indicate the specific hardware feature required.

Conclusions

This is not an exhaustive list of possible rejection motivations (see links on the right), but you can easily understand why it is not so unusual that an app might not be approved. Moreover, in addition to written rules, there are also some others that are based on “moods” and “pressures”. So, even if you manage to place your app inside the App Store, it can be kicked out without any advice and at any moment.