App Store Rejection Reasons (and How to Avoid Them) in 2026

Most app store rejection reasons fall into a few groups: the app crashes or is incomplete, the reviewer cannot log in, privacy information is missing or wrong, the app asks for permissions it does not need, or the store listing does not match the app. Apple and Google both publish their rules, and almost every rejection we have seen maps to one of them. This guide covers the common ones as of September 2026, with links to the official guidelines and a checklist to run before you submit.

Rules change regularly. Always check the current Apple App Review Guidelines and the Google Play Developer Policy Center before a release.

1. Crashes, bugs and incomplete apps

This is the most basic reason, and still one of the most common. Apple’s guideline 2.1 (App Completeness) says submissions should be final versions with working URLs, and that Apple will reject apps that crash or show obvious technical problems. Google Play also rejects apps that do not work as described.

Typical causes:

• The app works on the simulator but crashes on a real device or a different OS version.
• Placeholder text (“Lorem ipsum”, “Coming soon”), empty screens or broken links.
• The backend is a staging server that was switched off, or it rate-limits the reviewer.

How to avoid it:

• Test release builds (not debug builds) on real, older devices as well as new ones.
• Use TestFlight and Google Play internal or closed testing before every production submission.
• Keep the production backend up during review, and watch your crash reporting on review day.

2. The reviewer cannot log in or reach features

Guideline 2.1 also asks you to include demo account details if your app has a login, and to keep your backend running. If reviewers hit a login wall, they reject the app.

How to avoid it:

• Create a dedicated review account with realistic data. Put the username and password in App Review Information (App Store Connect) and in App access (Play Console).
• If login needs SMS codes, hardware, or a company invitation, explain the workaround in the review notes, or provide a demo mode.
• If you offer in-app purchases, make sure the reviewer can find and test them. Apple’s guideline 2.1(b) asks you to explain in the review notes if a configured purchase cannot be found in the app.

3. Missing account deletion

Both stores require account deletion if users can create an account in your app.

• Apple (guideline 5.1.1(v)): “If your app supports account creation, you must also offer account deletion within the app.”
• Google Play: apps that allow account creation must provide an in-app path to delete the account and associated data, and a web link where users can request deletion without reinstalling the app. You declare this in the Data safety form (Google Play Help).

“Email us to delete your account” or “deactivate” only is not enough. Build a real deletion flow, including the backend that actually deletes (or anonymises, where the law requires you to keep records) the data.

4. Privacy policy, privacy labels and Data safety

Privacy is the area where rules have grown the most, and where mistakes are easiest to make.

Apple

• Privacy policy (5.1.1(i)): every app needs a privacy policy link in App Store Connect and inside the app. It must say what data you collect, how, what you use it for, how third parties protect it, and how users can request deletion.
• App Privacy details (“nutrition labels”): you declare in App Store Connect what data the app and every third-party SDK collects. If your answers do not match what the app actually does, that is a problem.
• Privacy manifests: apps and many common third-party SDKs must include a PrivacyInfo.xcprivacy file that declares data use and the reasons for using certain APIs (Apple documentation). Update SDKs to versions that ship a manifest.
• Tracking: you must ask permission through App Tracking Transparency before tracking users across apps and websites (5.1.2).
• Third-party AI: guideline 5.1.2(i) now says you must clearly disclose where personal data will be shared with third parties, including third-party AI, and get explicit permission before doing so. If your app sends user content to an external LLM API, tell the user and ask first.

Google Play

• Data safety section: you declare data collection, sharing and security practices, including those of your SDKs. The declaration must be accurate and complete.
• Privacy policy: required in Play Console and must be linked in the app when the policy requires it.
• Prominent disclosure: if you collect personal or sensitive data in ways users would not expect, you must show an in-app disclosure and ask for consent before collection.

How to avoid it: make a list of every SDK in the app (analytics, crash reporting, ads, auth, payments, AI) and what each collects. Fill in both stores’ forms from that list, and update it whenever you add a dependency. If you process EU user data or use AI features, our GDPR and AI Act checklist can help.

5. Permissions you cannot justify

Asking for permissions that are not needed for a clear feature is a frequent rejection reason on both stores.

Apple

• Every permission needs a purpose string (for example NSCameraUsageDescription) that clearly and fully explains why the app needs it. “We need your camera” is not enough. “Scan receipts to add expenses automatically” is.
• Guideline 5.1.2 says apps must not require users to enable system functions such as push notifications, location or tracking to use the app.

