Spam, copycat apps, ads and deceptive design explained
A large share of rejections are not about what an app contains but about whether it is what it claims to be and whether it adds anything to the store. Spam and copycat rules protect the store from duplicates and imitations. Advertising and deception rules protect users from interfaces that mislead them or interrupt them at the wrong moment.
These rules are judged by effect, not by intent. A developer who did not design a misleading full-screen ad, because it was injected by an advertising library, can still be held responsible for it. Likewise, an app that is technically original but reads as a lightly re-skinned template is treated as a duplicate.
Reviewers look at the overall impression an app creates. They compare it with other apps on the store, read its listing as a user would and watch what happens when an ad appears or a button is tapped. This is why these decisions can feel subjective, and why two similar apps sometimes get different outcomes.
How Apple approaches it
Apple covers duplication in guideline 4.3 (Spam), impersonation in 4.1 (Copycats) and template-built apps in 4.2.6. Names and keywords have their own rule, 2.3.7, and business-model abuse such as inflated ad engagement is in 3.2.2. Advertising placement is restricted by 2.5.18, which keeps ads inside the app, and push notifications are limited to messages the user wants by 4.5.4.
How Google Play approaches it
Google's Spam policy covers apps with trivial differences and apps that only redirect elsewhere, while the Impersonation policy covers look-alikes. Metadata rules address keyword stuffing and misleading listings. The Ads policy limits disruptive placement, Ad Fraud covers invalid impressions and clicks, and the Deceptive Behavior, Social Engineering and System UI Imitation policies address interfaces designed to mislead.
Where the two platforms differ
- Apple expresses duplication mainly through guideline 4.3 and separates impersonation into 4.1. Google combines related ideas across its Spam and Impersonation policies.
- Both prohibit keyword stuffing and borrowed brand names in listings.
- Google has more granular policies on ad behaviour and deceptive interface design. Apple handles similar issues through a smaller number of broader guidelines.
- Both hold the developer responsible for ads and behaviour supplied by third-party SDKs.
- Both treat repeated violations as a pattern that can affect the whole developer account.
What reviewers typically check
- How the app compares with other apps on the store, including other apps from the same developer account.
- Whether the name, icon and screenshots could be confused with another app or brand.
- Whether keywords and descriptions describe the app or borrow popular unrelated terms.
- When and where ads appear, and whether any of them imitate system messages or controls.
- Whether buttons, prompts and warnings do what they appear to do.
Key terms
- Design spam
- Apps that share the same structure and look as other apps, offering little that is distinct.
- Template app
- An app generated from a shared template or builder, often with only branding changed.
- Interstitial
- A full-screen ad shown between parts of an app's experience.
- Keyword stuffing
- Filling a listing with repeated or unrelated terms to influence search results.
- Scareware
- Content that uses false alarms, such as fake infection warnings, to push users into an action.
Common questions
Template use is not banned in itself. The concern is whether the resulting app adds something distinct and who submits it.
The developer, since the library is part of the app.
Reviewers judge the overall impression and the risk of confusing users, not a single design choice.
Apple guidelines on this topic
Google Play policies on this topic
Platform rules change often. This page is a plain-language overview written by AppReviewFix, not official guidance. Check the App Store Review Guidelines and the Google Play Developer Program Policies for the exact current wording.