You've spent weeks building a feature, polished the UI, written the release notes — and then Apple rejects your build. Or Google flags it for a policy violation you've never heard of. It's one of the most demoralizing moments in mobile development, and it happens far more often than most developers expect.
Apple reviewed roughly 7.77 million app submissions in 2024 and rejected about 25% of them outright. More recent industry data suggests that nearly 40% of iOS submissions face delays or rejection due to preventable errors — not obscure edge cases, but things like missing privacy disclosures, broken links, and incomplete metadata. On Google Play, policy enforcement has tightened significantly in 2026 with new developer verification requirements and updated content policies.
The good news: most rejections are avoidable. This guide walks through the most common reasons apps get rejected on both platforms in 2026 and gives you concrete steps to fix each one before you submit.
Privacy and Data Transparency#
Privacy is the single biggest category of App Store rejections in 2026, and Google Play is catching up fast.
On iOS, Apple now requires a complete privacy manifest for every app and every third-party SDK your app includes. The privacy manifest must declare all data types your app collects, the purposes for that collection, and whether any data is linked to the user's identity. If your app uses any of Apple's "required reason" APIs — and most apps do, since this includes things like UserDefaults and disk space checks — you need to declare a valid reason for each one.
The enforcement isn't theoretical. As of early 2026, roughly 12% of App Store rejections cite privacy manifest issues specifically. Apps that integrate third-party SDKs for analytics, advertising, or crash reporting are especially vulnerable, because the privacy manifest must cover those SDKs too, and many developers don't realize they're responsible for their dependencies' declarations.
On Google Play, the Data Safety section serves a similar function. Google requires developers to accurately disclose data collection and sharing practices, and inconsistencies between your declared behavior and your app's actual network activity can trigger review flags or removal.
What to do:
Review your privacy manifest against Apple's latest required reasons list before every submission. Audit every third-party SDK in your project — check whether the SDK vendor provides an up-to-date privacy manifest, and if they don't, file an issue or consider switching to one that does. On Google Play, keep your Data Safety section updated whenever you add a new SDK or change how you handle user data.
SDK and Build Requirements#
Both Apple and Google regularly update their minimum SDK requirements, and submissions built with outdated tools get rejected automatically — no human reviewer involved.
The biggest deadline right now is Apple's April 28, 2026 cutoff: after that date, all apps uploaded to App Store Connect must be built with Xcode 26 and the iOS 26 SDK (or later). The same applies to iPadOS 26, tvOS 26, visionOS 26, and watchOS 26 SDKs. Apps built with older versions of Xcode will be rejected on upload, before they even reach review.
This isn't just a recompile. Apps built with the iOS 26 SDK automatically adopt the new Liquid Glass visual style for standard UIKit and SwiftUI components. If you haven't tested your app's UI against Liquid Glass, you may discover layout issues, contrast problems, or visual regressions that could lead to rejection under Apple's design guidelines — or worse, a poor user experience that triggers negative reviews.
On Google Play, Android apps targeting API level 36 (Android 16) must now support adaptive screen orientations on large screens. The ability to lock screen orientation on tablets and foldables is being removed, and apps that don't handle this gracefully will face policy flags.
What to do:
Update your CI/CD pipeline to use Xcode 26 now — don't wait until April 27. Run a full visual regression test with the iOS 26 SDK to catch Liquid Glass issues early. On Android, test your app on large-screen emulators and foldable devices to ensure orientation changes don't break your layout.
Crashes, Bugs, and Incomplete Features#
It sounds obvious, but crashes and broken functionality remain one of the top three rejection reasons on both platforms. Apple's review team tests apps on current-generation devices, and if the app crashes during their testing session, it's an automatic rejection.
The subtler version of this problem is incomplete features. If your app has a tab that leads to a "coming soon" screen, a login flow that doesn't work, or a feature that's hidden behind a server-side flag that isn't enabled for the reviewer — that's a rejection. Apple's guidelines explicitly state that apps must be "complete" and not feel like a beta or a demo.
Google Play is slightly more lenient here, but repeated crashes reported by early users can trigger automated quality reviews that result in your app being flagged or deprioritized in search results.
What to do:
Run your app through a real device test matrix before every submission, not just the simulator. If you use feature flags, make sure all visible features are enabled for the App Store review build. Include detailed reviewer notes in App Store Connect explaining how to access any feature that requires a login — provide a demo account with credentials.
Metadata and Screenshot Mismatches#
Your app's store listing is reviewed alongside the binary, and inconsistencies between what your screenshots show and what the app actually does will trigger a rejection. This includes screenshots that depict features not present in the submitted version, pricing claims that don't match your actual IAP configuration, and descriptions that overstate capabilities.
On Google Play, Google has also cracked down on misleading store listings in 2026, particularly around AI features. If your app description claims "AI-powered" functionality, the review team may check that the feature actually works and isn't just a wrapper around a generic API with no meaningful user value.
What to do:
Update your screenshots every time you ship a major UI change. Make sure your description accurately reflects the current feature set — not your roadmap. If you've removed a feature, remove it from the screenshots and description before submitting.
This is one area where automation pays for itself quickly. Regenerating screenshots across multiple device sizes and localizations for every release is tedious and error-prone when done manually. Platforms like Stora can generate localized, device-framed screenshots from your app and keep your store listing in sync with your actual product — which eliminates one of the most common metadata rejection triggers.
Guideline 4.3: Spam and Minimum Functionality#
Apple's Guideline 4.3 is the catch-all that trips up more indie developers than almost any other rule. It covers "spam" — apps that are too similar to existing apps, including your own — and "minimum functionality" — apps that don't do enough to justify their existence on the App Store.
If you're submitting a simple utility app (a flashlight, a timer, a unit converter), Apple may reject it under 4.3 unless it offers meaningfully more than what's already available. Apps that are essentially web wrappers with no native functionality are also common 4.3 rejections.
What to do:
Before submitting a utility app, search the App Store for similar apps and honestly assess whether yours offers something materially different. If your app is a web wrapper, add native features — push notifications, widgets, Siri Shortcuts, offline support — that justify a native app's existence. In your reviewer notes, explain what makes your app unique.
The Compound Effect: How Small Errors Stack Up#
Most rejections aren't caused by a single catastrophic mistake. They're caused by the accumulation of small oversights: an outdated privacy manifest entry, a screenshot from two versions ago, a crash that only happens on iPad mini, a description that still mentions a feature you sunset last quarter.
The developers with the lowest rejection rates aren't the ones who know every guideline by heart. They're the ones who have a systematic pre-submission checklist and the tooling to enforce it. Whether that's a CI pipeline that runs compliance checks, a staging environment that mirrors the review process, or a submission platform like Stora that handles metadata validation, screenshot generation, and compliance checks before you hit submit — the goal is the same: catch the preventable stuff before Apple or Google does.
A Quick Pre-Submission Checklist#
Before every submission to either store, verify the following:
Your privacy manifest (iOS) and Data Safety section (Google Play) accurately reflect all data collection, including third-party SDKs. Your app is built with the latest required SDK version — iOS 26 SDK for Apple, current target API level for Google Play. All visible features work end-to-end, with no "coming soon" placeholders or broken flows. Your screenshots match the current UI and feature set across all required device sizes. Your app description doesn't claim capabilities the app doesn't have. You've included reviewer notes with demo credentials and instructions for any gated features. You've tested on physical devices, not just simulators, across multiple screen sizes.
None of these steps are difficult individually. The challenge is doing all of them consistently, on every release, under deadline pressure. That's where process and tooling make the difference — and where the gap between a 10% rejection rate and a 40% rejection rate lives.