Why Did My App Get Rejected? A Guide to Apple’s App Store Rules

That “Rejected” email from Apple… it stings, right?

You’ve spent months building, and your app is finally ready. You hit “Submit for Review,” and then you get the bad news. So, why did my app get rejected by Apple? It’s a question every part of the team asks, from the developers to the C-suite.

Here’s the good news: it’s almost never a mystery. Apple isn’t trying to be difficult. They just have a rulebook, and they expect you to read it. The common App Store rejection reasons are often small, avoidable details.

We’ve distilled our takeaways so that you don’t have to learn the hard way. Think of this as the real-talk guide to the Apple App Store rules for developers that matter most.

Let’s be clear: Apple’s official requirements are comprehensive, and you should absolutely review the full App Store Review Guidelines document. But in today’s high-paced tech environment, we find it’s the small, “obvious” details that are most often overlooked. This guide focuses on those common, avoidable traps.

Before a reviewer even opens your app, they judge your store listing. This is your first impression. If it’s sloppy, they’ll assume your app is too.

This is an instant rejection and a classic Guideline 2.3: Accurate Metadata violation. If your designer used a beautiful mockup of an Android phone, you’re out. Apple, understandably, isn’t a fan of you showing a competitor’s hardware on their turf. Your screenshots must be on Apple hardware.

The reviewer also needs to see core functionality, not just your splash screen. Be sure to provide screenshots for all required device sizes (e.g., 6.7″ and 5.5″ for iPhones, 12.9″ for iPads), or your app may be rejected for not being optimized.

When you submit, you must provide a support URL, and a human reviewer will click it. If it’s a 404 page, a “coming soon” page, or a landing page with no contact info, you’ve failed the test. This is a common Guideline 2.1 (App Completeness) issue.

The app store support URL requirements mean the page must have a real way to get help, like a direct support email, a contact form, or a help desk.

This is the new boss level of app review. Apple is all-in on privacy, and this is where they check your work. Most rejections here fall under Guideline 5.1.1: Data Collection and Storage.

You added “Sign in with Google” to make things easy, but this can trigger a rejection. The App Store third-party login requirements are clear: if you offer any third-party login, you must also offer “Sign in with Apple” as an equal choice. You also have to justify why you need the data. This means writing clear “purpose strings” in your Info.plist file (e.g., NSUserTrackingUsageDescription).

Your app store privacy policy requirements must also be 100% honest. If you use Firebase, you’re collecting “Usage Data.” If you use a Facebook SDK, you’re collecting “User ID.” Apple’s scanners can detect these SDKs in your binary, so don’t hide them.

This is a major, non-negotiable rule. If your app lets users create an account, you must give them a clear, in-app way to delete that account. A “deactivate” button or a “mailto:” link is not enough. This is Guideline 5.1.1(v).

The button must be easy to find and must initiate the deletion of the user’s data, not just set a “deleted” flag in your database. If you use “Sign in with Apple,” you must also implement Apple’s API to revoke the user token on deletion.

This category is a catch-all for anything that feels broken, lazy, or incomplete.

This is the cardinal sin. If the app crashes when the reviewer opens it, you’re done. You must test on physical devices, not just the Xcode simulator. The reviewer might be on an old iPhone SE or a brand new iPad Pro. A crash on their device is a guaranteed rejection.

If your app is just your company website in a container, it will probably be rejected. It needs to feel like an app, not a slow webpage. This is Guideline 4.2: Minimum Functionality. A simple WKWebView wrapper around your site is not enough. You need to add native UI elements, push notifications, or other functionality that makes it a true app.

Any placeholder text (“Lorem Ipsum”), broken links, or buttons that do nothing will get you rejected. This falls under Guideline 2.1 (App Completeness). If you have a feature greyed out with a “coming soon” label, your app is not complete. Don’t submit it. Every single button must work.

Remember, a real person is testing your app. Don’t make them guess.

If your app has a login screen, you must provide a working demo account (username and password) in the “App Review Information” section. Make sure this app store reviewer demo account has all features unlocked, especially any paid or subscription content. If the reviewer can’t test your features, they can’t approve them.

This is your one chance to talk to your reviewer. Is your app complex? Does it need a specific setup? Write a clear, polite note explaining exactly how to test complex features. If you fixed a previous rejection, explain how you fixed it here. A little guidance goes a long way.

Look, the app store review guidelines explained here aren’t meant to scare you. They’re just the rules of the game.

Pushing an app to the App Store doesn’t have to be a gamble. When you know what the reviewers are looking for, you can stop guessing and start shipping. It’s not a mystery box, it’s a checklist. And now you know what’s on it.

But knowing what’s on the checklist is one thing. Executing it perfectly is another. It’s a lot of technical grunt work that takes time and focus away from building your next great feature.

If you’d rather focus on your product instead of Apple’s rulebook, let’s talk. We handle this every day. Schedule the no bs call with us, and let’s get your app approved.