Many developers grumble against Apple’s closed ecosystem approach, but you can’t argue that it’s one of the company’s biggest competitive advantages.
However, maintaining that ecosystem means Apple has to tightly control all aspects of their world, especially with third-party app developers.
That’s why the App Store has the strictest approval process compared to other app marketplaces like Google Play.
In fact, only last year, Apple reportedly rejected 150,000 apps submitted to their store.
Being aware of the most common reasons for App Store rejection is vital for developers to avoid unnecessary delays, added costs, and development headaches.
So, here’s what to cross off your app store submission checklist if you want to succeed.
Table of Contents
App Content Is Inappropriate
Apps dealing with sensitive or objectionable content, such as porn and gambling, are automatically rejected by the App Store.
They would also not approve apps that encourage dangerous behavior like racism, realistic violence, and substance abuse.
It’s easy to see why Apple would screen out such types of content.
Remember that, as per their guidelines, they intend to give all their users a safe experience.
Any app that threatens this basic tenet will get cut out.
Luckily, this is a problem that you can quickly spot and solve as early as your app planning stage.
If you feel that your app will easily offend people or entice them to break the law, rejection is highly likely.
You can either modify your concept or avoid launching it through the App Store altogether.
Get your free copy and find out how successful entrepreneurs define parameters of success!
The tricky part, though, is when inappropriate user-generated content gets involved. If it ends up dominating your app, Apple will remove it from the App Store.
To get around this dilemma, you can place filtering or reporting mechanisms to block inappropriate content and ban repeat offenders if necessary.
This is how social media sites like Facebook and Instagram control the integrity of their platform’s content.
The App Is a Copy of Another App
Apps that are closely similar to another app already in the App Store will also fail to get approval.
These so-called copycats often take the best-selling app in the App Store, do some minor changes, then pass their product off as a fresh idea.
Blatant copying should be avoided by all developers on any platform, not just Apple app makers.
Besides being a rip-off of the hard work done by other programmers and designers, it’s also a lawsuit waiting to happen.
The solution is simple—you should come up with a unique app concept.
Do thorough research on existing apps on the App Store to see how saturated your app category is, then try to come up with a different experience.
A similar but unrelated issue is spamming, which is when a developer submits multiple variations of the same app.
For example, a developer might create separate map apps with the same features and UI but for different cities or countries.
Apple treats spamming as a more serious offense which can end up having your developer account removed.
The best resolution is to combine all app variations into one container app.
Hardware and Software Are Not Compatible
Making universal apps that run well and look great on all of the latest Apple devices and iOS updates is a fantastic way to increase your approval chances.
In particular, you should ensure that iPhone apps work well on a bigger iPad screen, and vice versa.
The key to creating universal apps is automatically resizing your app’s layout depending on the screen dimension or orientation (portrait or landscape) the user is on.
This is called an adaptive layout, and you can use Apple’s layout tools like Auto Layout to achieve this.
You should also use higher resolution assets and images that won’t blur when blown up. This ensures your UI elements remain crisp when displayed on an iPad.
Once you have an adaptive layout, edit your app deployment settings in Xcode to ensure your app gets deployed on all Apple platforms.
Set the target device to both iPhone and iPad, and optionally the deployment target to the lowest iOS version it can run on.
However, simply running the app on every Apple device is just the beginning.
It’s also vital that you don’t damage or degrade the user’s device in any way.
Excessive battery usage and heat generation are common examples.
Additionally, you can’t ask users to disable core iOS features or run unauthorized background processes on the user’s device.
To avoid these performance issues, make sure your app is using resources efficiently.
For instance, it’s better to use notifications to let users know that a countdown has finished instead of an in-app timer that continuously consumes resources.
Reduce or avoid background processes to make sure your apps use up as little memory as possible when they’re idle.
You Have No Privacy Policy
A privacy policy is a legal agreement that shows users how your app collects and deals with personal data.
Apple requires all app developers to include a privacy policy to comply with privacy laws, such as the GDPR in Europe and various FTC rules in the US.
Even if your app is not collecting any personal data, you should still have a privacy policy in place.
Simply state that your app is not getting any personal information from your user in any way. Here’s an example.
To avoid rejection, make sure that your privacy policy is easily accessible both within your app and app page in the App Store.
Example of app privacy info
It should explain how you use the specific data that you collect: how it’s stored, and whether or not you share it with other third-party entities.
While a privacy policy entails legal language, writing it isn’t too difficult. Every app in the App Store has a privacy policy, and you can simply base yours off theirs.
Nevertheless, when in doubt, it’s still best to get a lawyer to help you write one to ensure it covers everything.
App Wants to Share Personal User Data
Apps must abide by Apple’s privacy rules, including how data is tracked, stored, and shared with third-party entities.
A breach of these rules can be grounds for the removal of your app from the App Store.
In a way, this isn’t at all bad for legitimate app developers like you. It shows people how you value their data and privacy, which can foster trust with your user base.
As with our previous suggestion, including a privacy policy in-app is the first step to abide by Apple’s privacy rules.
Still, to go beyond that, you need to follow through and be transparent.
If you intend to share their data with another company, disclose who that is and how they’ll use it.
Above all, users must have control over their data at all times.
Always ask permission from your users first if your app needs to collect any, and give them the option of deleting all copies of their personal information on your side whenever they want.
You’re Using Private API
A private API is any Apple function or class that’s undocumented and, therefore, not meant for developers to use.
Including private API calls in your app code will flag a warning from Apple and prevent approval.
Private APIs are used internally by Apple for their documented public APIs. Using private APIs is risky because their functionality is not guaranteed.
They can be changed or replaced by Apple without any warning, potentially affecting your app’s functionality.
Fixing private API issues is relatively straightforward—simply replace the private API calls with public ones.
The easiest and most common way to fail to obtain approval from the App Store is if your app crashes or has significant bugs during the review.
Apple is notoriously uncompromising of this standard, and hence why it’s at the top of their app rejection list.
To prevent this from happening, you first have to realize just how rigorous Apple’s review process is.
Your app will face a series of stress and performance tests designed to break your app.
Knowing this, the best way to ensure approval is to perform the same level of testing yourself before submission.
Ensure that every feature is thoroughly reviewed and testedfor all possible situations to expose potential flaws and bugs.
It’s also crucial to test run your app physically on every Apple device (and not just rely on emulators) to catch any UI or layout glitches.
You can use Apple’s TestFlight or other third-party services to invite beta testers to go through your app before launching it on the App Store.
Another great option is to have your testers use bug-reporting tools, such as Shake, which allows them to report any errors instantly by shaking their device.
Of course, it’s unrealistic to expect that you’ll catch every possible bug and error during testing, and that’s not the goal here.
As long as you can detect and fix all the major errors that will make your app unusable, you should get approval.
Unusually Long Load Times
Apps that take an unusually long time to load can lead to a poor user experience and are, therefore, candidates for rejection.
Slow load times can cause users to think that your app froze or their device crashed.
It almost always leads to frustration when someone wants to use your app to solve an immediate problem, and they can’t.
There are many causes of slow load times, just as there are multiple ways to fix it.
If you can, simplify the user interface and optimize your code to make it run faster. You can also try compressing images and assets to reduce load times.
For apps that need to connect to a server, ensure that the connection is being used efficiently.
For example, request only the data the app needs to display immediately to reduce bandwidth usage.
If slow load times are unavoidable (for example, in graphics-heavy games), it’s a good idea to mask them with a splash or loading screen.
Displaying in-game tips or other helpful content is a common tactic used in video games and might be an excellent method for your app.
Broken Links in the App
Broken links are frowned upon by Apple.
These are links that point to an incorrect or non-existent resource on the Internet and, therefore, do not work.
A broken link is yet another sign of poor performance that degrades your user’s experience.
For example, if a link to your support page is not working, it will be harder for your users to solve an immediate problem.
This will inevitably reflect poorly on you as a developer, as it shows neglect.
To avoid such an event, thoroughly check all your app links and see if they point to the correct page, especially Help pages and your privacy policy.
In case you deleted or moved the webpage that a link is pointing to, a quick fix is to do a simple redirect to the new resource.
Placeholder Content Is Still in the App
A placeholder or dummy content is a temporary container that’s often used during development to represent where content will eventually go once your app goes live.
The most notable example of this is the “Lorem Ipsum” template used in web and print design.
Because it’s a development technique, having placeholder content in your app is a sign that it’s not yet complete.
Non-completeness violations like this are one of the chief reasons to get rejected from the App Store. They indicate developer neglect and cast your app in a poor light.
Having placeholder content in an app that’s supposed to be complete might seem like a simple omission, but it’s surprisingly common.
It can be relatively easy to miss a placeholder or two in the final app, especially in tight development schedules.
The best way to avoid this issue is to have a thorough testing regimen and pre-launch checklist in place.
Inspecting every corner of your app ensures that you catch these simple mistakes before submission.
App Appears to Be Unfinished
As we’ve covered in the previous item, Apple rejects any app that it deems incomplete, so ensure your app is 100% ready before submission with a pre-launch checklist.
Most items on a pre-launch checklist are trivial but crucial, like updating links, removing temporary content, and making sure all of your app’s features are working.
Also, provide a working dummy account, so app reviewers can check features that require a login.
However, even if your app is complete, using the wrong version number or words in your app name can flag it as incomplete in Apple’s eyes.
App versions like “0.1” or words like “beta” or “alpha” send the signal that your app is still in the beta stage (even if it’s not) and might cause App Store rejection.
Remember that the App Store is only for finished, fully functional apps that are ready for distribution. Betas and trials should be deployed on TestFlight instead.
Incomplete or Inaccurate Metadata
Metadata refers to the information users see on your App Store page before downloading your app.
It includes app descriptions, screenshots, age ratings, payment options, and privacy information.
Having incomplete or inaccurate metadata can mislead users with the wrong information, which can break their trust. Unsurprisingly, Apple will refuse to approve your app because of this.
Apple’s example of inaccurate screenshots
The key to creating accurate metadata is transparency.
In your app description, clearly describe what your app can do. Avoid using unrelated words solely to exaggerate your app’s features or boost App Store visibility.
The screenshots should depict the app in-use and not just the title screen or other artwork.
If your app has in-app purchases, it’s critical that you state this clearly on your metadata.
It’s good practice to indicate which features of a free app are actually free and which ones require a subscription to unlock.
Ensure your app is also rated for the right age group so that it can be appropriately filtered through the App Store’s parental controls.
Lastly, remember that users of all ages can see your app’s metadata in the App Store, so make sure it’s appropriate for everyone, even if your app’s content isn’t.
As an example, your app icon and screenshot should not depict violence or scary scenes.
Low-Quality UI
Apple expects that all apps have a refined and well-designed interface that’s easy and intuitive for users.
A poor UI that fails to meet standards can make your app difficult to navigate, warranting rejection.
Fortunately, Apple has plenty of resources for app developers to ensure this doesn’t happen.
Marko started DECODE with co-founders Peter and Mario, and a decade later, leads the company as CEO. His role is now almost entirely centred around business strategy, though his extensive background in software engineering makes sure he sees the future of the company from every angle.
A graduate of the University of Zagreb’s Faculty of Electrical Engineering and Computing, he’s fascinated by the architecture of mobile apps and reactive programming, and a strong believer in life-long learning. Always ready for action. Or an impromptu skiing trip.
