Every quarter, a significant percentage of the total number of apps submitted at the Apple Store gets rejected. In what follows, we have highlighted some important points that would boost the chances of an app being approved.
Unlike at the Google Play Store, getting new apps approved at the Apple App Store can be just a trifle tricky. Developers need to follow a host of terms and guidelines, while creating applications and submitting them at the store. Although the Cupertino company does not release any official figure regarding the volume/percentage of the total volume of rejected apps, 58% of all rejections can be attributed to ten rather common factors (or mistakes, from the point of view of developers). Here’s a checklist of key store review guidelines that need to be followed, to maximize the chances of an iOS app going from ‘In Review’ to ‘Ready For Sale’:
- Test your apps. Thoroughly – Apple takes the issue of app bugginess very seriously. According to available stas, over 3% of all app rejections occur due to the presence of bugs/malware, and resultant app crashes. Mobile app companies need to have separate teams of testers, who would be in charge of checking all the features of applications, before they are submitted at the store. In addition to the simulators (available in Xcode), new apps have to be installed and tested on actual devices too. What’s more – apps that cause excessive battery drain and/or are likely to cause harm to the target Apple device(s) in any way are rejected forthwith.
- Follow the 4+ rating – Every visual element of an app at the store – right from screenshots and previews, to app icons have to conform to the 4+ age rating – as specified by Apple. There should not be any differences between the small and large icons of the same iPhone/iPad/iPod/Watch app. In case iOS app developers assign incorrect ratings to their apps or include them under a wrong category/genre, they should brace themselves for rejection too. The name of the app at iTunes Connect and on the device have to be identical.
- Location APIs and user permissions – Indiscriminate usage of location-based APIs is an absolute ‘no-no’ in iOS applications. Experts from the field of mobile app development advise against using any API in a new app, for either emergency purposes or controlling automobiles/planes on an automated basis. App developers also have to make sure that their mobile software asks for user permissions before collecting location-based data and using the same for any purpose. Provided that the necessary permissions are obtained, location data can be used by an app for advertisements.
- Stay away from duplication – For new iPhone app developers, the temptation to simply replicate an existing iTunes application can be immense (after all, there are well over 1.5 million apps, many of them are successful, so why not just make a copy of any one of them?). Doing so, however, would be an ideal recipe of getting a new app rejected. The rejection risks increase in proportion with the number of apps that are similar to a newly submitted application (e.g., flashlight apps). Never release multiple versions of the same app, which would be treated as spamming. If an app is found to be a miniature version of a website, or if it does not provide any long-term value, it will be in violation of the app review guidelines too.
- Placeholder text and metadata – Apple clearly specifies that new apps cannot contain any placeholder text. Those that have placeholder content are invariably deemed as ‘incomplete’, and hence, are generally rejected. If an iPhone app company wishes to submit a beta app, it can do so only through TestFlight (there is a separate set of TestFlight guidelines to be followed). The metadata of an app cannot contain the name of any other mobile platform either. In case the description is not found to be relevant/related to the actual functionality of the app, that is another criterion for rejection. Close to 2% of app rejections at the App Store occur due to incorrect app descriptions provided by developers.
- In-app purchases – Revenues from freemium apps are growing at a rapid clip (the growth was more than 200% last year). However, app developers need to be careful while implementing freemium features in their iOS software. No other purchasing mechanism other than Apple’s in-app purchase (IAP) method can be included in an application. The services or content (e.g., new digital storybooks in a mobile app for kids) have to be available within the app as well. It is possible to use in-app purchases for providing credits/currency – but the same must not get expired, and should be consumable within the application. The IAP subscriptions should remain available to users for a minimum of seven days.
- App advertising guidelines – Although including in-app ads is a valid mobile app monetization strategy, abusing this method can lead to new apps getting rejected. Developers should never resort to any shady, underhand methods to increase the click-through rates (CTR) of the advertisements present in their apps. Every quarter, plenty of iPhone apps get rejected, simply because their prime purpose is displaying ads (i.e., they do not deliver any specific ‘value’ to end-users). There should not be any blank iAd banners present in the app either.
- Implementing push notification functionality – If an app has push notifications feature, the same should be available for free to users (i.e., they are not liable to pay any charges for such features). There is a specific API called Apple Push Notification, which has to be used for implementing the notification feature (the unique Push Application ID has to be obtained beforehand). Via push notifications, no form of personal/confidential information can be transferred. Nor can they be used for the sole purpose of displaying promotional content. Make sure that no form of malware gets transmitted through push notifications. An iOS application cannot download any type of codes either – so be wary about that.
- Size and functionality – Any iOS app development expert worth his/her salt would know that apps should never exceed the maximum size limit of 100 MB. Non-compliance to this limit will make the app non-downloadable over any cellular network. The features and functions of the app have to match the descriptions provided by the concerned app company (read: no hidden functionality allowed). Apple also prohibits the usage of non-public APIs in new applications. The onus lies on iOS developers to ensure that their applications do not make use of any data from sources other than the assigned counters. If a feature is present in an app but is not documented by the developer, it would almost surely get rejected.
- Stay away from using offensive content – While creating apps or games, developers have to make sure that no group or community is being deliberately downgraded in any way. For example, in a game application, the ‘villain’ or ‘enemy’ must not be depicted as members of a particular community (race, caste, etc.). App companies are not supposed to submit apps that are similar to/are variants of Russian roulette, or encourage violence and usage of realistic weapons. Apple places prime emphasis on parental control features in the iPhone apps for kids at the store – and that’s precisely why applications with any form of ‘crude content’ are liable to get rejected immediately. In general too, an app should give users the option to flag inappropriate content.
- Media and content streaming – The data used by an app for streaming audio content cannot exceed the limit of 5MB (over a period of five minutes). For large video streaming (e.g., for longer than 10 minutes), a 192 kbps baseline has to be used, along with the HTTP Live Streaming feature. There is a bar against replicating the interface of the iTunes store in any of the screens of a new app as well. The media resources in the Apple Media Library can, of course, be accessed by an app – but for that, the latter should be using the available MediaPlayer framework. If audio or video content is downloadable from third party channels (e.g., SoundCloud or YouTube), separate authorizations are required.
- Following Game Center guidelines – This is vital for iOS game developers. Those who try to reverse lookup, data harvest, trace, or misuse Player IDs in any way run the risk of getting booted out from the iOS Developer Program altogether. Final users of the game app should not be able to view Player IDs, while leaderboards can be displayed only after the required approval is obtained from the Game Center. During the testing phase, developers have to check whether any type of unnecessary data, virus, programs or files (generally used for phishing purposes) are being transferred via the Game Center. If an app uses Player IDs for any purpose that is in conflict with Apple’s terms of service, it is simply waiting to be rejected.
- iPad compatibility and resource usage – While creating an iPhone app, a developer needs to ensure that it would be downloadable and usable on the iPad too – at a resolution level of 2X iPhone 3GS. Apple also provides WebKit JavaScript resources (apart from the WebKit framework), which have to be used by applications that have web-browsing features. App-makers do not have the permission of specifying which carriers their app will be compatible with, while location-based exclusion of users is not allowed either. In addition, an app should not be created for the purpose of promoting/marketing/encouraging the download of another application. The regulations specified in the iOS Data Storage Guidelines (https://developer.apple.com/icloud/documentation/data-storage/index.html) also have to be followed.
- Charity apps, lotteries and sweepstakes – Apple does not take any responsibility regarding the sponsorship of mobile sweepstakes. The concerned app development company needs to declare itself as the sponsor of the contests/sweepstakes. There is a prohibition clause against allowing users to purchase raffle tickets directly from an iOS application. In case a lottery app is submitted at the store, the same should have all the legal permits, provide all pertinent information to users, and must not involve transference of real money for gaming purposes. Charity-based applications have to be free, with text messaging or web browser services being used for the collection of donations.
- Making iOS apps for kids – The App Store has a vast range of children’s apps – right from mobile storytelling apps to learning apps for kids. Developers are required to specify the age range that their apps target (for instance, 6-8 or 9-11, etc.). These apps cannot have advertisements that are customized with the behavior of the end-users (kids) on them. For outbound linking from the app and/or in-app purchases, parental gateways/permissions have to be used. An iPhone app for kids should also contain a detailed privacy policy, and must not violate the security considerations of the little users in any way.
- Apple Pay, HomeKit and HealthKit – Proper Apple Pay branding has to be used by iOS apps that offer mobile payment options to users. The items available for purchase should not violate any territorial law, and the app needs to have a privacy policy as well. User-data can be shared only for the purpose of facilitating the delivery process of the purchased goods and services. All relevant information should be available on the app, prior to the purchase being made. The HomeKit framework may be used by developers for including home automation functionalities only. Care has to be taken to make sure that the HomeKit APIs are not being used to harvest or mine data, or use them for any other unauthorized purpose. Apps that include the HealthKit framework are not supposed to store any form of user-health data on iCloud. Once again, a privacy policy document is necessary, providing inaccurate data is prohibited, and the HealthKit API must not allow third-party access of a user’s health information without prior permissions.
iOS developers working on apps with extensions need to carefully go through the information provided in the App Extension Programming Guide (https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/ExtensibilityPG/index.html). Providing previews of iTunes music in a new app is strictly prohibited. Apps that use Passbook credentials have to be created in line with the specified guidelines. No form of pornographic applications are allowed at the App Store, and developers should never try to access user-passwords by including hidden data transfer features in an app. WatchKit developers need to think beyond applications that only show the time and do little else. To be approved at the App Store, an iOS application needs to have high-quality user-interface, in-app navigation and layouts.
Around 6% apps were rejected last quarter because their interfaces were not user-friendly enough. More significantly, over 13% were dumped due to absence of adequate information provided by their developers. Make sure that you follow all the clauses of the Apple Program License Agreement. You are putting in the hard yards to make a new, unique app – finding that it has been rejected would certainly be disappointing!
Hussain Fakhruddin
CEO at Teknowledge Software
Hussain Fakhruddin is the founder/CEO of Teknowledge mobile apps company. He heads a large team of app developers, and has overseen the creation of nearly 600 applications. Apart from app development, his interests include reading, traveling and online blogging.
Latest posts by Hussain Fakhruddin (see all)
- How do mobile apps help small businesses? - October 10, 2019
- Top 15 Mobile App Ideas For 2020 - October 1, 2019
- Top 15 Software Development Trends To Watch Out For In 2020 - September 18, 2019