<!-- Info.plist: specific, honest purpose strings -->
<key>NSCameraUsageDescription</key>
<string>Take a photo of a receipt to add it to your expense report.</string>
<key>NSLocationWhenInUseUsageDescription</key>
<string>Show nearby stores and their opening hours.</string>

Google Play

Google restricts several sensitive permissions and requires a declaration explaining why your app needs them. Examples:

• Photos and videos: apps targeting Android 13+ may only request READ_MEDIA_IMAGES and READ_MEDIA_VIDEO if the system photo picker is not sufficient for core functionality (policy). Most apps should just use the Android Photo Picker.
• Background location, SMS/Call Log, and “all files” access also have strict policies and declarations.

How to avoid it: remove permissions you don’t use (including ones added by libraries; check the merged Android manifest), ask for permissions only at the moment the user uses the feature, and use system pickers where possible.

6. Metadata that does not match the app

Apple’s guideline 2.3 (Accurate Metadata) is a common source of rejections:

• No hidden features (2.3.1): everything the app does should be visible to users and to App Review.
• Screenshots (2.3.3): should show the app in use, not only title art, the login page or the splash screen.
• Age-appropriate metadata (2.3.8): icons, screenshots and previews should suit a 4+ audience even if the app is rated higher.

Google Play has similar rules against misleading store listings, keyword stuffing and irrelevant screenshots.

How to avoid it: take screenshots from the release build, make sure every feature you mention in the description exists, and avoid competitor names or “best” and “#1” claims you cannot back up.

7. Minimum functionality and “just a website”

Apple guideline 4.2 says an app should offer features, content and UI that go beyond a repackaged website. A WebView wrapper around your site is a classic rejection. Guideline 4.3 (Spam) also rejects many near-identical apps, such as a separate app per city or per client.

How to avoid it: use native features that add value (offline access, push notifications, device integrations), and use configuration or in-app selection instead of cloning apps.

8. Payments and login rules

• In-app purchase (Apple 3.1.1): unlocking digital features or content inside the app generally must use Apple’s in-app purchase. Rules for links to external payment differ by region and have changed several times, so check the current guideline text for the storefronts you target.
• Google Play billing: digital goods generally use Google Play Billing, with regional alternatives. Physical goods and services use your own payment provider on both stores.
• Login services (Apple 4.8): if you use a third-party or social login (Google, Facebook and others) for the primary account, you must also offer an equivalent login option that limits data to name and email, lets users hide their email, and does not track for ads without consent. Sign in with Apple meets this requirement.

9. User-generated content without moderation

If users can post content or message each other, Apple guideline 1.2 requires a way to filter objectionable content, a way to report it with timely responses, the ability to block abusive users, and published contact information. Google Play has similar user-generated content rules. Build these before launch, not after the first rejection.

10. Outdated SDKs and target API levels

These are “technical” rejections that block uploads entirely:

• Apple: from April 28, 2026, apps uploaded to App Store Connect must be built with the iOS 26 SDK (Xcode 26) or later (Apple upcoming requirements).
• Google Play: from August 31, 2026, new apps and updates must target Android 16 (API level 36) or higher, with an extension possible until November 1, 2026 (Android Developers).

Keep your framework (React Native, Flutter) and build tools current, so these deadlines don’t turn into emergency projects.

Pre-submission checklist for common app store rejection reasons

• Release build tested on real devices, including an older OS version
• No placeholder content, broken links or dead buttons
• Production backend running; reviewer is not rate-limited
• Demo account and review notes provided (plus a demo mode for SMS or hardware login)
• In-app account deletion works; Google Play web deletion link is live
• Privacy policy linked in the store listing and in the app
• App Privacy details, privacy manifest and Data safety form match the real SDK list
• Users are told, and asked, before personal data is sent to third-party AI services
• Only needed permissions requested, with clear purpose strings, at the moment of use
• Photo picker used instead of broad media permissions where possible
• Screenshots and description match the current build
• In-app purchases visible and testable; payment method follows store rules
• Sign in with Apple (or equivalent) offered if you use social login
• Reporting, blocking and filtering in place for user-generated content
• Built with the current required SDK and target API level

If you do get rejected

1. Read the rejection message carefully. It usually cites the exact guideline number.
2. Fix the issue, and explain the fix clearly in the review notes or Resolution Center reply.
3. If you believe the reviewer misunderstood the app, reply politely with screenshots or a short screen recording.
4. On Apple, you can appeal to the App Review Board if you still disagree after that.

Let us handle publishing

Store review is predictable once you have done it many times. If you want someone to prepare your listings, privacy declarations and review notes, or to fix a rejected app, see our app store publishing service or contact us.