Understanding App Rejections
Last updated: June 9, 2026
What This Does
This guide explains the most common reasons branded mobile apps are rejected when submitted to the Apple App Store and Google Play Store, and how to avoid them. Use it before handing an app to the app team so submissions clear review without avoidable delays.
Note: Both stores enforce strict guidelines on branding, metadata, content, and functionality. Reviewing these checks up front is the fastest way to a smooth approval.
Before You Begin
The app should be ~90% complete with enough populated pages to capture meaningful store screenshots.
For any branded app using a client's name, logo, or trademark, collect a signed brand-authorization document before submission.
Confirm the chosen app name is available on the target store and have an alternative ready.
The Three Core Review Areas
Apple groups its review guidelines into three broad areas. Google Play applies equivalent standards.
Safety: Apps must not include offensive, insensitive, or disturbing content. Content intended to disgust or in exceptionally poor taste will be rejected.
Performance: All metadata — privacy information, descriptions, screenshots, and previews — must truthfully represent the app's core functionality. Avoid hidden, dormant, or undocumented features. Screenshots should showcase real usage, not just title art or splash screens. Keep the app name unique and avoid stuffing metadata with irrelevant phrases or trademarked terms.
Business / Design: Apps should offer features, content, and UI that differentiate them from a simple website replica. An app that lacks uniqueness or utility may not meet store standards.
Common Rejection Reasons and How to Fix Them
1. Impersonation / "Copycats" / Branding Without Authorization
This is the single most common reason for rejection. Whenever a branded app uses a client's name, logo, or trademarked term, both stores require signed proof that we are authorized to publish on the client's behalf.
What gets flagged:
App name containing the client's brand or trademark.
App icon or hi-res icon that matches the client's official logo.
Short description or store listing copy referencing the client's brand.
Store policy names:
Google Play: "Impersonation policy" violation.
Apple App Store: "Copycats" / Guideline 4.3(a) – Design.
How to clear it: Provide a signed authorization document before submission. Accepted forms:
An agreement signed by both parties.
A signed declaration or authorization letter.
A signed contract, licensing, or distribution agreement.
The letter must be on the brand owner's official company letterhead, name the exact app package / bundle ID, grant explicit permission to use the branding on the relevant store, and be signed by an authorized representative of the brand owner.
Not accepted: Screenshots, emails, or other informal communications.
From past cases: Apps have been rejected multiple times and even removed from a store while authorization was being verified. Collect the signed letter up front to avoid release delays. An iOS app icon that is identical or too similar to another app already on the store can also trigger a 4.3(a) rejection — the fastest fix is to create a unique icon.
2. App Description Does Not Reflect Actual Functionality
Rejected when the store description does not accurately describe what the app does.
Rejected when the description is too promotional or marketing-heavy instead of explaining functionality.
Fix: Write the description around what users can do in the app — view the schedule, see speakers, build an agenda, find maps, network, and get updates.
3. Identical Title and Short Description (Google Play)
If the app name and the Android short description are identical, Google rejects with "Identical title and description."
This is a hard blocker — the short description must differ from the app name and add context.
4. App Name Already Exists on the Store
New app creation can be rejected because the chosen app name is already taken on the App Store.
Fix: Confirm name availability early and have an alternative name ready.
5. Insufficient Content / App Not ~90% Complete
Apps with multiple blank pages or minimal data get rejected.
The app must be ~90% complete before it is handed to the app team for submission.
There must be enough populated pages (home page, schedule, speakers, FAQ, etc.) to capture meaningful store screenshots. A home page is required.
Tip: Proactively hide pages that have no content before submission, then unhide them once the app is approved.
6. Screenshots Must Show Real, Core Functionality
Apple rejects listings whose screenshots only show title art, splash screens, or placeholder images.
Screenshots must accurately represent the actual UI and show the main screen / core functionality of the app.
Misleading or unclear screenshots lead to rejection.
7. Hotspots / CTAs Not Configured
Rejected when interactive hotspots on call-to-action buttons are not configured, so taps lead nowhere.
Every CTA must lead the user to a relevant destination inside the app.
This is a submission blocker — verify all CTAs are wired before submitting.
8. Button Color / Contrast — CTAs Look Disabled
Buttons whose color blends into the background, or that resemble a disabled (gray) state, can be read as unresponsive by automated and manual reviewers.
Ensure primary colors have sufficient contrast against the theme so buttons are clearly tappable and active.
Pre-Submission Checklist
Signed brand-authorization letter is collected.
App icon is unique (not identical to other store apps).
Description explains functionality, not marketing claims.
Short description differs from the app name (Google Play).
App name confirmed available on the target store.
App is ~90% complete; no blank pages; home page present.
Store screenshots show real core UI (not splash, placeholder, or Networking).
All CTA hotspots are configured and lead to valid destinations.
Button colors have sufficient contrast (no disabled-looking CTAs).
No changes are planned during the review window.
What Happens Next
Approval typically takes ~4 to 48 hours.
Republishing goes through review again (typically 24–48 hours).
By following these guidelines and staying vigilant throughout submission, you can minimize the risk of rejection and get apps approved on the store more smoothly.