10 Most Common App Store Rejection Reasons in 2026
Apple rejects thousands of apps every week. Here are the top 10 reasons: and exactly how to fix each one before you hit Submit.
In 2025, Apple rejected approximately 1.7 million app submissions. The majority of those rejections were for the same repeating reasons: reasons that are entirely avoidable with the right checklist. This article covers the 10 most frequent rejection triggers and gives you specific, actionable fixes for each.
App crashes on launch
Guideline 2.1
This is the single most common rejection reason across both iOS and Android. Apple reviewers test on real devices: often older models: and if your app crashes in the first 60 seconds, it is rejected immediately.
How to fix it
- Test on physical devices, not only the simulator. Especially iPhone SE, iPhone 12, and iPad.
- Test with a slow or no internet connection: many apps crash on first launch without network access.
- Use Xcode Instruments to check for memory issues, retain cycles, and threading violations.
- Implement proper error handling for all network calls and database operations.
- Use TestFlight for final pre-submission testing with real users on real devices.
Missing or invalid privacy policy URL
Guideline 5.1.1
If your app collects any user data, uses analytics SDKs, or has any account functionality, you must provide a publicly accessible privacy policy URL in App Store Connect. The URL must work: Apple checks it.
How to fix it
- Create a privacy policy and host it at a public URL (e.g. yourapp.com/privacy).
- Add the privacy policy URL in App Store Connect under App Information.
- Link to the privacy policy from within the app itself, typically in the Settings screen.
- Ensure the policy accurately describes what data you collect and how you use it.
- If you use any third-party SDKs (Firebase, Amplitude, Adjust), mention their data collection in your policy.
Requesting excessive or unjustified permissions
Guideline 5.1.2
Apple requires that every permission you request must be directly necessary for a core feature of your app. Requesting camera access in a calculator app? Rejected. Requesting contacts access 'just in case'? Rejected.
How to fix it
- Audit every permission in your Info.plist and remove any that are not actively used.
- Request permissions lazily: only when the user is about to use the feature that requires them.
- Write clear, specific NSUsageDescription strings explaining exactly why you need each permission.
- Never request permissions at launch before the user has any context.
- Test your app with all permissions denied to ensure graceful degradation.
Incomplete or placeholder content
Guideline 4.0
Apps submitted with 'Lorem ipsum' text, empty screens, broken features, or test data in the production build are rejected for being incomplete. This includes apps where key features require a backend that is not live yet.
How to fix it
- Ensure all UI text is final and makes sense to a first-time user.
- Make sure all features are functional and the backend is live before submission.
- Remove all debug logs, test accounts, and hardcoded test data.
- If a feature requires account creation, provide a demo account in your App Review Notes.
- Test the full user journey from install to first meaningful action.
Missing privacy manifest (PrivacyInfo.xcprivacy)
Guideline 5.1: Required from May 2024
Since May 2024, Apple requires all apps: and all third-party SDKs: to include a PrivacyInfo.xcprivacy file declaring every API that accesses user data. Apps without this manifest are rejected during automated review before a human ever sees them.
How to fix it
- Add a PrivacyInfo.xcprivacy file to your app target in Xcode.
- Declare every 'required reason API' your app uses (UserDefaults, NSFileManager, System Boot Time, etc.).
- Check all your third-party dependencies: if they use required reason APIs without a manifest, you need to update them.
- Use Xcode's Privacy Report (Product > Archive > Validate App) to identify undeclared APIs.
- If you use popular SDKs (Firebase, Crashlytics), ensure you are on the version that includes their privacy manifest.
Misleading app description or screenshots
Guideline 2.3
App Store screenshots must accurately represent your app. If your screenshots show features that do not exist in the version being submitted, or if your description promises functionality that is not present, Apple will reject the submission.
How to fix it
- Take screenshots directly from your app: do not use marketing mockups that don't match the real UI.
- If your description mentions a feature, make sure that feature is implemented and accessible.
- Do not claim your app is 'free' if there are required purchases to use core functionality.
- Do not reference competing platforms (Android, Google Play) in your metadata.
In-app purchases or subscriptions not implemented correctly
Guideline 3.1
Any app that monetises digital content must use Apple's in-app purchase system. Linking to an external website for payment, using third-party payment processors for digital goods, or trying to avoid the 30% cut will result in immediate rejection.
How to fix it
- Use StoreKit 2 for all digital purchases and subscriptions.
- Physical goods and services (e.g. ordering a pizza, booking a ride) are exempt: they can use other payment methods.
- Do not include links to your website where users can purchase a cheaper subscription.
- Provide a clear Restore Purchases button for any non-consumable or subscription purchases.
- Test in-app purchases thoroughly using StoreKit testing in Xcode before submission.
App does not work in demo/review mode
Guideline 2.1
Apple reviewers cannot create real accounts on your backend. If your app requires account creation or sign-in to access any meaningful functionality, and you do not provide demo credentials, the reviewer cannot test your app and will reject it.
How to fix it
- Always provide demo login credentials in the App Review Information section of App Store Connect.
- Ensure the demo account has all features fully enabled.
- If your app has a sign-in with Apple requirement, also offer email/password as a fallback for reviewers.
- Include review notes explaining any non-obvious features or workflows.
Poor user interface or UX that does not meet Apple standards
Guideline 4.0
Apple reviews for quality. Apps with broken layouts on any supported device, non-standard UI patterns that confuse users, tiny tap targets, or general low quality can be rejected for not meeting minimum quality standards.
How to fix it
- Test on every device size your app claims to support, including iPad if you use Universal.
- Follow Apple's Human Interface Guidelines for navigation, typography, and touch targets.
- Support Dynamic Type: your UI should not break at large accessibility text sizes.
- Support both light and dark mode unless you have a strong reason not to.
- Ensure proper Safe Area insets on iPhone 14 and newer notch/Dynamic Island devices.
App is a thin wrapper or lacks unique value
Guideline 4.2
Apps that are simply a web view wrapping a website, apps that duplicate existing App Store apps with no differentiation, or apps with extremely limited functionality are rejected for not providing sufficient value.
How to fix it
- If your app uses a web view, ensure it adds native value: push notifications, offline access, biometric auth, or native integrations.
- Articulate the unique value of your app clearly in your review notes.
- Apps that are essentially just a single static information page should be a website, not an app.
- Ensure your app has at least three to five substantive features or screens.
Still worried about rejection?
Run our free App Health Check to get an instant rejection risk score before you submit. Or submit your app for a full human review by testers who know exactly what Apple looks for.