How to Submit an iOS App to App Store: Tips and Tricks

By Evgeniy Musiienko, Senior iOS Engineer

Intro

A new software product usually has a high chance to become successful if it gives something to the end-users which isn’t present yet in the market. It may be a completely new idea or a new, more convenient, ingenious way of representing existing ideas, products, or services. Although the right idea at the right time is the key to great products, it, of course, requires an excellent end solution, application with high quality, design, and user experience. And, finally, the idea should be announced to a potential customer, in advance in most cases. When the time and cost needed for implementation are planned, the release date is scheduled and announced to users, everyone wants everything to go according to the plan. 

This article is about one issue. An issue that is able to surprise iOS developers at the end phase of publishing a mobile app with App Store Connect – the all-important Apple App Store Review. Being aware of the guidelines, which the app submission review is based on, is important for designing a mobile app and verifying the initial idea, planning budgets, and prices.

The App Store Review Guideline Document

The keystone of the Apple product review is the document where Apple lists all the requirements and restrictions of any new app update or new product. It’s worth mentioning that the document is changeable and is constantly being updated. So any time someone checks it, it’s a reliable source of truth. I recommend visiting the page before analyzing existing or elaborating new app requirements to make sure that they don’t contradict with the guidelines. 

It’s a pretty interesting fact that the App Store may have a mobile app not following the rules. It’s possible that new guidelines or restrictions were introduced after the application was published or additional agreements between Apple and the producers were negotiated. However, it doesn’t mean that those apps can be taken as a precedent for any negotiations and, of course, it isn’t reasonable to just break any rules of the guidelines hoping that it will be accepted like some other mobile app. If product requirements really need some special treatment, it’s worth trying to consult Apple support, sometimes they may meet you halfway. The chances are higher if the point of the guideline is a recommendation and not a restriction. 

An example of this happened to me recently. It was related to the login with Apple feature, which Apple started requiring last year. The application update was rejected because it lacked this feature, nevertheless, the product owner managed to convince Apple to give the app a pass for this update. The main point of the negotiation was the fact that the app update contained a critical bug fix which needed to be released as fast as possible. However, we had to promise to add login with Apple in the next build.

The Main Parts of the Guidelines

Among all the requirements, I’d like to highlight some parts of the guidelines which I consider to be the most important and influential and which any Apple developer or business analyst must keep in mind while doing mobile app development

Payments

Basically, payments can be divided into 2 groups: payments for physical goods and payments for digital goods. Digital goods can be some game items, online content, unlocking functionality. An example of physical goods would be products in an online store. Apple’s policy is clear and strict: only in-app purchase (IAP) can be used for buying digital goods used in the application but the policy does NOT allow using in-app purchases for buying physical goods. The main thing to note of in-app purchases is that Apple charges a 30% fee on each transaction – and this is the main reason why almost any product owner wouldn’t mind avoiding those transactions. Unfortunately, there is nothing to do about this requirement apart from coming to terms with it. Below is a list of possible workarounds which have been tried(in my personal experience and experience of my colleagues) that don’t work.

