Once an app has been published you may receive a rejection from Apple on Guideline 2.1 - Performance - App Completeness. This article outlines why this usually happens and presents the steps you can take to resolve it.
You will have received a notification that your app has been rejected by Apple because of Guideline 2.1 - Performance - App Completeness. Here is an example of a rejection message:
Guideline 2.1 - Performance - App Completeness
We discovered one or more bugs in your app when reviewed on iPhone and iPad running iOS 12.3.1 on Wi-Fi.
Specifically, _________________________________________________. (here the exact error message will vary depending on the actual issue)
To resolve this issue, please run your app on a device to identify any issues, then revise and resubmit your app for review.
If we misunderstood the intended behavior of your app, please reply to this message in Resolution Center to provide information on how these features were intended to work.
For new apps, uninstall all previous versions of your app from a device, then install and follow the steps to reproduce the issue. For updates, install the new version as an update to the previous version, then follow the steps to reproduce the issue.
For information about testing your app and preparing it for review, please see Technical Note TN2431: App Testing Guide.
For a networking overview, please review About Networking.
This rejection is usually related to metadata and binary rejections. The most common cases are:
- inaccurate screenshots
- incomplete information
- misleading, irrelevant information in the app's description
- bugs and crashes
- broken links
- placeholder content
- requesting permission even if not needed
- substandard user interface
Based on the exact error message above you would need to determine how to resolve it by using Technical Note TN2431: App Testing Guide.
To solve Metadata Rejections
- Verify the screenshots are accurate and follow the Screenshot Tools Best Practises
- If a login would be required for the app to be accessed, ensure that the Sign-in feature is disabled.
- To avoid this rejection while we implement the Sign in Apple functionality gets implemented, we suggest disabling all the third-party and social logins and then re-enable once the app is published.
To solve Binary Rejections
- Ensure that the app is tested on multiple iOS devices to ensure that it does not crash or report any bugs.
- All links within the app must work.
- The app, once live in the App Store must be 100% available with no content missing.
- The app should only request permissions to device features that it requires, and if requires location services, the app should explain why on initial start-up.
- The app must provide a good user experience and interface.
Once you follow the above recommendations and fix your app you can resubmit it to Apple and check if this time it got accepted.
Your app should adhere to the following guideline (taken from Apple Guidelines on Performance)
2.1 App Completeness
Submissions to App Review, including apps you make available for pre-order, should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission. Make sure your app has been tested on-device for bugs and stability before you submit it, and include demo account info (and turn on your back-end service!) if your app includes a login. If you offer in-app purchases in your app, make sure they are complete, up-to-date, and visible to the reviewer, or that you explain why not in your review notes. Please don’t treat App Review as a software testing service. We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems.
- Apple Guidelines on Performance
- Technical Note TN2431: App Testing Guide
- Screenshot Tools Best Practises
- Sign-in with Apple - Guidelines and Requirements