You spent months building the app. You hit submit. Then the email arrives: “We noticed an issue with your submission.”

An app store rejection is frustrating, but it is also extremely common. Most rejections come from a small set of repeat problems, and almost all of them can be fixed in a day or two once you know what the reviewer is actually asking for.

This guide covers the 15 most common reasons apps get rejected by the Apple App Store and Google Play, what each message really means, and the exact fix. If you are about to submit, use it as a pre-launch checklist and avoid the rejection altogether.

Quick note: Store policies change often. Always confirm the details against the current Apple App Review Guidelines and the Google Play Developer Policy Center before you resubmit.

Quick Summary: The Most Common Rejection Reasons

#	Reason	Store	Typical fix time
1	Crashes and bugs	Both	1 to 3 days
2	Broken or missing demo account	Apple	Under 1 hour
3	Incomplete or misleading metadata	Both	1 to 2 hours
4	Missing or weak privacy policy	Both	1 day
5	No in-app account deletion	Apple	1 to 3 days
6	Wrong payment method for digital goods	Both	2 to 7 days
7	Minimum functionality (thin app)	Apple	Varies
8	Spam or copycat app	Both	Varies
9	Login options not compliant	Apple	1 to 2 days
10	Inaccurate data safety / privacy labels	Both	2 to 4 hours
11	Requesting unnecessary permissions	Both	1 day
12	User-generated content without moderation	Both	2 to 5 days
13	Placeholder content and broken links	Apple	1 to 2 hours
14	Outdated SDK or target API level	Both	1 to 5 days
15	Testing requirements not met	Google Play	2 to 3 weeks

1. Crashes, Bugs and Poor Performance

What the reviewer says: Often cited as Guideline 2.1: Performance, App Completeness on Apple. On Google Play it appears as a broken functionality or stability violation.

This is the number one reason for rejection. Reviewers test on real devices, on real networks, often on an older OS version than the one you developed against.

How to fix it:

• Test on at least one older device and one older OS version, not only your latest phone.
• Test on a slow connection and with no connection at all. Many crashes happen when an API call times out.
• Use TestFlight (iOS) and internal testing tracks (Android) before you submit for review.
• Add crash reporting such as Firebase Crashlytics or Sentry so you can see crashes you cannot reproduce.

2. Broken or Missing Demo Account

If your app needs a login, Apple’s reviewers cannot test it without credentials. This causes a large share of avoidable rejections, especially for B2B apps and SaaS companion apps.

How to fix it:

• Provide a working demo username and password in the App Review notes.
• Make sure the demo account has real data in it so every screen can be tested.
• If login needs two-factor authentication or a hardware device, supply a bypass or detailed instructions.
• Check that the demo account has not expired or been locked before you submit.

3. Incomplete or Misleading Metadata

Your screenshots, description and app name must match what the app actually does. Reviewers reject apps that show features the app does not have, mention competing platforms, or stuff keywords into the title.

How to fix it:

• Use screenshots taken from the real app, not marketing mockups showing unreleased features.
• Keep the app name short and free of keyword stuffing.
• Do not mention other platforms or competitors in your description.
• Make sure every feature you advertise is available in the submitted build.

4. Missing or Weak Privacy Policy

Both stores require a privacy policy link for most apps, and it has to explain what data you collect and how you use it. A generic template that does not match your real data practices will get flagged.

How to fix it:

• Host the policy on a public, working URL (not a PDF download that errors out).
• List every data type you collect, including analytics, crash logs and advertising identifiers.
• Name any third-party SDKs that receive user data.
• Link to it inside the app as well as in the store listing.

5. No Way to Delete an Account Inside the App

If your app lets people create an account, Apple expects them to be able to start the deletion process from inside the app. Google Play has a similar requirement and also asks for a web link where users can request deletion.

How to fix it:

• Add a clearly labelled “Delete account” option in settings.
• Make it a real deletion flow, not just “deactivate” or “email support”.
• Explain what gets deleted and what is legally retained.
• Add the matching deletion URL in the Google Play Console.

6. Using the Wrong Payment Method for Digital Goods

This one catches many SaaS and subscription apps. In general, if you sell digital content or features that are consumed inside the app, the stores expect you to use their in-app purchase system. Physical goods and real-world services (a taxi ride, a product delivery) are treated differently.

How to fix it:

• Decide whether what you sell is a digital good or a physical or real-world service.
• For digital subscriptions, implement Apple In-App Purchase and Google Play Billing.
• Rules on linking out to external payment pages differ by region and have changed over the past few years, so check the current rules for the countries you launch in.
• Do not hide or disguise an external payment link. That is a fast route to rejection.

If you are building a mobile companion for an existing SaaS product, plan your billing approach before development. Changing it late is expensive.

7. Minimum Functionality (A “Thin” App)

Apple rejects apps that feel like a website wrapped in a shell, or apps that do too little to justify being an app. This is often cited under Guideline 4.2: Minimum Functionality.

How to fix it:

• Use native capabilities where they make sense: push notifications, offline access, camera, biometrics.
• Make sure the app does more than display a mobile website in a web view.
• Explain in the review notes what the app does that the website cannot.

8. Spam, Copycat or Template Apps

Submitting many near-identical apps from one template, or copying another app’s design and name, triggers a spam rejection (often Guideline 4.3).

How to fix it:

