App Rejection FAQ

We read your rejection, removal or suspension notice, identify the most likely root cause, and tell you honestly whether the problem is a policy interpretation issue, a metadata issue, or a technical defect in the app, its backend, its SDKs or its store configuration.

Because we are a development company, we can then implement legitimate fixes — code, configuration, privacy declarations, reviewer access, StoreKit or Play Billing — and prepare the app for resubmission or a well-founded appeal.

Related: Submit Rejection, About

No. Nobody outside Google or Apple can guarantee a review outcome, and any service that does is misleading you. What we can do is find the real problem, fix what is legitimately fixable, remove avoidable reasons for a repeat rejection and present your case accurately. That materially improves your position, but the decision always belongs to the platform.

Related: Disclaimer

No. App Rejection Fix is an independent service operated by Keshav Infotech. We are not affiliated with, endorsed by, sponsored by, certified by, or an official support service of Google LLC or Apple Inc. We have no special access to reviewers and we never claim to.

Related: Disclaimer

The exact rejection text, copied word for word, plus screenshots of the notice if you have them. Tell us the platform, the app name, the technology stack and whether this is a first rejection or a repeat. Do not send passwords, signing keys, API secrets, recovery codes or payment credentials — we never need them for an initial review and we will ask you to remove them if they are included.

Related: Submit Rejection

The initial review of your rejection message is free — it is how we scope the work. After that, any technical work is quoted per case because a metadata correction, a Data safety realignment and a payment-flow rebuild are very different amounts of work. You will always know the scope and cost before any development starts.

Related: Submit Rejection, Terms of Service

The Decoder is a deterministic tool that matches your rejection text against a curated set of patterns and our rejection taxonomy. It is fast and useful for orientation, but it only sees the words in the notice. A human review looks at the app, the listing, the declarations and your history, which is where the actual root cause usually lives. If the Decoder reports low confidence, it will tell you to request a human review.

Related: Rejection Decoder, Submit Rejection

Rejected means a specific submission (new app or update) was not accepted; the previously published version usually stays live. Removed means a published app was taken down for a policy issue but can normally be corrected and resubmitted. Suspended is more serious: the app is taken down and the suspension may count as a strike against your developer account. The right response is different for each, so always check which one the notice actually says.

Related: Google Play Rejection Help, App Suspended

Open Play Console and check the Policy status page for the app, then the email sent to the developer account owner. The Policy status entry usually names the policy and often quotes the specific issue and the affected area (store listing, permissions, Data safety, app content). Copy that text exactly — paraphrasing it loses the details that identify the root cause.

Related: Google Play Rejection Help

Most Data safety rejections come from a mismatch between the declaration and what the app or its SDKs actually do. Analytics, crash reporting, advertising and authentication SDKs frequently collect identifiers, diagnostics or location that developers forget to declare. The fix is to audit the real data flows first, then either correct the declaration or change the app so that the two agree. Over-declaring blindly is not a safe shortcut.

Related: Data Safety Rejection

No. Creating a new account to continue publishing after a termination is treated as evasion and typically leads to the new account being terminated too, along with any accounts Google links to it. Read the termination notice carefully, understand which policy or agreement clause was cited, gather evidence, and use the official appeal path within the stated window. Technical fixes alone rarely reverse an account-level decision.

Related: Developer Account Terminated

The number maps to a section of the App Store Review Guidelines. 2.1 is App Completeness (crashes, bugs, incomplete features, reviewer access), 2.3 is Accurate Metadata, 3.1 is Payments and In-App Purchase, 4.2 is Minimum Functionality, 4.3 is Spam and similar apps, and 5.1 is Privacy. The number tells you the category; the reviewer's message and any attached screenshot tell you the specific trigger. Both matter.

Related: App Store Rejection Reasons, App Store Rejection Help

Not always. Metadata Rejected issues (screenshots, description, keywords, review notes) can often be corrected in App Store Connect and resubmitted with the same binary. Rejections that involve app behaviour, crashes, missing features, privacy flows or payments need a new build. If the reviewer asked a question rather than rejecting, reply in App Store Connect first.

Related: Metadata Rejection (2.3), Guideline 2.1 — App Completeness

WebView itself is not banned. What Guideline 4.2 targets is an app that offers little beyond what a website already provides. Apps built on WebView that add genuine native value — offline behaviour, device integration, notifications that matter, a workflow that is better as an app — can pass. Repackaged websites, marketing brochures and link collections usually cannot, regardless of how they are built.

Related: Guideline 4.2 — Minimum Functionality

