10 steps to ensure your iOS app is approved

In the past 10+ years that we have been developing apps for iOS, one thing that has remained consistent is clients having issues getting their apps approved. A lot of people, over the years, have come to us completely baffled on why Apple rejected their app and what to do next.

Apart from the obvious reasons like presence of objectionable content, copying an existing app or copyright issues in your app, here are 10 not-so-obvious reasons why your app might be rejected by Apple

Functionality

A lot of our clients building apps for their websites come to us when Apple rejects their app saying it is not suitable for the App Store. Usually, this applies for apps which do not use any native functionality provided by iOS. The apps generally encompass the same functionality that their website uses. And Apple thinks such apps are better suited to be released as web apps rather than on the App Store.

To prevent rejection due to this reason, when ideating your app, think about how you can add value to the app to justify it being released as a native app. Or re-think whether you need a native app or a responsive website is a better alternative for you.

Purchases

We regularly answer a lot of questions our clients have around purchases and subscriptions and many times, these become the reason why Apple rejects apps. There are various reasons around IAPs and payments that might prompt Apple from rejecting your app. Some of them being

1. Not providing in-app purchase as a payment option for selling digital goods inside an app. If your app makes digital goods available, make sure users can purchase them using IAPs
2. Not giving users an option to restore purchases - while this doesn’t take a long time to implement, not including a Restore option can increase your approval time due to multiple rejections and reviews
3. Not providing in-app purchase as a payment option if selling digital goods across platforms - at times users make digital goods/services available in apps across platforms (web, android apps, iOS apps). They feel that since the same purchase is available across multiple platforms, excluding Apple IAPs should be okay. Unfortunately, it is not. Apple requires you to still provide IAP as an option. You can have the user unlock the functionality by paying on other platforms, but they still need to be given an option to pay via the app

User-generated content

Many social apps are rejected by Apple because they do not provide the ability to moderate user-generated content. This would include any content posted by users and available to other users - comments, posts, images/videos etc. For any apps having such user-generated content, Apple requires that users be given the ability to report/flag content. They also need the app owners to have a system where they can monitor this flagged content (and other generated content) and remove it.

Some of our clients have come to us to get such a system built when Apple rejected their social apps saying they did not give users the ability to report content.

Collecting user information and its usage

When it comes to user information and privacy, Apple is very stringent on how/why you collect this information and use it. If they feel that your app doesn’t require user sign-ups to use the app functionality, or don’t need to provide certain info and still be able to use the app, they will likely reject the app asking why you need this information.

Also, if you are collecting this information, be explicit in your Terms of Service on how you intend to use this information or share it with others. A lack of these, and your app stands a chance to be rejected.

When any specific device functionality is being used - like recording audio, GPS location, accelerometer, the user should be asked for permission and shown clear indication of the same. Any attempt at hiding this information and your app will be rejected.

Hidden/undocumented features

Your app description should clearly state the app functionality. If some functionality is behind a paywall, there should be reason for that. If Apple finds out about any undocumented or hidden functionality, which is not apparent from the app description, they will reject the app.

If they figure out that some functionality of the app, which is essential to the functioning of the app as advertised, is behind a paywall, they will reject the app. For instance, if you are developing a social app, but it requires the user to pay via IAP for connecting with any other users, the app will be rejected. But if it does allow users to connect with others, and users can pay for unlocking certain advanced features, that is acceptable.

Use of background processes

Some app developers use background processes to keep their app running in the background, for completely unrelated functionality. If your app does that, Apple is bound to reject it. Apps must use background processes for related functionality - VoIP, location changes, audio playback etc.

Subscriptions

Subscriptions are a major part of monetization strategy for Apple developers. But with the past few versions of the App Store approval guidelines, Apple has added a few more rules for subscriptions in apps.

If your app provides subscriptions using Apple Pay or IAPs, it must give the following information to users

1. Length of the renewal term
2. A heads-up that the subscription will continue renewing till users cancel it
3. The functionality available with the subscription
4. The actual amount which will be charged
5. Steps to cancel subscriptions

Forced reviews/shares

As mentioned before, Apple likes its apps to be transparent in terms of what an app offers and how it uses the information provided to it. If your app forces users to commit certain actions for using the app or its features, it will be rejected.

Some examples of such actions - forcing the user to rate/review the app in order to continue using it, asking the user for additional information not required by the app in order to use it, asking the user to share the app with others to unlock certain functionality and so on

Use of commercialized templates/app generation services

This rule is a little subjective in nature and meant to be a deterrent for copycat apps which provide little or no value to end users. A lot of app generation services allow users to create templatized apps by using drag-drop functionality and specifying various config URLs (e.g. Mobile Roadie). If you use such a service, you cannot release the app under your own developer account. The app can only be released under the developer account of the app generation service.

There are certain exceptions to the rule. If a service lets you get the source code, make your own edits and submit, you can publish the app under your own account.

Competition

If your app provides direct competition to any of the Apple services (say Apple Music, Weather app etc) OR uses a UI which might confuse the users on whether they are using Apple apps or a custom app, your app will be rejected.

Be sure to read through the App Store review guidelines and Common causes for app rejection ensure that your app follows all the rules depending on the functionality. If you are still stumped on why Apple rejected your app, we would be happy to help.