• Differentiate the app with unique features, branding and content.
• If you build apps for multiple clients, consider one app with multiple configurations instead of many cloned apps. Apple has specific rules about template and white-label apps.
• Never imitate another app’s icon, name or layout.

9. Login Options That Don’t Meet the Rules

If you offer third-party sign-in (Google, Facebook and similar), Apple requires an additional login option that meets its privacy standards. Sign in with Apple is the common way to satisfy this, and the guideline allows other equivalent options that limit data collection.

How to fix it:

• Add Sign in with Apple alongside your other social logins, or add an equivalent privacy-focused option.
• Do not force users to give extra personal data just to create an account.
• Check the current wording of the login services guideline, since it has been updated before.

10. Inaccurate Privacy Labels or Data Safety Form

Apple’s privacy nutrition labels and Google’s Data Safety section must match what your app and its SDKs actually do. Reviewers and automated scans compare your declaration with the app’s behavior.

How to fix it:

• Audit every SDK: analytics, ads, crash reporting, attribution, chat widgets.
• Declare data collected by third-party SDKs, not just your own code.
• Update the declaration every time you add or change an SDK.

11. Asking for Permissions You Don’t Need

Requesting location, contacts, camera or microphone without a clear reason is a common rejection trigger. The permission prompt text also has to explain why you need it.

How to fix it:

• Request only the permissions the app genuinely needs.
• Ask at the moment the feature is used, not on first launch.
• Write specific usage descriptions, such as “We use your camera to scan invoices”, not “This app needs camera access”.
• Make sure the app still works reasonably if the user says no.

12. User-Generated Content Without Moderation

If users can post comments, photos, reviews or messages, both stores expect safeguards.

How to fix it:

• Add a way to report content and block abusive users.
• Publish clear terms of use and a moderation process.
• Give users contact details for support and make sure you can act on reports quickly.

13. Placeholder Content and Broken Links

Lorem ipsum text, empty screens, dead support URLs and “coming soon” buttons all signal an unfinished app.

How to fix it:

• Search your build for placeholder text before every submission.
• Click every link and button, including those in settings and the footer.
• Remove or hide any feature that is not ready. Do not ship a button that does nothing.

14. Outdated SDK or Target API Level

Both stores raise minimum requirements over time. Apple requires builds made with a recent Xcode and SDK version. Google Play requires new apps and updates to target a recent Android API level, and apps that fall behind can lose visibility or be blocked from updates.

How to fix it:

• Check the current minimum Xcode and SDK version on Apple’s developer site before each release.
• Check Google’s current target API level requirement in the Play Console.
• For React Native and Flutter apps, keep the framework and native dependencies updated on a regular schedule, not only when a rejection forces you to.

15. Google Play Testing Requirements Not Met

Newly created personal Google Play developer accounts have to run a closed test with a minimum number of testers for a minimum number of days before they can apply for production access. Teams that skip this discover it right before launch.

How to fix it:

• Check the current tester and duration requirement in the Play Console help documentation.
• Start the closed test early, at least three weeks before your planned launch.
• Recruit real testers and collect feedback during the testing period.
• If you publish for clients, consider an organization account, which can have different requirements.

What to Do When Your App Gets Rejected

A rejection is a to-do list, not a verdict. Follow this process:

1. Read the full message. The guideline number and the reviewer’s comments tell you exactly what to fix.
2. Reproduce the problem. If you cannot, ask for more detail through the Resolution Center (Apple) or the appeal and contact options in Play Console.
3. Fix the root cause. Do not patch only the screen the reviewer mentioned. The same issue often exists elsewhere.
4. Reply with specifics. In your resubmission notes, explain what you changed and where to find it.
5. Appeal only if you are confident. If the reviewer misread your app, you can appeal politely with evidence, such as a screen recording.

Pre-Submission Checklist

Before you press submit, confirm:

• The app runs without crashes on older devices and slow networks
• A working demo account is in the review notes
• Screenshots and description match the real app
• Privacy policy is live and accurate
• Account deletion works inside the app
• Billing uses the correct payment system for digital goods
• Privacy labels and Data Safety form match your SDKs
• Permissions are minimal and clearly explained
• No placeholder text, dead links or unfinished features
• Build uses the current required SDK and target API level

Frequently Asked Questions

How long does an App Store review take?

Many apps are reviewed within a day or two, but timing varies by season, app type and whether it is a first submission. Plan your launch date with a buffer and do not submit on the day you need to go live.

Can I resubmit immediately after a rejection?

Yes. Once you have fixed the issue, you can resubmit right away. There is no mandatory waiting period for a normal rejection.

Why was my app rejected for something I did not change?

Store policies and automated checks change over time, and a different reviewer may be stricter about a rule that passed before. Always re-read the current guidelines before each release.

Is Google Play easier to get approved on than the App Store?

Google Play’s initial review is often faster, but it has strict policy enforcement, data safety checks and testing requirements. Neither store is easy to ignore. Prepare properly for both.

Should I hire a developer to handle store submissions?

If you are launching your first app or you build apps for clients, an experienced team can save you weeks. Planning for store requirements during development is far cheaper than reworking features after a rejection.

Final Thoughts

Most app rejections are predictable. Crashes, missing demo accounts, privacy gaps, payment rules and outdated SDKs account for a large share of them, and every one is preventable with a proper checklist.

If you want to launch your iOS or Android app without costly delays, the team at Software Flux Solution builds and ships React Native, iOS and Android apps, including App Store and Google Play submission and post-launch support. Contact us to talk through your app.