Almost always one of five layers rather than your purchase code: the Paid Applications agreement or banking and tax details are not complete; the product is not in a state that makes it available for testing or sale; the product identifier in the app does not match App Store Connect exactly; StoreKit is querying before the product has propagated or in the wrong environment; or the build is running in a sandbox or TestFlight context that behaves differently from production. Work down the layers in that order — it is faster than reading the purchase code again.

Related: In-App Purchases Not Working, IAP / Payment Rejection (3.1)

The environment did, so work out how each build is actually buying before you change any code. An Xcode build may be running against a local StoreKit configuration file, which never contacts App Store Connect at all, or against Apple's sandbox. Apps installed from TestFlight operate in the sandbox environment, with accelerated subscription renewals. An App Store release uses production. Compare four things across the builds that work and the one that does not: the product identifiers and their configuration in App Store Connect, the bundle ID and team the build is signed with, the account signed in on the test device, and which environment your server accepts transactions from. A purchase that succeeds locally proves nothing about TestFlight or production.

Related: In-App Purchases Not Working

They overlap more often than developers expect. A Guideline 3.1 rejection is a reviewer's judgement about how you are charging — external payment, missing restore, unclear subscription terms, the wrong purchase type. A purchase that will not load is usually a configuration or environment problem, but it is not invisible to App Review: Guideline 2.1 requires in-app purchases to be complete, up to date, visible to the reviewer and functional, and says that if a configured product cannot be found or reviewed you must explain why in the review notes. So the same broken product can surface as a 2.1 rejection, a 3.1 rejection or no rejection at all, depending on what the reviewer hit. Start from the exact wording of the notice and the purchase step that fails, not from the guideline number alone — the number tells you which rule Apple applied, not what is technically broken.

Related: IAP / Payment Rejection (3.1), In-App Purchases Not Working, Guideline 2.1 — App Completeness

Usually not. An appeal is for cases where you believe the decision was wrong, not for cases where the reviewer was right and the app needs to change. Filing a weak appeal spends goodwill and time. Diagnose first: if the issue is real, fix it and resubmit; if the reviewer misunderstood the app, reply with clarification; reserve a formal appeal for a genuinely incorrect decision backed by evidence.

Related: App Store Appeal, Google Play Rejection Help

Specificity and evidence. Name the guideline or policy, explain exactly what the app does, show where the reviewer's reading diverges from the facts, and attach proof — screenshots, screen recordings, documentation, licensing or eligibility evidence. Keep it short and factual. Never fabricate evidence, testimonials or testing data; that converts a recoverable case into an account-level problem.

Related: App Store Appeal

Both. Keshav Infotech has in-house Android, iOS, Flutter, React Native, Unity, web and backend engineers plus QA. Typical rejection-driven work includes fixing crashes, implementing account deletion, aligning Data safety or App Privacy declarations with real data flows, adding privacy manifests, correcting permission usage, rebuilding purchase flows on StoreKit or Play Billing, and making reviewer access work.

Related: About, Submit Rejection

For the initial review, no. For implementation work we agree exactly what access is needed — usually repository access and a test build — under a written engagement. We never ask for passwords by email or through the website form, and you should never share signing keys or production secrets with anyone as part of a rejection review.

Related: Privacy Policy, Terms of Service

Yes. Stores now block releases for technical reasons: the target API level (Android 16 / API 36 since 31 August 2026), a deprecated Play Billing Library version, 16 KB page size compatibility, a build not made with Xcode 26 and the iOS 26 SDK, a signing-key mismatch, or an app that still needs registering under Android developer verification. There is nothing to appeal in those cases; the build or the account setup has to change, and that is engineering work we do. The free initial review works the same way as for a rejection — send the console message and tell us what the app is built with.

Related: Legacy App Update & Modernization, App Publishing Deadlines, Android Developer Verification

Yes — with the technical side. Google Play and Apple each have their own transfer criteria and their own list of things that break: Firebase and Google Cloud ownership, signing-key fingerprints, AdMob links, subscriptions and payment profiles on Play; Sign in with Apple identifiers, APNs keys, subscription shared secrets, Apple Pay merchant IDs and keychain on the App Store. We review the app before the transfer, plan the migrations, and carry them out if you want us to. Account ownership and identity verification always stay with you.

Related: Google Play App Transfer, App Store App Transfer

Yes, and it is the cheapest review to act on. Send what the app does, how a reviewer signs in, what it collects, what it sells and which sensitive permissions it needs. We tell you which declarations will be questioned, which technical requirements the build does not yet meet, and what we would change first — before a rejection is on the record. It is the same free initial review; there is no separate pre-submission product or price.

Related: Google Play Submission Checklist, App Store Submission Checklist