• The first and the most obvious one – direct or indirect redirect to a website instead of an in-app purchase. For instance, there is a game where users can buy some equipment for the game and, to buy it, there is a link to an external online shop hidden somewhere in settings of the iOS app. Don’t even try, the application will be rejected.
• What if an application allows both methods: IAP and something else? Yes, it looks like we can divide payments on a 50/50 basis, some users will use IAP, some will use a website. Not so bad. Apple has specific guidelines that are not so univocal about this.. According to 3.1.1 “If you want to unlock features or functionality within your app … you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality …”. Here it’s clear that an IAP must be present in the app (ok, we have it), having other ways of buying goods isn’t mandatory, but it is also not restricted. Does it mean that it’s possible to add an alternative web page in the application which allows users to buy something? It depends. If another method is a simple website for buying goods or just some credit card based system inside the app, I have bad news – unfortunately, chances that the app will be rejected are still close to100%. It’s a cheat, and Apple recognizes cheats very well. However, a legal case is still possible and described in the section 3.1.3(b) of the guidelines – multi platform services. It says that, “Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired in your app on other platforms or your web site, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app”. This makes sense, Apple gives an opportunity to have another payment system other than IAP only where it’s really needed. If a service, or a game has a fully working instance on other platforms it’s possible to use items bought using these platforms in the iOS app. Good news for those who already have a system and want to extend it to the iOS platform.
• Another variation of the previous topic is not having any payment system inside the iPhone app, but having an ability to buy digital goods on another platform – a website being the most common case. It may work if the reviewer, who is testing the app, doesn’t know about the other platforms, but it’s a huge risk to take. When the application becomes successful and attracts more attention, this fact may become known. In this case, an Apple developer will come across a more serious problem, which is mentioned in the guidelines as well: “If you attempt to cheat the system (for example, by trying to trick the review process, steal user data, copy another developer’s work, manipulate ratings or App Store discovery) your apps will be removed from the store and you will be expelled from the Developer Program.”. Quite a big risk for your Apple Developer Account, right?

Apart from attempts to save the 30%, it’s important to understand Apple’s payments policy in order to avoid mistakes app developers make during iOS app development. For example, any application has to provide a restore mechanism so that users can restore all their purchased items if they use other devices or have to remove and install the app.

Background Modes

Among other hardware and software requirements, working in the background has always been a special feature. The first iOS versions didn’t allow to use it at all, and, starting from iOS 4.0, Apple opened it for developers for mobile app development. Although it gives many possibilities it’s still quite limited for battery saving purposes. Thus, it’s no surprise that we sometimes need a little more than is allowed for an iPhone app. Many apps for iOS need background data updates, synchronization or some calculations, but Apple says that background modes should be used only for particular tasks like location updates, audio, VoIP, etc – something to keep in mind when considering development of an iOS app. And, during reviews, they carefully check if an app uses a background mode only for something which is proposed.

For example, if an app has to perform calculations in the background and these calculations are triggered by location updates or audio events, it will be rejected. Moreover, using any device capability requires permission from end users and can be disabled at any time. Also, apps have to explain why they need a capability in their privacy policy section.

On the other hand, if an app already has a background mode for a reasonable purpose, nothing prevents it from adding some extra logic apart from the main. In any case, it’s always better to consider all the methods of meeting system requirements which use iOS capabilities in a way they propose.

App Rating Manipulation Prevention

Apple takes its rating system seriously and is very attentive to the ways an Apple developer may get feedback from the application users. It’s considered unacceptable to influenсe users in order to get more stars in the store review. The worst violation of this rule is any attempt to bribe the user. Thus, it’s not worth making up solutions giving users in game points, free subscriptions for a month or unlocking some new features for the sake of good ratings in your store review and risking the status of your Apple Developer Account. Less, but still dangerous is giving something for free and proposing to rate the app right after the user accepts it. Any behavior like this may lead to expulsion from the Apple Developer Program.

One more example of the app which was rejected had had the next solution implemented: It asked the user if they liked the app and, based on their choice, redirected them either to the Apple App Store or to the app’s internal feedback system. Despite not being a bribe, it was still manipulation in terms of the Apple Developer Program rules. The guidelines mention the criteria described only in one place which was given here a few topics above, but it’s worth quoting it one more time so that you never jeopardize your Apple Developer Account: “If you attempt to cheat the system (for example, by trying to trick the review process, steal user data, copy another developer’s work, manipulate ratings or App Store discovery) your apps will be removed from the store and you will be expelled from the Developer Program.”

Privacy

Talking about privacy, the general rule regarding mobile app development can be formulated as follows: any access to the user’s data must be explicitly accepted by the user. iOS apps must provide all the information about the purpose of accessing their data. The App Store guidelines have a whole section dedicated to privacy (5.1). It’s recommended for an iOS developer to read this section at the starting point of mobile app development. Applications should behave correctly if the user doesn’t give permissions to access some of their data. Many privacy settings may be changed in the phone’s settings when the app isn’t working. 

