The App Store Rejected My App! Now What?

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.

Where Should I Start?

So what should you do when your app is rejected? Here are some useful starting steps:

1. Read the rejection message carefully. They will usually be pretty clear what is wrong, though they will sometimes reference aspects of the App Store terms document or use terms you may not know.
2. If you feel the App Store is mistaken about something, you can send them feedback through App Store Connect - just be aware it may take them some time to respond. You can also write the App Review Board.
3. Try to replicate the problem the App Store team saw. When using in-app purchases, try running a fresh install from a TestFlight build (not built from Xcode) on device, using the iTunes Sandbox for purchase testing.
4. While you are looking into the problem review reported, double check other related systems work - the review team only reports one issue at a time, even if you have multiple issues with the application they could seemingly easily discover at once.
5. This may go without saying, but check StackOverflow for the wording the App Store team used in your rejections. They mostly use the same wording across many applications, so chances are someone had a similar rejection and might be able to help clarify what aspect of the app has been rejected and how they solved the problem.

👉Read more: Offering App Store Alternative Payments in South Korea

5 Tips to Avoid Rejections Related to StoreKit, In-App Purchases and Subscriptions

Here are specific suggestions to issues we’ve seen submitting apps with purchases:

1. For in-app purchases in particular, make sure all of your purchases you need have been added to the build you are submitting for review - if you don't have all of the product metadata filled out, you'll not be able to add that product for review.
2. For subscription purchases, be aware that Apple will try out all products you are submitting for review, even if there are multiple subscriptions in the same application group - so make sure you also have tested all of your products in the iOS sandbox before submitting the app for review.
3. If you have products, make sure that terms and conditions of purchases are available somewhere in your application, along with the option to restore purchases.
4. If you have any complex uses of your app especially around purchasing, add to the "Notes" field in the app metadata for submission - you can explain common uses of the app or direct them to specific screens for purposes of testing functionality. Often just noting down how your app works can avoid confusion. It could also help them test the application faster, since they are not trying to figure out how your app works from scratch. Make sure to carefully test all of the things you tell them to try!
5. Nami can help avoid rejections due to purchase issues, as our SDK is built to to handle StoreKit errors and interactions so you don't need to worry about edge cases the reviewers might test. You should always test your in-app purchases in the iOS sandbox to be sure everything works as expected in your application when purchases are made, and can use the Nami bypassStoreKit setting to test app purchase reaction when using the simulator.

Solutions to Common Rejections

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

‍

‍