App Rejection Library
37 structured entries covering the Google Play and App Store rejection messages we see most: what each means, the usual causes, what to check, and whether to fix, reply or appeal. Every entry links its official source and shows when it was last verified.
Showing 1–20 of 37 entries.
App Store
High
Rejection
Technical review likely
Guideline 3.1.1 — digital content unlocked outside In-App Purchase
Digital features, content or subscriptions were unlocked by an external payment, a code or a link, or IAP items were not reviewable.
Open entry ↓
Typical wording
Guideline 3.1.1 - Business - Payments - In-App Purchase. Your app unlocks or enables additional features or functionality with mechanisms other than the App Store.
Common causes
- External checkout for digital features
- Links steering users to buy elsewhere
- Products missing or not loading in sandbox
What to check
- Which items are digital and consumed in the app
- Storefront-specific rules and any entitlement programme
- Products submitted with the version and loading in sandbox
Fix / reply / appeal guidance
- Implement StoreKit purchases for digital items
- Keep physical goods and services on your own processor
- Make every purchase reviewable and mention it in the notes
- Policy / guideline:
- App Store Review Guideline 3.1.1 — In-App Purchase
- Category:
- Guideline 3.1.1 — In-App Purchase
- Official source:
- In-App Purchase (Apple Developer)
- Last verified:
App Store
High
Rejection
Technical review likely
Guideline 4.2 — app provides limited functionality or is a repackaged website
Apple judged the app too limited: a wrapped website, a brochure, or content that does not need a native app. Cosmetic changes rarely resolve this.
Open entry ↓
Typical wording
Guideline 4.2 - Design - Minimum Functionality. We found that the experience your app provides is not sufficiently different from a mobile browsing experience.
Common causes
- WebView showing the website
- Marketing or content-only app
- Template app with little custom functionality
What to check
- What the app does that a browser cannot
- Device capabilities used meaningfully
- Whether the core value lives in the app or elsewhere
Fix / reply / appeal guidance
- Add genuinely native, useful functionality or reconsider the format
- Reply only if the reviewer missed real functionality
- Do not bolt on random features for review
- Policy / guideline:
- App Store Review Guideline 4.2 — Minimum Functionality
- Category:
- Guideline 4.2 — Minimum Functionality
- Official source:
- App Store Review Guidelines
- Last verified:
App Store
High
Rejection
Technical review likely
Guideline 4.3 — app is too similar to other apps (spam)
Apple judged the app too similar to your other apps or to existing apps, or built from a template without meaningful differentiation.
Open entry ↓
Typical wording
Guideline 4.3(a) - Design - Spam. We noticed your app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences.
Common causes
- White-label or reskinned apps
- Purchased templates
- Multiple bundle IDs for one product
- Saturated category
What to check
- Comparison matrix against the similar apps
- Whether the portfolio could be one app with a picker
- Template origin and customisation depth
Fix / reply / appeal guidance
- Differentiate meaningfully or consolidate into a multi-tenant app
- Do not resubmit with a new icon, bundle ID or account
- Appeal only with a concrete comparison
- Policy / guideline:
- App Store Review Guideline 4.3 — Spam
- Category:
- Guideline 4.3 — Spam / Similar apps
- Official source:
- App Store Review Guidelines
- Last verified:
App Store
High
Rejection
Technical review likely
Guideline 5.1.1 — privacy policy, purpose strings or data collection issues
The privacy policy, permission purpose strings, data minimisation, mandatory login or App Privacy labels did not meet 5.1.1.
Open entry ↓
Typical wording
Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage. Your app requires users to register or log in before they can access non-account-based features, or the purpose string does not sufficiently explain the use of the data.
Common causes
- Vague usage descriptions
- Registration required for features that do not need it
- Privacy policy missing or unreachable
- Labels that disagree with the app
What to check
- Every Info.plist usage description
- Which features truly need an account
- Policy reachable in-app and in App Store Connect
- App Privacy labels against real data flows
Fix / reply / appeal guidance
- Write specific purpose strings
- Allow use without an account where possible
- Align the policy, labels and code
- Policy / guideline:
- App Store Review Guideline 5.1.1 — Data Collection and Storage
- Category:
- Guideline 5.1.1 — Data Collection and Storage
- Official source:
- App privacy details on the App Store
- Last verified:
App Store
High
Rejection
Technical review likely
Guideline 5.1.2 — tracking without App Tracking Transparency consent
The app or an SDK tracks users or shares data with third parties without the ATT prompt or beyond the stated purpose.
Open entry ↓
Typical wording
Guideline 5.1.2 - Legal - Privacy - Data Use and Sharing. Your app uses the App Tracking Transparency framework but tracks users before requesting permission, or collects data for tracking without consent.
Common causes
- Ads or attribution SDK initialised before consent
- Data shared with brokers
- Use beyond the disclosed purpose
What to check
- SDK initialisation order relative to the ATT prompt
- App Privacy tracking answers
- Privacy policy sharing section
Fix / reply / appeal guidance
- Show the ATT prompt before any tracking and respect refusal
- Gate SDKs on consent
- Align labels and policy
- Policy / guideline:
- App Store Review Guideline 5.1.2 — Data Use and Sharing
- Category:
- Guideline 5.1.2 — Data Use and Sharing / tracking
- Official source:
- App Tracking Transparency (Apple Developer Documentation)
- Last verified:
App Store
High
Rejection
Guideline 5.2 — third-party trademark or copyrighted content
Use of trademarks, copyrighted content or platform names and icons without authorisation.
Open entry ↓
Typical wording
Guideline 5.2.1 - Legal - Intellectual Property. Your app includes content or features that infringe on the intellectual property rights of a third party.
Common causes
- Brand names or logos you do not own
- Media without a licence
- Other-platform references
What to check
- Every brand and media asset
- Documentation of rights or authorisation
Fix / reply / appeal guidance
- Remove or license the material
- Provide authorisation documents if you appeal
- Policy / guideline:
- App Store Review Guideline 5.2 — Intellectual Property
- Category:
- Guideline 5.2 — Intellectual Property
- Official source:
- App Store Review Guidelines
- Last verified:
App Store
Medium
Rejection
Technical review likely
Guideline 2.1 — app crashed or exhibited bugs during review
The reviewer hit a crash, freeze or broken flow on the listed device and OS. Reproduce on the release build with that configuration.
Open entry ↓
Typical wording
Guideline 2.1 - Performance - App Completeness. We discovered one or more bugs in your app when reviewed on iPhone running iOS. Specifically, the app crashed on launch.
Common causes
- Release-only crash (optimisation, entitlements, configuration)
- Backend or third-party service unreachable during review
- Missing usage description causing a crash on permission access
What to check
- The device model and OS in the message
- Symbolicated crash log
- Backend reachability from outside your network
- Fresh-install behaviour
Fix / reply / appeal guidance
- Fix the defect and upload a new build
- Describe the fix in the review notes
- Run a cold test on a clean device
- Policy / guideline:
- App Store Review Guideline 2.1 — Performance: App Completeness
- Category:
- Guideline 2.1 — App Completeness
- Official source:
- App Store Review Guidelines
- Last verified:
App Store
Medium
Rejection
Technical review likely
Guideline 3.1.2 — subscription terms, trial or restore issues
Auto-renewable subscription terms, pricing, trial disclosure or restore-purchase behaviour did not meet the subscription rules.
Open entry ↓
Typical wording
Guideline 3.1.2 - Business - Payments - Subscriptions. Your app's subscription purchase screen does not clearly display the price and length of the subscription.
Common causes
- Price or term not shown before purchase
- Trial length unclear
- Restore Purchases missing
What to check
- Purchase UI shows full terms
- Subscription groups configured
- Restore flow works in sandbox
Fix / reply / appeal guidance
- Display price, period, trial and renewal terms before purchase
- Implement Restore Purchases
- Link terms of use and privacy policy where required
- Policy / guideline:
- App Store Review Guideline 3.1.2 — Subscriptions
- Category:
- Guideline 3.1.2 — Subscriptions
- Official source:
- In-App Purchase (Apple Developer)
- Last verified:
App Store
Medium
Rejection
Technical review likely
Guideline 4.8 — third-party login without an equivalent privacy option
The app offers third-party or social login without an equivalent login option that meets the privacy requirements of Guideline 4.8.
Open entry ↓
Typical wording
Guideline 4.8 - Design - Login Services. Your app uses a third-party login service but does not offer an equivalent login option with the privacy features required.
Common causes
- Only Google or Facebook sign-in offered
- Sign in with Apple missing or not equivalent
What to check
- Login options and their capabilities
- Whether the alternative meets the 4.8 privacy features
Fix / reply / appeal guidance
- Add a compliant login option such as Sign in with Apple with equivalent capabilities
- Policy / guideline:
- App Store Review Guideline 4.8 — Login Services
- Category:
- Guideline 4.8 — Login Services
- Official source:
- App Store Review Guidelines
- Last verified:
App Store
Medium
Rejection
Technical review likely
Guideline 5.1.1(v) — account deletion not offered in the app
Apps that support account creation must let users initiate deletion of their account from within the app.
Open entry ↓
Typical wording
Guideline 5.1.1(v) - Data Collection and Storage. Your app supports account creation but does not include an option to initiate account deletion.
Common causes
- No in-app deletion path
- Deletion only by email or website
- Deletion hidden or non-functional
What to check
- Deletion option location
- Backend actually removes or anonymises data
- Review notes mention the feature
Fix / reply / appeal guidance
- Implement in-app account deletion with backend support
- Mention where it is in the review notes
- Policy / guideline:
- App Store Review Guideline 5.1.1(v) — account deletion
- Category:
- Guideline 5.1.1(v) — Account deletion
- Official source:
- Offering account deletion in your app
- Last verified:
App Store
Medium
Warning / notice
Technical review likely
ITMS-90078: Missing Push Notification Entitlement
App Store Connect accepted the upload but emailed ITMS-90078: the app links the Push Notifications framework without carrying the aps-environment entitlement, so the build cannot be submitted as it is.
Open entry ↓
Typical wording
ITMS-90078: Missing Push Notification Entitlement - Your app appears to include API used to register with the Apple Push Notification service, but the app signature's entitlements do not include the "aps-environment" entitlement.
Common causes
- The Push Notifications capability is not enabled on the target, so Xcode never added aps-environment to the entitlements file
- The capability is enabled on the target but not on the App ID, so the provisioning profile does not grant it
- A stale provisioning profile created before the capability was added is still being used (often on CI)
- An SDK links the push APIs even though the app itself does not use push — Firebase Messaging, OneSignal, analytics and chat SDKs all do this
- Manual signing with an entitlements file that was copied from another project
What to check
- Signing & Capabilities on the app target: is Push Notifications listed?
- The target's .entitlements file: does it contain aps-environment (development or production)?
- Apple Developer → Identifiers → your App ID: is Push Notifications enabled?
- The profile the archive was signed with — regenerate it after any capability change
- Whether push is actually a feature; if not, remove the SDK or its push component instead
Fix / reply / appeal guidance
- If the app uses push: enable Push Notifications on the target and on the App ID, regenerate the provisioning profile, archive again and re-upload
- On CI: refresh the profiles after the capability change; automatic signing with an App Store Connect API key avoids stale profiles
- If the app does not use push: remove the SDK (or its push module) so the API is no longer linked, rather than adding an entitlement you do not need
- Remember the server side is separate — an APNs auth key or certificate is what actually sends notifications; the entitlement only makes the build valid
- Policy / guideline:
- Push Notifications capability and the aps-environment entitlement
- Category:
- Code signing / provisioning / entitlements
- Official source:
- Apple Developer Documentation — Capabilities (entitlements)
- Last verified:
App Store
Medium
Warning / notice
Technical review likely
Invalid Binary: the upload was accepted, then failed validation
The archive uploaded and then the build turned to “Invalid Binary”, usually with an ITMS-90xxx email. Validation happens after upload, so the problem is in the binary itself — not in App Review.
Open entry ↓
Typical wording
Invalid Binary — We have discovered one or more issues with your recent delivery. Please correct the following issues and upload a new binary.
Common causes
- The build was made with an SDK or Xcode version Apple no longer accepts
- A required entitlement is missing, or an entitlement is claimed that the provisioning profile does not grant
- Missing privacy manifest or required-reason API declarations for the app or a listed SDK
- Unsupported or missing architectures, simulator slices left in a framework, or a bitcode-era artefact
- Missing app icon at a required size, or an invalid Info.plist value (version, bundle ID, deployment target)
- The version or build number is not higher than a build already uploaded
What to check
- The ITMS email: it names the exact rule that failed
- The Xcode Organizer validation step before distribution — it catches most of these locally
- Toolchain: the app must be built with the current required Xcode and platform SDK
- Entitlements versus the provisioning profile used for the archive
- The privacy report generated from the archive (Xcode → Generate Privacy Report)
Fix / reply / appeal guidance
- Fix the specific ITMS code rather than rebuilding blindly — each one maps to a single rule
- Validate in Xcode Organizer before uploading; it is the same validation that runs server-side
- Rebuild with the required Xcode and SDK version, then re-check entitlements and privacy manifests
- Increment the build number for every upload attempt, even for a failed one
- Policy / guideline:
- App Store Connect build validation
- Category:
- Build rejected at upload (Xcode / SDK / privacy manifest requirement)
- Last verified:
App Store
Medium
Rejection
Technical review likely
Missing privacy manifest or required-reason API declaration
The build uses required-reason APIs or listed SDKs without the privacy manifest declarations Apple expects (ITMS upload warnings or rejection).
Open entry ↓
Typical wording
ITMS-91053: Missing API declaration - Your app's code in the "App" file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryFileTimestamp, NSPrivacyAccessedAPICategoryUserDefaults.
Common causes
- A third-party SDK on Apple’s list (Firebase, Facebook, Alamofire, Flutter/RN plugins …) at a version without PrivacyInfo.xcprivacy
- App code using required-reason APIs (file timestamps, UserDefaults, system boot time, disk space, active keyboards) without declared reasons
- An app-level privacy manifest that is missing, not in the main bundle, or not copied by the build
- Outdated CocoaPods / Swift Package dependencies pinned by an old lockfile
What to check
- The API categories and SDK names listed in the ITMS email
- Podfile.lock / Package.resolved versions against each vendor’s first manifest-bearing release
- Whether PrivacyInfo.xcprivacy is in the app target and each framework target that needs one
- The generated privacy report in Xcode (Archive → Generate Privacy Report)
Fix / reply / appeal guidance
- Upgrade every listed SDK to a version that ships a privacy manifest and signature
- Add PrivacyInfo.xcprivacy to the app with the approved reason codes for each API category the app itself uses
- Fill NSPrivacyCollectedDataTypes and NSPrivacyTracking so they match the App Store privacy details
- Rebuild with Xcode 26, generate the privacy report, re-upload and confirm no ITMS email arrives
- Policy / guideline:
- Privacy manifest files and required-reason APIs
- Category:
- Privacy manifest / required reason API
- Official source:
- Privacy manifest files (Apple Developer Documentation)
- Last verified:
App Store
Low
Reviewer question
Guideline 2.1 — Information Needed (reviewer questions)
This is a question, not a rejection. App Review needs details about functionality, data use or business model before continuing.
Open entry ↓
Typical wording
Guideline 2.1 - Information Needed. We need additional information about your app to continue the review. Please answer the following questions.
Common causes
- Business model unclear from the app
- Features gated to certain users
- Data use that needs explanation
What to check
- Each question individually
- Whether the review notes already answer it
Fix / reply / appeal guidance
- Answer every question factually in App Store Connect
- Do not appeal or resubmit a new build until answered
- Policy / guideline:
- App Store Review Guideline 2.1 — Information Needed
- Category:
- Guideline 2.1 — Information Needed
- Official source:
- App Store Review Guidelines
- Last verified:
App Store
Low
Rejection
Technical review likely
Guideline 2.1 — reviewer could not sign in
The demo account was missing, expired or blocked by OTP, SSO or region, so the app could not be fully reviewed.
Open entry ↓
Typical wording
Guideline 2.1 - Information Needed. We were unable to sign in with the demo account credentials you provided. Please provide a valid demo account with full access to all features.
Common causes
- Expired or single-use credentials
- OTP the reviewer cannot receive
- Social login only
- Region or device restrictions
What to check
- Credentials in App Review Information match the current build
- Every feature reachable with the review account
- A cold tester can follow the notes
Fix / reply / appeal guidance
- Provide a durable demo account with OTP bypass
- Add an email/password path for review
- Update App Store Connect every time credentials change
- Policy / guideline:
- App Store Review Guideline 2.1 — App Completeness (demo account)
- Category:
- Guideline 2.1 — Demo account / login
- Official source:
- App Store Review Guidelines
- Last verified:
App Store
Low
Metadata rejected
Guideline 2.3 — screenshots or description do not reflect the app
Screenshots, previews, description, name or keywords do not match the app. Usually fixable in App Store Connect with the same build.
Open entry ↓
Typical wording
Guideline 2.3.3 - Performance - Accurate Metadata. We noticed that your screenshots do not sufficiently reflect the app in use.
Common causes
- Screenshots from another platform or app
- Marketing composites not showing the app
- Claims the app cannot back up
What to check
- Every screenshot against the build
- Claims and superlatives in the description
- Name and subtitle for keyword stuffing
Fix / reply / appeal guidance
- Capture screenshots from the actual build
- Correct the listing and resubmit the same build
- Remove other-platform references
- Policy / guideline:
- App Store Review Guideline 2.3 — Accurate Metadata
- Category:
- Guideline 2.3 — Accurate Metadata
- Official source:
- App Store Review Guidelines
- Last verified:
App Store
Low
Warning / notice
Missing Compliance: the build is waiting for an export-compliance answer
The build uploaded successfully but App Store Connect shows “Missing Compliance”. Until the encryption questions are answered the build cannot be distributed to TestFlight testers or submitted for review.
Open entry ↓
Typical wording
Missing Compliance — You must provide export compliance information for this build before it can be submitted for review or distributed to testers.
Common causes
- The encryption questions were never answered for this build
- The app uses HTTPS or standard platform cryptography and the developer assumed no declaration was needed
- Info.plist does not contain ITSAppUsesNonExemptEncryption, so the prompt returns for every new build
- The answer given previously does not carry over because the encryption usage changed
What to check
- App Store Connect → the build → Provide Export Compliance Information
- Whether the app only uses standard encryption (HTTPS, platform crypto) or ships its own / non-standard algorithms
- Info.plist for ITSAppUsesNonExemptEncryption
- Whether a French import declaration applies to your distribution
Fix / reply / appeal guidance
- Answer the questions on the build; for apps that only use standard encryption the declaration is usually a single answer and the build is released immediately
- Add ITSAppUsesNonExemptEncryption to Info.plist so the question stops appearing for every build — set it to the value that is true for your app
- If the app uses non-standard or proprietary encryption, prepare the documentation the regulations require (self-classification report, ERN or CCATS) before submitting
- Do not guess: the declaration is a legal statement about what the app does
- Policy / guideline:
- Export compliance (encryption declaration)
- Category:
- Build rejected at upload (Xcode / SDK / privacy manifest requirement)
- Official source:
- App Store Connect Help — Overview of export compliance
- Last verified:
Google Play
Critical
Removal
Technical review likely
App or SDK flagged as malware or unwanted software
The app or a bundled SDK was flagged for malicious, unwanted or non-compliant behaviour. Third-party code is your responsibility.
Open entry ↓
Typical wording
Issue found: Malware policy violation. Your app contains code that engages in malicious behavior or mobile unwanted software behavior.
Common causes
- Monetisation or ad SDK with undisclosed behaviour
- Remote code loading
- Device fingerprinting or data exfiltration by a library
What to check
- SDK inventory with versions
- Network behaviour of a release build
- Obfuscated or dynamically loaded code
Fix / reply / appeal guidance
- Identify and remove or update the flagged component
- Rebuild and describe the change if appealing
- Do not republish elsewhere
- Policy / guideline:
- Malware and Mobile Unwanted Software policies
- Category:
- Malware / unwanted software / SDK
- Official source:
- Google Play Developer Program Policies (Policy Center)
- Last verified:
Google Play
Critical
Suspension
Technical review likely
App suspended from Google Play
A suspension is a serious enforcement action: the app is removed and the suspension may count as a strike toward account termination.
Open entry ↓
Typical wording
Your app has been suspended and removed from Google Play due to a policy violation. Suspensions are associated with your developer account.
Common causes
- Repeated or egregious policy violations
- Deceptive behaviour, malware or impersonation
- Association with a previously suspended app or account
What to check
- The exact policy cited and the enforcement history
- Other apps in the account with the same issue
- Any association concerns mentioned
Fix / reply / appeal guidance
- Do not republish under a new listing or account
- Understand the finding fully and fix the cause
- Appeal once, with evidence, through the official form
- Policy / guideline:
- Enforcement Process
- Category:
- App suspended
- Official source:
- Play Console Help — Enforcement Process
- Last verified:
Full entry pages
The most common messages have their own page with the complete explanation, checks and fix guidance.
- App Store: Guideline 3.1.1 — digital content unlocked outside In-App Purchase
- App Store: Guideline 4.2 — app provides limited functionality or is a repackaged website
- App Store: Guideline 4.3 — app is too similar to other apps (spam)
- App Store: Guideline 5.1.1 — privacy policy, purpose strings or data collection issues
- App Store: Guideline 2.1 — app crashed or exhibited bugs during review
- App Store: ITMS-90078: Missing Push Notification Entitlement
- App Store: Invalid Binary: the upload was accepted, then failed validation
- App Store: Missing privacy manifest or required-reason API declaration
- App Store: Guideline 2.3 — screenshots or description do not reflect the app
- App Store: Missing Compliance: the build is waiting for an export-compliance answer
- Google Play: App suspended from Google Play
- Google Play: Developer account terminated
- Google Play: Data safety declaration does not match app behaviour
- Google Play: Invalid or unreachable privacy policy URL
- Google Play: Production access application not approved
- Google Play: Repetitive content / limited functionality: the app is not different enough
- Google Play: Reviewer could not access the app (login or credentials)
- Google Play: Version code already used: Play Console refuses the bundle
Your message is not in the library?
Send it to us. Classifying unfamiliar notices is how the library grows — and how you get a specific answer instead of a category.
What happens next: an engineer on our technical team reads the notice you send — not an autoresponder. We work out what it most likely means and what we would check, and reply with that assessment and a recommended next step.
Initial rejection review is free. Technical implementation, if required, is quoted separately.
Get My Free Rejection Review
Free initial review · No payment required · No source code required initially