So your app was rejected. App Store rejections are common but are usually simple to resolve. This article covers typical rejection reasons, including those relating to apps utilizing StoreKit, in-app purchases and subscriptions.
Table of Contents:
This article is for people who have submitted to the App Store, but have had the application rejected for some kind of technical (not policy) reason.
First of all, don't panic! App Store rejections are pretty common and it does not affect your standing with Apple or necessarily mean you have a serious problem to fix. Often it’s a small detail of Apple's requirements you need to address, and then all will be well.
So what should you do when your app is rejected? Here are some useful starting steps:
👉Read more: Offering App Store Alternative Payments in South Korea
Here are specific suggestions to issues we’ve seen submitting apps with purchases:
Authentication Screen Remained open
Apple considers your payment request screen (paywall) to be a form of authentication, they are saying after a purchase was made there was no indication from the app the purchase succeeded - such as dismissing the paywall view.
Solution: Try to reproduce a case where a paywall remains open after purchase. Does turning off the network not yield any messages when attempting to purchase? Would any error case in purchasing leave the screen up? Make sure a successful purchase messages the user.
Guideline 5.2.1 - Legal - Intellectual Property
This means App Store review has found images in your application or in app preview images for the App Store that are copyrighted - for example if your application sample images showed album covers or images from other people.
Solution: One possibility for App Store preview items, is to simply blur out copyrighted material from preview images so that it is no longer recognizable. You could also edit out anything copyrighted and replace with images you do have rights to.
Guideline 3.1.1 - Business - Payments - In-App Purchase
Read the details of the problem they had, one common item is that your application did not offer a way to restore purchases.
Solution: If your app does offer a restore purchase option, respond directing them as to where it can be found. If it does not already, add that feature - usually it is placed somewhere on the product selection screen (paywall).
Guideline 3.1.2 - Business - Payments - Subscriptions
This category includes specific issues with subscriptions.
One common possibility here is that you forgot to include some way to access purchase terms, and the privacy policy of your app.
Solution: These can be anywhere, make sure to point out where they can be found if the app reviewer says they are missing but you have included them. One common technique is to have these legal documents hosted on your website, and use a Safari web view in your app to display them for reading.
Guideline 2.1 - Performance - App Completeness
This guideline can come into play if you've forgotten to include products to submit with the build of the application you are submitting to the App Store.
Solution: If you have not filled out all product metadata (including screen shots of the purchase screen for app review), then the section to include products in the app metadata for review will not appear - make sure all of the products you want to use in the release of your application are marked as "ready for review" and have been added to a build you are submitting for review.
Another possibility: Tapping purchase buttons produces no result.
Solution: If a user attempts to purchase, there should always be some indication by the application that it is attempting to make a purchase - make sure that the button will always initiate a purchase with StoreKit, and listen to any possible response to fail gracefully if StoreKit returns any errors. Double-check all of your purchases from a device Sandbox test account, to make sure you do not have anything like incorrect product identifiers, and are listening to transaction results from Apple.
Another possibility: A user attempted an in-app purchase outside the application, but the app did not show the purchase was made (for example, an App Store page that shows subscription options might be used to make a purchase instead of in-app).
Solution: Make sure you start up store kit listeners at app launch, and process any incoming transactions as soon as you see them - ave some way for the application to react to purchases made at any time, not just when on a purchase screen (paywall).
Guideline 2.1 - Performance
This more general category may arise if your application does not work on IPV6 networks. They will mention this in the notes if that is the issue.
Solution: Check Apple's documentation on supporting IPV6 networking, including some common items to look for that may trip up IPV6 support. Learn more about how to set up an IPV6 network for testing.
Missing Info.plist key
Accessing a variety of protected system features, like location or bluetooth, requires an entry in the info.plist. Over time, Apple may add new entries (as when they added “when in use”) that require new entries for capabilities you supported with other plots entries previously.
Solution: Review all of the plist entries required for protected capabilities your app supports, also make sure they are clear as to why the user needs to grant you access to that ability.
For more impactful abilities like the location “always” permission, you may want to add something to the Notes metadata file the app submission, so the reviewer is clear as to why the application needs that permission.
👉Read more: What the Epic v. Apple Ruling Could Mean for Your App