App Store Rejection Reasons: Top Causes and How to Fix Them

Apps get rejected from the App Store for five broad reasons. According to Apple's 2024 App Store Transparency Report, "Performance, legal, design, business, and safety were the top reasons for rejection, in that order." In practice, that usually means a crash or broken feature, missing privacy details, an app that feels like a website, a payment rule problem or unsafe content.

The good news is that a rejection is rarely final. We submit apps for clients to both stores, with more than 10 apps live on the App Store and Google Play, and almost every rejection we see comes from a short list of fixable problems. This guide covers that list, the Google Play side, and how to reply to App Review and resubmit.

How often does Apple reject apps?

Often. These figures come from Apple's 2024 App Store Transparency Report, as covered by MacRumors.

Many of those rejections are updates to existing apps, not just first submissions. Even experienced teams get rejected. What matters is how fast you fix the issue and get back in the queue.

The most common App Store rejection reasons

1. The app is incomplete or crashes (Guideline 2.1)

Performance problems are the top category, and guideline 2.1, App Completeness, is where most of them land. Apple asks that submissions "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."

• Crashes or freezes on the device the reviewer uses, often an iPad when you only tested on iPhone.
• Buttons that do nothing, broken links or "coming soon" screens.
• Lorem ipsum text, test data or placeholder images.
• A login screen with no demo account. Apple asks you to "include demo account info (and turn on your back-end service!) if your app includes a login."

Fix: test the exact build you submit on several devices, remove anything unfinished, and put a working demo login and short instructions in the App Review notes.

2. Privacy details are missing or wrong (Guideline 5.1)

Legal issues are the second category, and privacy is the most common one we see. Guideline 5.1.1(i) says: "All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner."

• No privacy policy link inside the app, or a link that goes to a missing page.
• App Privacy answers that do not match what the app or its SDKs actually collect. Apple says this information, including what third-party partners collect, "is required to submit new apps and app updates."
• Asking for permissions like location or contacts without a clear reason in the permission prompt.
• Letting people create an account without a way to delete it inside the app.

Fix: list every SDK in your app, check what each one collects, update your privacy answers and add a visible privacy policy link and account deletion option in settings.

3. It looks like a repackaged website (Guideline 4.2)

Design is the third category, and for web-based apps the biggest risk is minimum functionality. Guideline 4.2 says an app "should include features, content, and UI that elevate it beyond a repackaged website." Guideline 4.2.2 adds that apps "shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links."

Fix: add native navigation, push notifications, offline handling and features people use after signing in. Our guide to converting a website to an app explains each one.

4. Payments break the business rules (Guideline 3)

Business rejections usually involve how you charge. Selling digital content or subscriptions inside the app generally has to go through Apple's in-app purchase system, while physical goods and services used outside the app do not. Rules on linking to outside payment options now differ by country, so check the current guideline 3.1 for each storefront you sell in.

Fix: map every purchase in the app to the right rule before you submit, and make sure any subscription shows its price and terms clearly.

5. Safety and content problems (Guideline 1)

Safety rejections cover objectionable content and apps with user-generated content that lack ways to report and block abusive users. If people can post anything in your app, build in reporting, blocking and a way for you to remove content.

6. Metadata that does not match the app

Screenshots that show features the app does not have, a description that promises too much, or screenshots of another platform's device all lead to rejections. Use the right sizes and real screens, as covered in our App Store screenshot size guide.

Why do apps get rejected on Google Play?

Google's review is mostly about policy compliance. In its February 2026 safety report, Google said: "In 2025, we prevented over 1.75 million policy-violating apps from being published on Google Play" and "banned more than 80,000 bad developer accounts that attempted to publish harmful apps." It also prevented more than 255,000 apps from getting excessive access to sensitive user data.

The rejections we see most often on Google Play are:

• Data safety form mismatches. The form says one thing and the app or an SDK does another.
• Sensitive permissions such as background location, SMS or all-files access without a clear core feature that needs them.
• A missing or broken privacy policy link.
• An outdated target API level. From August 31, 2026, Google says new apps and updates "must target Android 16 (API level 36) or higher."
• Misleading store listings, such as claims the app cannot back up or names that look like another brand.
• Apps that crash or do very little, which fall under Google's minimum functionality rules.

New personal developer accounts have one more hurdle. Accounts created after 13 November 2023 need a closed test with at least 12 testers opted in for 14 days before they can publish to production.

How do you fix and resubmit an App Store rejection?

When Apple rejects a submission, its status changes to Unresolved Issues and App Review sends a message that names the guideline. Read it carefully, because it usually says exactly what the reviewer saw.

1. 1Fix the problem. If it is in the code, upload a new build. If it is in the metadata, such as screenshots or the description, you can edit it without a new build.
2. 2Update the submission. Apple notes that "You can edit items in a submission once before resubmission."
3. 3Reply to App Review to explain what you changed (steps below).
4. 4Click Resubmit to App Review.

Apple says it typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours, so a quick fix often means approval within a day or two. If you need a critical bug fix out quickly or the app is tied to a time-sensitive event, you can request an expedited review.

How do you reply to App Review?

In App Store Connect, the Account Holder, an Admin or an App Manager can reply:

1. 1Go to Apps and select the app.
2. 2Click the unresolved issues link.
3. 3Under In Progress, click Resolve.
4. 4Click Reply to App Review, write your reply, attach a file if it helps, then click Reply.

Keep the reply short and specific. Say which guideline you addressed, what you changed and where the reviewer can see it. A screen recording is often the fastest way to show a feature the reviewer missed.

If you believe the app already follows the rules, you can appeal to the App Review Board. Apple asks you to "Provide specific reasons why you believe your app complies" and to "Submit only one appeal per submission that didn't pass review." Stay factual. Arguing with the reviewer rarely helps; showing them clearly usually does.

On Google Play, the email and the policy status page in the Play Console name the policy involved. Fix the issue and submit an updated release, or file an appeal if you believe the decision was a mistake.

A checklist before you submit

• The submitted build is tested on a current iPhone, an iPad if supported, and an Android phone.
• No placeholder text, test data or unfinished screens.
• A working demo account and short instructions in the review notes.
• A privacy policy link in the listing and inside the app.
• App Privacy and Data safety answers match every SDK in the app.
• Account deletion is available inside the app if users can sign up.
• Screenshots show the real app on the right device at the right size.
• Digital purchases follow each store's payment rules.
• The Android build targets the current required API level.

For the full process from accounts to launch, see how to publish an app on the App Store. If your app is built on Base44, our Base44 App Store guide covers the platform-specific steps.

Virtual Horizons is a Base44 Legend Partner, Ambassador and Community Pillar, a Base44 Shark Tank winner and a multiple-time Vibe Sprint winner. Through our mobile app service we prepare the submission, answer App Review and handle resubmissions until the app is live.

Roenic Natarelli

Founder, Virtual Horizons

Roenic runs Virtual Horizons and is a Base44 Legend Partner, Ambassador and Community Pillar, Base44 Shark Tank winner and multiple-time Vibe Sprint winner. The studio builds web and mobile apps, AI voice agents and automations, with more than 10 apps live on the App Store and Google Play. More about us