10 Common App Store Rejection Reasons and How to Fix Them

Why App Rejections Happen (And Why They're Not the End of the World)

App store rejections feel like a gut punch, especially when you've spent weeks or months building your app. But they're incredibly common — Apple reports that roughly 40% of app submissions are rejected on the first try. The good news: most rejections are for fixable issues, and re-submission after addressing the feedback is usually approved quickly. Both Apple and Google provide reasons for rejection, though Apple's feedback tends to be more specific. Understanding the most common rejection patterns before you submit lets you preemptively fix issues, dramatically improving your chances of first-try approval. Here are the ten most common rejection reasons across both platforms, ranked roughly by frequency.

1. Bugs and Crashes (App Completeness)

This is the single most common rejection reason on both platforms. Apple's Guideline 2.1 (App Completeness) and Google's equivalent policy reject apps that crash on launch, have broken features, or show placeholder content. Reviewers test on current-generation devices, so crashes that only happen on specific hardware often slip through — but launch crashes are caught immediately. The fix is straightforward but requires discipline: test your release build (not your debug build) on a physical device before submitting. React Native developers should verify the JavaScript bundle is included in the archive. Flutter developers should test the AOT-compiled release build. Swift and Kotlin developers should test with optimizations enabled. Pay special attention to network-dependent features — reviewers may test in various network conditions, and your app should handle offline scenarios gracefully rather than crashing.

2. Missing or Inadequate Privacy Policy

Both platforms now require a privacy policy for all apps, even those that don't collect user data. Apple requires a privacy policy URL in App Store Connect, and your app must also link to it somewhere accessible (usually in settings or at registration). Google Play requires it in both the store listing and within the app itself. Your privacy policy must accurately describe what data you collect, how you use it, and who you share it with. If you use analytics SDKs (Firebase, Mixpanel), ad networks (AdMob), crash reporters (Sentry, Crashlytics), or any third-party service that processes user data, you must disclose this. Free privacy policy generators exist (PrivacyPolicies.com, TermsFeed), but make sure the generated policy actually matches your app's data practices. A generic policy that doesn't mention specific third-party services you actually use can lead to rejection.

3. Incomplete Metadata or Misleading Screenshots

Apple's Guideline 2.3 (Accurate Metadata) catches many first-time developers. Screenshots must accurately depict the actual app — you can't use marketing renders or mockups that show features that don't exist. Descriptions must match what the app actually does, and keywords must be relevant. Google has similar requirements. Common metadata issues include: screenshots from a different version of the app, descriptions mentioning features planned for future updates, category selections that don't match the app's primary function, and app names that include generic terms like 'best' or 'free' (which violate Apple's naming guidelines). The fix: take fresh screenshots from the exact build you're submitting, review every word of your description for accuracy, and choose your category based on primary functionality, not aspirational positioning.

4. Insufficient App Functionality (Minimum Functionality)

Apple's Guideline 4.0 (Design) includes a minimum functionality requirement. Apps that are essentially websites wrapped in a WebView, apps with very limited functionality, or apps that duplicate built-in iOS features without significant additions are commonly rejected. Google has tightened similar standards. This rejection particularly affects apps built with hybrid frameworks (Ionic, Cordova, Capacitor) where the entire UI is a WebView. It also hits simple utility apps and promotional apps for businesses that don't offer meaningful in-app functionality. To fix: ensure your app provides genuine value that goes beyond what a mobile website offers. Use native UI components where possible, implement platform-specific gestures and navigation patterns, and ensure the app works offline or provides meaningful offline functionality. If your app is a companion to a web service, it should offer something unique — push notifications, offline access, device features — that justifies its existence as a native app.

5. In-App Purchase and Subscription Issues

If your app offers in-app purchases or subscriptions, both platforms have strict rules. Apple requires all digital content purchases to go through In-App Purchase — you cannot link to external payment methods for digital goods (with limited exceptions in specific regions). Subscriptions must clearly display pricing, duration, and renewal terms. Apple also requires a 'Restore Purchases' button for non-consumable purchases and subscriptions. Google has similar requirements for the Play Billing Library. Both platforms will reject apps that try to bypass their payment systems for digital goods, that don't clearly disclose subscription terms before purchase, or that make it difficult to cancel subscriptions. The fix: implement Apple's StoreKit 2 (or StoreKit) and Google's Play Billing Library correctly, show clear pricing before any purchase screen, include a restore purchases mechanism, and link to subscription management (iOS: Settings > Apple ID > Subscriptions; Android: Play Store > Subscriptions).