It reads it in that one request and then discards it. The text is never written to the database, the session or the log, nothing is executed or downloaded, no dependency is resolved, and analytics receives only a category such as “blockers found” — never the text itself. Input containing a private key or certificate is refused rather than analysed. The checker reports what a build file can prove (versions, declared permissions, deprecated configuration) and is explicit about what it cannot: 16 KB alignment, signing identity and runtime behaviour live in the built bundle, not in the configuration.

Related: Android Update Readiness Checker, Privacy Policy

It means the targetSdkVersion declared in your build must be 36 or higher before Play Console will accept a new release. It is a build setting, not a judgement about your app, and it is checked at upload — before any human review. Since 31 August 2026 it applies to new apps and to every update; Google offers an extension, requested per app from the Policy status page, that defers the block to 1 November 2026 without removing the requirement.

Related: Target API Level 36 Fix, App Publishing Deadlines

No. There is no reviewer decision to contest — the upload is refused by a mechanical check. The only two exits are a build that targets API 36 or higher, or the extension Google offers until 1 November 2026. Anyone offering to appeal it, or to get it waived, is describing something that does not exist.

Related: Target API Level 36 Fix

The line itself is one line. What follows usually is not. Targeting Android 16 enforces edge-to-edge layouts without the previous opt-out, changes large-screen orientation and resizability handling, tightens background execution and notification behaviour, and frequently forces a Gradle, AGP and dependency upgrade because older analytics, ads, payment and map libraries do not compile against the new toolchain. Plan it as a small project with device testing, not as a version bump.

Related: Target API Level 36 Fix, Legacy App Update & Modernization

If your app targets Android 15 (API level 35) or higher and ships any native code, it is in scope — and because target API 36 is now mandatory for updates, that is most apps that still release. Pure Java/Kotlin apps generally pass already. Native code arrives more often through SDKs and frameworks than through your own source: Flutter and React Native engines, Unity, and ads, analytics, database, media or security SDKs all bundle .so files.

Related: 16 KB Page Size Fix

Not conclusively. Alignment is a property of the compiled .so files, so it can only be proved from an APK or bundle — with zipalign -c -P 16, bundletool, APK Analyzer or an ELF segment check. What a build file can tell you is whether the toolchain is even capable of producing aligned libraries and which dependencies are likely to carry native code. Our update readiness checker reports exactly that and says plainly that the alignment check itself still has to happen on the artefact.

Related: 16 KB Page Size Fix, Android Update Readiness Checker

Today an affected app either runs in a compatibility mode on 16 KB devices — with a warning on first launch — or fails outright, and Play Console flags the bundle. From 1 February 2027, updates that do not support 16 KB page sizes cannot be released at all. The requirement has applied to new apps and updates targeting Android 15 or higher since 1 November 2025.

Related: 16 KB Page Size Fix, App Publishing Deadlines

Check the resolved version, not the one written in your build file — a plugin or SDK can pin an older one. On native Android, ./gradlew app:dependencies shows what is really linked. Otherwise the version is decided by whatever wraps it: the Unity IAP package, in_app_purchase_android on Flutter, react-native-iap on React Native, or a subscription SDK such as RevenueCat, Adapty or Qonversion. Play Console's policy status message names the deprecated version it detected in your uploaded bundle.

Related: Play Billing Library 8 Upgrade, Android Update Readiness Checker

Because the block is on publishing, not on purchasing. Google deprecates each Play Billing Library version two years after release, and since 31 August 2026 new apps and updates that sell in-app products or subscriptions must use version 8 or later. Existing installs keep working; your next release does not go out. An extension can be requested per app until 1 November 2026.

Related: Play Billing Library 8 Upgrade, App Publishing Deadlines

Usually yes, if you are coming from version 4–6. Version 8 removed the SkuDetails-era APIs, so product listing and purchase launching have to be rewritten against ProductDetails, and product details and pending purchases are handled differently. Plan for changes in the purchase flow, the restore path and server-side verification, plus a full test pass on real purchases rather than only on the happy path.

Related: Play Billing Library 8 Upgrade

It is Google's requirement that the developer behind an Android app is a verified identity and that the app's package name and signing keys are registered, so that certified Android devices will keep installing it. It reaches beyond Google Play: apps distributed as APKs or through other stores are in scope too. Enforcement starts regionally on 30 September 2026 and becomes global during 2027.

Related: Android Developer Verification, App Publishing Deadlines

No, and you should be suspicious of anyone who says they will. Identity verification is completed by the account holder, with their own documents, in Google's console — we never handle your government ID or D-U-N-S paperwork and never act as the account holder. What we do is the technical preparation around it: inventorying packages and signing keys, checking key eligibility and package-name conflicts, planning transfers and account structures, enrolling apps in Play App Signing, registering keys for non-Play channels and fixing the builds that follow.

Related: Android Developer Verification, About

