You spent months developing, testing and creating your app. The email comes: “We found an issue with your submission.” This can delay a launch, annoy stakeholders and cost money.
The good news? Most app rejections are preventable. Apps are reviewed based on a set of public guidelines by Apple, and these rejections occur time and time again. You know the things reviewers check, but all you need is to address them before submitting.
This article will outline why apps are rejected, explain the most common reasons and show how to deal with them. It finishes with a checklist.
Why Apps Get Rejected by the App Store
App’s review process takes care of the user’s safety. The reviewer checks for the safety of the app, its functionalities, privacy policies, fair money transactions, and offers something of value for downloading. Any feature that fails to meet the above criteria could lead to rejection.
Here are some common reasons behind the majority of rejections:
Violation of guidelines. Many development teams tend to ignore the guidelines because, in their opinion, everything is right in the app. However, there are many other aspects to it – legal issues, payment guidelines, privacy policy, etc.
Rushing to finish before the deadline. A development team is trying to meet the deadline without final testing, leaving placeholder content or ignoring to provide login credentials.
Changes in Apple’s policy. The policy is changing frequently and what worked last year won’t work this year.
A rejection is not a ban. Apple tells you which guideline you broke, and you can fix the issue and resubmit. Most apps that follow the guidelines get through. Understanding the common triggers saves you several review cycles.
Top App Store Rejection Reasons and How to Fix Them
The following ten issues account for a large share of rejections. For each one, here is what goes wrong and how to prevent it.
➺ Privacy and Data Protection Violations
Privacy is one of the most stringently enforced categories. Apple requires you to be explicit about the data you collect, the reason why you collect it, and how you utilize it. Common violations are:
The lack of or broken privacy policy URL
Inconsistency between privacy labels on the App Store and actual data collected
Collection of data without users’ proper consent
SDKs collecting data without disclosing it
User tracking across the apps without the usage of the App Tracking Transparency permission prompt
How to avoid: Audit all SDKs and analytics tools in your app, and ensure that your privacy policy and privacy labels reflect the actual data collection process. Request the consent in clear words and only collect data which you actually need. Use the proper permission prompt in case you track users. Make sure your privacy policy URL works both in the app and in App Store Connect.
➺ App Crashes or Appears Unfinished
According to the completeness guidelines for apps, you should present the final product. Any crashes on the opening of the application, freezing, incorrect URLs, broken images or “lorem ipsum” texts will cause rejection of the project. Labels such as beta or “coming soon,” as well as unfinished sections, are also negative factors.
How to avoid this mistake: Test your application on real devices, not only on simulators, and test all the supported iOS versions and all screen resolutions. Go through all screens and buttons. Delete placeholder texts, test links and debugging code. Make sure to fix any issues that can be found in TestFlight.
➺ Reviewer Cannot Access or Test the App
Perhaps this is one of the most annoying rejects, since it could be easily prevented. For instance, if you have any login functionality and do not provide valid credentials for your app, the reviewer will not be able to use it. The same is true for the features depending on an unresponsive backend, missing hardware, or a location the reviewer is unable to access.
What you need to do in order to prevent this: Offer a demo account with full functional in the “App Review Information” section of App Store Connect. Make sure your servers are up and running while the reviewing process is going on. If your application requires hardware, a certain region, or a subscription, make note of it in your reviewing materials.
➺ Missing Account Deletion
If your app gives users the ability to create an account, then it should give them the ability to delete their account through the app as well. It’s unacceptable to hide the possibility of deletion behind an email message or make the process of deletion happen by taking users to a website. This problem is often forgotten by many teams because they start building registration processes first.
How to avoid it: Provide your users with the ability to delete their accounts, explain to them which information would be deleted in that case. Confirm this action and finally, delete the user’s data. In case it’s needed to store some data according to the law, it should be explained to users.
➺ Copycat or Low-Value Apps
Apple wants no clones in their store. An app may get rejected for being a copy of someone else’s app, using a name or icon from a famous app or providing minimal functionality. A web site enclosed in an app wrapper, a template app branded differently or a plethora of identical apps by one single developer may all fall into the category of spam or minimum functionality apps.
How to avoid it: Provide your app with a clear function and a feature list which makes it worth installing. Native features like notifications, offline availability or device integration will add extra value to your app compared to a mobile website. Be unique with names, icons and designs. If you develop apps for different customers from one template, make sure each of them stands out.
➺ Copyright and Intellectual Property Violations
Plagiarizing something that is copyrighted is a fast way to have your app rejected. This includes images, music, logos, trademark names or any software used beyond its license terms. Apps which use names of other companies, or make you believe they are associated with another brand while this association does not exist, are not acceptable as well.
How to prevent this: Use only your own or copyrighted content or make sure that you have the license for it. Make sure that your app does not use anything owned by the other companies such as their logos, characters or brands in your icon, screenshots or description without a written permission.
➺ Content Guideline Violations
Offensive, harmful, or inappropriate content is also not accepted at Apple. This involves hate speech, graphic content, explicit material, and other activities which promote or contain anything related to crime. For apps which involve user-generated content, stricter rules apply. They should have content filtering, report mechanisms, blocking options for abusive users, and fast response to any complaints.
How to avoid this mistake: Check if your content violates any guidelines and fix it. Make sure your app is ready for content moderation if the users will be able to share something. Set the right age rating, since an incorrect one is one of the reasons for rejection.
➺ In-App Purchase and Payment Issues
In general, Apple demands that digital goods and services, including subscriptions, paid features, and in-app purchases of any kind, be made through Apple’s In-App Purchase system. This rejection occurs when an app tries to direct users to use another means of payment besides in-app purchases for the digital goods, or does not provide information on subscriptions or does not offer a way to restore purchases.
What you can do to prevent it: Unless an exemption applies to your app in your territory, use Apple’s In-App Purchase for digital goods. Display prices, billing cycle, trial period, and how to cancel subscriptions. Provide a “Restore Purchases” button. Test purchases in the sandbox environment. Make sure all products offered in the app are set up and approved in App Store Connect.
➺ Incomplete or Inaccurate App Metadata
Metadata includes everything that users see before they download your app – its name, subtitle, description, screenshots, keywords, and category. The reviewer makes sure that your metadata matches the actual app. The most frequent issues are screenshots of the features that do not exist in the app, references to another platform in the description, keyword abuse, and inclusion of competitor names in the title.
How to avoid it: Use screenshots of the current version of your app only. Describe what your app does now. Keep your name and subtitle relevant. Do not use unverifiable statements like “the number one app” if you cannot prove it. Check that your support URL and contact information work properly.
➺ Unjustified Background Features or Permissions
Permissions must be requested only when needed, and the request itself should make sense to the user. For example, requesting access to location, camera, contacts or microphone without any logical explanation will lead to rejection. The background operation must be relevant to the user.
How to prevent this: Permissions must be requested only when necessary, and there must be specific explanations of what it will be used for. “We use your location to show you nearby stores” is much more appropriate than a general explanation. Remove unused permissions and background modes from the application. If the feature can work without certain permission, then it should be optional.
How to Prepare Your App Before App Store Submission (Checklist)
A short pre-submission routine catches most problems. Before you hit submit, confirm the following:
🢡 Functionality
The app runs without crashes on supported devices and OS versions
All buttons, links and flows work
No placeholder text, test data or debug code remains
Privacy policy is live and linked in the app and in App Store Connect
Privacy labels match actual data collection, including SDKs
Permission requests are necessary and have clear explanations
Tracking consent is implemented where required
🢡 Accounts and access
Demo credentials are provided and tested
Account deletion is available in the app
Review notes explain special features or hardware
🢡 Payments
In-app purchases are configured and tested
Subscription terms and prices are clearly displayed
“Restore Purchases” works
🢡 Content and legal
All images, fonts, music and code are original or licensed
Moderation and reporting tools exist for user-generated content
Age rating is accurate
🢡 Metadata
Screenshots reflect the current app
Description, name and keywords are accurate and compliant
Support and marketing URLs work
Finally, read the latest App Review Guidelines. They change over time, and a quick review before each release is cheap insurance.
Conclusion
A rejection from the App Store is a disappointment, but it is usually something that can be fixed. Most rejections are due to the same reasons: unclear privacy policy, unstable or incomplete build, lack of demo access, account deletion, bad or plagiarized idea, rights violation, dangerous content, payment problems, misleading metadata and unnecessary permissions.
In case of a rejection, read the message from Apple and fix the mentioned problem. In case you think it was a wrong decision, you can appeal.
Don’t treat compliance as a separate process, but as an integral part of the development process. Develop according to the guidelines, test and submit your app with all the required information.
