There has been a revolutionary growth in iOS applications since Apple opened its stores to developers eight years ago. Over 1.5 million apps are available on Apple’s App Store as of today. Even though Android apps outnumber iOS apps, I think the latter have an edge in terms of quality because of the rigorous review process they go through before being accepted. Apple rejects junk apps outright and approves only those that conform to its high standards. To many iOS app developers, the App Store submission process is a major roadblock for meeting deadlines. Unexpected rejections can prove costly for clients for whom time is of great value, especially when competition in a domain is very high. Developers can appeal against rejection, but the process consumes more time. Whatever precautions a developer takes, there could still be loopholes that reviewers could pick on. For example, a pre-existing feature in a new version of the app that you submit for review can get you rejected.

App Store Review and Approval—Our Experience

Over the past few years, my teammates and I have made numerous App Store submissions, faced a few rejections, and learned a few valuable lessons from them about ensuring timely approval. Apple provides fairly exhaustive guidelines for iOS app developers and going through them looking for potential violations can be a tedious process. I’m sharing some of the things we’ve learned, so developers who are new to the platform or the review process can avoid the same mistakes we once made.

1. Metadata

Rejections related to metadata are very common, and when they happen, we do not have to resubmit the build again. We can edit the metadata and submit for review again. Here are some aspects you need to take care of with respect to metadata:
  • Demo user credentials: If your app has a login feature, make sure you give login credentials so that the Apple reviewer can navigate to the inner pages of the page and inspect all the features. Make sure that the user has the privilege to see all the features of the app. Apple expects us to provide login credentials even if there is a signup feature on an app.
  • App ratings: Pay attention to app ratings! We gave a rating of 4+ to one of our apps, attesting that it had no objectionable material. However, the app had a feature to show pictures uploaded by users. At the same time, the app did not have the provision for review before displaying those pictures. Our app was promptly rejected. We had to change the rating of the app to get it approved.
  • Name of the app: The name displayed below the app icon on the device and the one you submit to iTunes should be similar. It is not mandatory to have the very same names, but there should be some similarities.
  • Demo/beta or lite version: Call your app Demo or Beta and you risk getting rejected right away, regardless of whether it’s a paid or free version. You may call it “Lite.” Even if the application icon has the word Beta, your app will be rejected.
  • Broken links: All links provided in the metadata, such as support URL, marketing URL and so on, should be functional. Apple rejects the app if any of these links does not respond. The links should be public and should not require user authentication.

2. App Crashes

Apple will not entertain unstable apps or apps that crash. You have to make sure your apps do not crash during the review. Say, you have submitted the first version of an app and you are working on the second version. Make sure the back end is not affected by your work on the second version. It is ideal to have versioning in web services as well so that backend changes won’t affect the older versions of live applications.

3. Creative Designs

Apple is very, very strict about the User Interface (UI). All iPhone users are familiar with the icons and navigation in inbuilt Apple applications. Your applications should not have icons that resemble or contradict them. Nor should you imitate icons of other apps or they will be deemed fraudulent or misleading and rejected. Once our app was rejected because an icon we used for friends looked like the contacts icon in iPhone. Even if we use a similar icon, it should be for a similar functionality. For example, a button similar to the contacts icon should be used for accessing contacts.

4. Architecture/Navigation

In App payment/payment gateway integration: Apple wants us to go for In App purchase (IAP) as it earns them 30% of the revenue. If we are not using IAP, then we need to give an explanation for not doing so. Only for services offered outside the app, actual products sold and so on can we use third-party payment gateways like Paypal or Authorize.net. For unlocking any digital content or features, subscription, and so on, we will have to use In App purchase. A few more pointers:
  • Any content or section or page in the application that is not dependent on user accounts should be shown prior to log in/sign up. Terms and Conditions, About Us, and Contact Us are some common examples. Apple insists these pages be made available to users before they sign up or log in.
  • Asking users for personal information and making it mandatory is sure cause for rejection. Apps that require users to share their gender, age, email address, date of birth, and other private information in order to function will be rejected.
  • Do not ever show the names of other platforms that support your app. Even if your app is available on Android or Windows, you should not advertise them within the app.
  • Use the Advertising Identifier Filter (IDFA) carefully. When you submit your app for review, you’ll be asked whether your app uses IDFA to serve advertisements. If you select “YES” and if your app doesn’t show any ads or if the ads won’t load up properly, your app will be rejected.
  • Apps that display user-generated content must include provisions for filtering objectionable material, flagging offensive content, and blocking abusive users from the service.
  • Removing device support: An important and very potential reason for rejection is removing support for a particular set of devices that were supported earlier. Usually, this happens when we decide not to support iPod or iPads in newer versions of an app. Apple wants us to make sure that all users get future updates of an application when they update their OS.
This is not a complete set of reminders for iOS app development and submission, but the ones my team collected over the years. By keeping them in mind while you plan the architecture of an iOS app, you can definitely avoid last-minute rework. Also, I recommend you keep at least one week buffer period while you submit so that even if the application goes through a rejection cycle, you can get it reviewed again and released as planned. Good luck with your iOS app approval process!
No Image