One more thing which is often forgotten by an Apple developer before their App Store submission, is adding a privacy policy section to the app. It can be a separate screen or a link to a web page. Writing a comprehensive privacy policy text usually takes some time and it’s much better to have it done before you prepare for a submission than after a rejection. Also, don’t forget to fill privacy policy descriptions in the project’s info.plist file for every capability using user’s data (location, health data, Bluetooth,etc). This information is then shown in the application’s App Store page.

Web-Based Applications

One of the controversial topics of the review process guidelines is web-based apps.  On one hand, there is no direct prohibition on such kinds of mobile apps on the Apple App Store. On the other hand, a few years ago there were lots of publications discussing rejections of cross-platform apps created with Cordova/PhoneGap. So you should be careful using those tools during app development for iOS. The controversy here is that actually Apple doesn’t reject all such web-based applications and sometimes it may be unclear what could go wrong if you decide to go this route with mobile app development. To better understand this, we should look to the chapters 4.2 and 2.5.2 or 2.59 (it’s not the full list though).

• 4.2 “Minimum Functionality
  Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store. If your App doesn’t provide some sort of lasting entertainment value, it may not be accepted. Apps that are simply a song or movie should be submitted to the iTunes Store. Apps that are simply a book or game guide should be submitted to the Apple Books Store.” This section can have an effect, for example, when an app is just a web page (or a web site) embedded in WebView. So, if a Cordova app is comparatively simple, Apple indeed may decide that it should’ve been implemented as an external web page. If your app doesn’t fit their definition of an app, you may look to publishing it with iTunes Connect.
• 2.5.2 “Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user.” The reason why Apple rejects such apps is that it’s possible to completely change it after the review and cheat the system or provide unacceptable functionality. Thus, having a webview for showing external content is OK, but it’s prohibited to load external functions, app screens outside the bundle.
• 2.5.9 “Apps that alter or disable the functions of standard switches, such as the Volume Up/Down and Ring/Silent switches, or other native user interface elements or behaviors will be rejected. For example, apps should not block links out to other apps or other features that users would expect to work a certain way. Learn more about proper handling of links.”. You can come across this rejection reason if the used cross-platform engine, not necessarily web-based, emulates the standard iOS interface in a way when it’s possible to tell the difference between native UI behavior and “like” native provided by the engine. So, the best solution here is choosing tools carefully. Luckily nowadays there are cross platform IDEs which translate internal language to native projects first, so the resulting app will be fully native. In the case of using web-based systems,designing a unique user interface will be the most reliable choice, that’s why, for instance, developing HTML5 games is safe in terms of the risk of being rejected during the review process (only if it uses only capabilities of the standard WebKit – p.4.7).

Other

One of Apple’s recent requirements during the App Store approval process is mandatory implementation of the login with Apple the app has login with at least one social network. The reason for this requirement doesn’t need an explanation.

Another violation of the guidelines is using private capabilities and APIs. It’s still possible in projects written using Objective C or sometimes JavaScript. Nowadays it’s almost impossible to do this inadvertently, but be mindful of the 3rd party libraries you use.

Conclusion

At the end of this, I’d like to draw your attention to a few interesting facts about Apple’s review of mobile apps before you prepare for submission. First of all, you shouldn’t consider this guide comprehensive. Apple’s app review process is flexible and sometimes decisions can be based on reasons outside the guidelines. And this statement is present in the review guidelines too – “ This is a living document; new apps presenting new questions may result in new rules at any time.” 

One more fact to keep in mind during the App Store approval process is that the iOS apps are tested by people and the human factor sometimes does impact the review. The same application can be approved after a rejection without any changes to the binary and vice versa.

Anyways, when you are finally ready to submit your iOS app, Apple’s review isn’t something to be afraid of if you have good intentions with your mobile app. Apple is interested in great new apps for iOS as app developers are interested in developing new, world-changing products.  Apple has even included this in the guidelines – “We love this stuff too, and honor what you do. We’re really trying our best to create the best platform in the world for you to express your talents and make a living, too.”

About the Author