6. Design and User Interface Problems

Apple is particularly strict about design quality. Apps that don't follow basic Human Interface Guidelines — like using non-standard navigation patterns, having unreadable text, or not supporting the device's full screen — face rejection. Apple specifically checks for: proper support for the iPhone notch/Dynamic Island, landscape and portrait orientation handling (or explicit opt-out), accessibility basics like minimum touch target sizes, and Dark Mode support (not required but recommended). Google's design requirements are less strict but have been increasing. Material Design compliance isn't mandatory, but apps with severely broken layouts, unreadable text, or buttons that don't respond are rejected. Both platforms expect apps to work with larger text sizes (Dynamic Type on iOS, font scaling on Android). Fix: test on multiple device sizes, verify your app looks good in both orientations if you support them, ensure touch targets are at least 44x44 points (iOS) or 48x48 dp (Android), and check that text is readable at all supported sizes.

7. Data Safety and Privacy Declaration Mismatches

Both platforms now require detailed data privacy declarations, and mismatches between what you declare and what your app actually does cause rejections. Apple's App Privacy nutrition labels require you to declare every type of data your app collects (contact info, location, identifiers, usage data, etc.) and how it's used (analytics, advertising, product personalization). Google's Data Safety section has similar requirements. The common mistake: forgetting about third-party SDKs. If you include Firebase Analytics, it collects device identifiers and usage data. If you include crash reporting, it collects device information and crash logs. Ad SDKs collect extensive data. Even apparently innocuous libraries may collect data. Audit your dependency tree, check each SDK's privacy documentation, and declare everything accurately. Under-declaring leads to rejection; over-declaring is safe but may concern privacy-sensitive users.

8. Login and Authentication Issues

If your app requires login, Apple requires you to offer Sign in with Apple as an option whenever you offer any third-party social login (Google, Facebook, etc.). This catches many developers who only implement Google Sign-In or Facebook Login. Additionally, Apple requires that apps offer some meaningful functionality without requiring login, unless the app's core purpose inherently requires an account (like banking or email). Google requires similar transparency about account requirements but doesn't mandate a specific sign-in method. Both platforms require that you provide demo/test account credentials in the reviewer notes if your app requires login to access functionality. Forgetting this means the reviewer can't test your app, resulting in immediate rejection. Fix: implement Sign in with Apple if you have any social login on iOS, provide clear demo credentials, and consider allowing limited browsing without authentication.

9. Intellectual Property and Content Violations

Using another company's trademarks, logos, or copyrighted material in your app or store listing triggers rejection. This includes using Apple or Google's product names or logos in ways that suggest endorsement, including copyrighted images or music without licenses, or creating apps that closely mimic existing popular apps. Less obvious violations include: using generic app names that are too similar to existing apps, including screenshots that show copyrighted content on screen, or using character designs that are similar to trademarked characters. Both platforms also prohibit user-generated content that infringes on copyrights unless you have a robust DMCA takedown process in place. Fix: audit all visual assets, names, and content for potential IP issues. Use original or properly licensed assets. If your app name is common, make it distinctive enough to avoid confusion with existing apps.

10. Target API Level and Technical Compliance

Google enforces minimum target API level requirements that change annually. As of 2025, new apps must target at least API level 34 (Android 14), and updates to existing apps must also meet this threshold. Apps targeting outdated API levels are automatically rejected. Apple similarly requires apps to be built with the latest stable Xcode and to support current device capabilities. Apple periodically drops support for apps that haven't been updated in three or more years. These requirements exist for security and user experience reasons — newer API levels include important privacy protections, performance improvements, and security patches. Fix: keep your development tools and SDKs up to date. For Android, update targetSdkVersion and compileSdkVersion in your build.gradle file. For iOS, build with the latest stable Xcode version. If you're using a cross-platform framework, update to a recent version that targets current API levels by default.

Key Takeaways

• About 40% of apps are rejected on first submission — it's normal, not catastrophic
• Always test your release/production build on a physical device before submitting
• Every app needs a privacy policy, accurate data privacy declarations, and proper metadata
• Apple requires Sign in with Apple whenever you offer any third-party social login
• Keep development tools and target API levels current — outdated versions are automatically rejected

Related Framework Guides