It depends on whether the app uses Play App Signing. If Google holds the app signing key, a lost upload key can be reset through Play Console and publishing continues. If the app is signed with a key you hold and that key is gone, the app identity cannot be recreated — on Google Play that usually means a new package name and a migration, and for non-Play channels it means the old artefacts cannot be updated at all. Deal with this before verification, not after.

Related: Lost Keystore / Upload Key, Android Developer Verification

The listing, reviews and install base move. Almost everything the app depends on does not: the Firebase or Google Cloud project stays with its current owner, so the OAuth clients and API keys that authorise sign-in and Maps sit under an account the new owner may not control; AdMob and Play Games links break; purchase verification needs a service account on the receiving side; and subscriptions require a payments profile there. Tester groups are not recreated for you. The signing certificate on released builds does not change unless you deliberately change it. Most transfer problems surface days later, in the first release after the move.

Related: Google Play App Transfer, App Store App Transfer

Do not plan one on the assumption that it can be rolled back. Google's transfer documentation sets out the process and the conditions but describes no way to undo a completed transfer, and we cannot promise that Google will reverse one or approve a later transfer back — which is why the inventory work belongs before the request rather than after it. If you do need to undo a completed transfer, ask Play Console support what is available for your case, with both account owners on hand. Google reviews a transfer request within about two business days; the preparation around it — signing keys, fingerprints, backend ownership, payments — is the part that takes real time.

Related: Google Play App Transfer

The upload key and app signing key serve different roles. Under Play App Signing Google holds the app signing key and uses it to sign the APKs delivered to users, and it stays with the app through a transfer — so the transfer by itself does not change the certificate on anyone's installed app. The upload key is the separate decision: either the previous owner hands their keystore over, or the receiving account requests an upload key reset in Play Console. A reset changes only what Play accepts on upload; it does not re-sign released builds. Fingerprints registered with Google Sign-In, Firebase, Maps and other APIs are matched against the certificate the distributed build actually carries, so update them if the app signing key is upgraded, and wherever a service was registered against the upload or debug certificate — not automatically because the upload key changed.

Related: Google Play App Transfer, Lost Keystore / Upload Key

Apple publishes transfer criteria the app must meet before the transfer can be initiated, and they are checked against the app's current state — things like the app having at least one released version, no pending agreements or contracts on either side, and no dependencies Apple does not allow to move. Check the criteria before any commercial agreement is signed; a refused transfer after a sale is an expensive discovery.

Related: App Store App Transfer

Anything bound to the old team rather than to the app record. In practice: APNs authentication keys and push certificates, Sign in with Apple configuration, subscription shared secrets and App Store Server API credentials, Apple Pay merchant identifiers, iCloud containers, App Groups and keychain sharing groups, associated domains, TestFlight and Xcode Cloud setup. The first build from the receiving account also has to be signed under the new team, which is where signing and provisioning errors tend to appear.

Related: App Store App Transfer, iOS Code Signing & Profiles

No — the app record, its App Store identity and its install base move, so users keep the app and their purchase history. What can break for them is anything the app talks to: push notifications if the APNs cut-over is not planned, sign-in if Sign in with Apple is not migrated, and entitlement checks if the receiving account's server credentials are not in place. Plan the cut-over so those are live before, not after, the transfer completes.

Related: App Store App Transfer

Uploads are stored privately, never exposed at a public URL, never indexed and only viewable by our reviewers through an authenticated admin interface. We accept PNG, JPG and PDF only, validate the file contents, and keep files only as long as needed to handle your case. The Privacy Policy describes retention and your rights.

Related: Privacy Policy

The Decoder keeps a record so we can improve its patterns and see where it fails. The text is encrypted at rest, is never sent to analytics, is hidden from our own staff by default, and any explicit reveal by an administrator is logged. Do not paste credentials or secrets into the Decoder — it is for rejection messages only.

Related: Rejection Decoder, Privacy Policy

Completing the minimum closed-testing period is a prerequisite, not a guarantee. Google also looks at how testers engaged, whether they used the real features, whether you gathered and acted on feedback and whether the app looks ready for a wider audience. Twelve opt-ins are not automatically twelve meaningful testers. The reapplication questions are answered better after an honest look at what the test actually showed.

Related: Production Access Rejected, More Testing Required

Not necessarily. If your test was genuine and well documented, the problem may be how the application was answered or something in the app itself — that is what we diagnose here. If a case genuinely needs another qualifying closed test with real people, 12RealTesters.com, a related Keshav Infotech service, provides managed Google Play closed testing. App Rejection Fix handles diagnosis, readiness and technical fixes; 12RealTesters handles the testing itself. We never recommend another test by default.

Related: More Testing Required, About