App Store rejection reasons in 2026 and how to avoid them
· 8 min read
Most App Store and Google Play rejections are not mysterious. The same handful of reasons come back release after release, and a good share of them are technical problems you can see in the build file before anyone at Apple or Google opens it. This guide goes through the rejection reasons teams run into most in 2026, what the message usually looks like, and how to catch each one earlier.
Two kinds of problems show up here. Some are upload blockers: App Store Connect or Play Console refuses the build, or sends an email with an ITMS code, before review even starts. Others are review rejections: a person reviewed the app against the guidelines and said no. The first kind is easy to check by machine. The second kind needs a human eye, but knowing the patterns helps.
Apple: the guidelines behind most rejections
Guideline 2.1: App Completeness
This is the classic. The reviewer hit a crash, a placeholder screen, a broken link, or could not get past the login screen. A very common variant is "Information Needed": the app needs an account and no working demo login was given in the review notes.
How to avoid it:
- Put a working demo account in App Review Information, and make sure it is not tied to a server that expires or a one time code sent to someone's phone.
- If features depend on hardware, a region or a backend switch, say so in the review notes and explain how to reach them.
- Install the exact build you plan to submit on a clean device, not the debug build from Xcode, and go through the main flows once.
Guideline 2.3: Accurate Metadata
Screenshots that show features the app does not have, a description that promises things the build cannot do, keywords stuffed with competitor names, or a "What's New" text that does not match the update. Reviewers compare the listing with the app. Keep screenshots current and write the description from what the build actually does.
Guideline 3.1.1: In-App Purchase
If the app sells digital content or features, Apple expects In-App Purchase for that, with rules that differ by region and by app type. Rejections usually come from a button that sends users to a web checkout for digital goods, or a paywall with no restore purchases option. Read the current text of 3.1 for your storefronts before you design the paywall, because this section changes more often than most.
Guideline 4.3: Spam
Apps that look like many other apps already on the store, or several near identical apps from one account, often get a 4.3 rejection. Template apps and white label apps are the usual victims. If you ship one codebase for many clients, each listing needs to stand on its own, and in many cases the client should publish under its own developer account.
Guideline 5.1.1: Data Collection and Storage
Privacy rejections are among the most frequent. Typical triggers:
- A permission prompt with a vague purpose string, such as "This app needs your camera". Apple wants the reason in plain words: what you use it for.
- Asking for personal data that the core feature does not need.
- Account creation without account deletion inside the app. Guideline 5.1.1(v) asks for both.
- Privacy labels in App Store Connect that do not match what the app and its SDKs collect.
Apple: upload blockers you can check in the file
These do not need a reviewer. They come from App Store Connect itself, usually by email shortly after upload.
| Message | What it means | Fix |
|---|---|---|
| ITMS-91053: Missing API declaration | Your code or an SDK uses a required reason API (for example file timestamps, system boot time, disk space or UserDefaults) and the privacy manifest does not list a reason for it. | Add the category and an approved reason to NSPrivacyAccessedAPITypes in PrivacyInfo.xcprivacy. If the call is inside an SDK, update the SDK. |
| ITMS-91061: Missing privacy manifest | The app includes a commonly used third party SDK from Apple's list, and that SDK has no privacy manifest. | Update the SDK to a version that ships PrivacyInfo.xcprivacy. Old pinned versions are the usual cause. |
| SDK version too old | Since April 28, 2026, uploads must be built with Xcode 26 or later using the iOS 26 SDK (or the matching iPadOS, tvOS, visionOS or watchOS 26 SDK). | Update Xcode on your build machine or CI image. |
| Wrong signing for the store | An Ad Hoc or Development build was uploaded, or the profile has expired. | Export with the App Store distribution method. |
Cross platform projects hit ITMS-91061 more than native ones, because a Flutter, React Native or Capacitor plugin can pull in an old version of a listed SDK without anyone noticing. Check the embedded frameworks in the built .ipa, not just your top level dependencies.
Google Play: the common blockers and rejections
Target API level
Since August 31, 2026, new apps and app updates must target Android 16 (API level 36) or higher. Wear OS and Android Automotive OS apps need API 35, Android TV and Android XR apps need API 34. Google offered an extension to November 1, 2026 for teams that requested it in Play Console. Existing apps that target below API 35 stop being offered to new users on newer Android versions. This one blocks at upload, so even a one line hotfix waits until targetSdk is raised.
16 KB page size
New apps and updates targeting Android 15 or higher must support 16 KB memory pages on 64-bit devices. If your app ships native libraries (.so files), they must be built and aligned for 16 KB. Apps without native code are not affected. React Native, Flutter, game engines and SDKs with native parts are where this comes from, so updating those dependencies is usually the fix.
Policy declarations in Play Console
Many Play rejections are about forms rather than code. The ones teams most often get wrong:
- Data safety: the form must match what the app and every SDK in it collect and share. A new analytics or ads SDK means the form needs an update.
- Sensitive permissions: permissions such as background location, all files access, SMS and call log, photo and video access, and some foreground service types need a declaration explaining the core feature that uses them. If the feature is not central to the app, remove the permission.
- Account deletion: apps that let users create an account need a way to request deletion, both in the app and through a link given in Play Console.
- App access: like Apple, Google needs working login details if parts of the app are behind sign in.
Debuggable or debug signed builds
Play does not accept a build with android:debuggable="true" or one signed with the Android debug key. It happens when the wrong build variant is uploaded, often from a hurried manual release.
New personal accounts
Personal developer accounts created after November 13, 2023 must run a closed test with at least 12 opted in testers for 14 days in a row before they can apply for production access. This is not a rejection, but it surprises first time publishers who expected to go live on day one. Plan for it.
Catch the technical ones before you submit
Review rejections need people: someone who reads the guidelines, tries the demo account and checks the screenshots. The upload blockers above are different. They are all readable from the build file, so there is no reason to find out from an email after the upload.
A short pre-submission routine:
- Build the release variant the same way you will submit it, ideally in CI.
- Check the SDK and Xcode version, privacy manifest and embedded frameworks of the
.ipa. - Check target API, debuggable flag, signing key and native library ABIs of the
.apk. - Read every usage description string out loud. If it sounds vague, rewrite it.
- Install the build on a real device and go through the review path with the demo account.
Step 5 is where test build distribution helps: send the same signed build to the people who will use the demo account, so the path the reviewer follows has been tried by someone other than its author. Our posts on test build distribution best practices and iOS code signing errors on test builds cover that part.
How the AppForShare store readiness check helps
Every build uploaded to an AppForShare account, on any plan including Free, gets a store readiness check against current App Store and Google Play rules. It looks at the iOS SDK version, privacy manifests and required reason APIs (the ITMS-91053 and ITMS-91061 cases), the Play target API level, 16 KB page size for 64-bit native libraries, debuggable and debug signing, 64-bit support and provisioning profile expiry. Each build gets a status of ready, review, blocked or unknown, and each issue comes with a short "how to fix".
When you upload a new build of the same app, the "what changed" view shows which store issues were fixed and which are new, next to changes in permissions, minimum OS, target API and SDK. That makes it easy to spot the release where a dependency update added a permission or an SDK without a manifest.
If you only want to check a file without an account, the free IPA inspector and APK analyzer run the same rules in your browser. The file is read locally and is not uploaded.
To be clear about the limits: the check reads the build. It cannot judge your screenshots, your paywall design, whether your app looks too similar to another one, or whether a reviewer will find the demo account working. It is guidance that catches technical problems early, not a promise of approval.
Try it on your next build
Drop your current release candidate into the IPA inspector or APK analyzer and see what comes up. If you want every build checked automatically and shared with testers in the same step, create a free account. For more on what review looks at once you are past the technical checks, see the risks of manual App Store publishing and security checks before you share a build.
