Here is a rule that catches almost every first-time publisher, and a surprising number of experienced ones: your App Store listing is not allowed to mention Android, and your Google Play listing is not allowed to mention the App Store. Not as a discouraged style choice — as a hard submission-blocker. Apple will reject an iOS build whose description says the game is “also available on Google Play,” and Google will reject the Android build that brags about its App Store rating. The two stores sell the exact same binary of our game to overlapping humans, and each one requires the store page to be written as if the other store, and the entire device family it runs on, simply does not exist. The word that gets your submission bounced is frequently not a swear word or a trademark — it is the name of the competitor you were being helpful about.
A store listing is copy, and the store owns the shelf
Start with the mechanism, because it is more
concrete than the folklore around it. A store listing is a small pile of
text files. When we push a release, the metadata that goes up with it is
plain, per-locale copy: on iOS a set that includes
name.txt, subtitle.txt,
description.txt, keywords.txt,
promotional_text.txt, and release_notes.txt; on
Android title.txt, short_description.txt,
full_description.txt, and the per-version
changelogs. Every one of those strings is read by a human
reviewer and matched against the store’s rules before the app goes
live. The copy is not documentation about your product — it is
marketing that lives on someone else’s shelf, and the shelf owner has
opinions about what you may say on it.
The specific opinion here is Apple’s App Store Review Guideline 2.3.10: an app’s metadata must be about the app itself, and must not include “names, icons, or imagery of other mobile platforms” unless there is an approved, specific reason. In plain terms, an iOS listing that says “Android,” “Google Play,” “Play Store,” or drops a Pixel into a screenshot is out of policy, and the reviewer will say so. Google runs the mirror image: a Play listing is expected to be about the app on Android and Google Play, not a billboard for the same game on iPhone. So the same sentence — “Play our puzzle on iPhone, iPad, and Android” — is a rejection on both stores at once, for opposite reasons.
Why the rule exists, and why it is not petty
It is easy to read this as two giants sulking, and the honest position is more generous than that. A store page is the one surface the platform fully controls, and its job there is to keep a shopper shopping. A line telling an iPhone owner that the game is also on Google Play is, from Apple’s side of the counter, an invitation to leave the counter — and every rival’s logo you place on that shelf is borrowed attention the store did not agree to lend. Seen that way the rule is coherent: the storefront is theirs, the copy is an ad running in their space, and they get to say the ad may not point at the exit. That is a defensible position, not a tantrum.
The cost, which we will not pretend away, lands entirely on the developer who thinks of the game as one product. To us, “the same puzzle, on your iPhone and your Android tablet” is simply true and useful. To each store it is contraband. So the friction is real and it is ours to absorb: one game, one set of facts about where it runs, and two listings that must each describe a smaller, platform-shaped version of that truth. The rule is reasonable from where the store sits and annoying from where we sit, and both of those are true at the same time.
The forbidden words hide in more places than the description
If the whole problem were the long description, it would be a five-minute proofread. It is not, because a store listing has a dozen text fields and several image slots, and the offending reference loves the corners nobody re-reads. The keyword list is a classic: someone adds “android” as a search term months ago and it sits there through twenty releases until a reviewer finally notices. Promotional text and release notes are next, because “now on Android too!” feels like exactly the kind of thing you put in release notes. Then there are the screenshots — a device frame showing a Pixel, or a status bar that is unmistakably not iOS, is an image-level version of the same violation, and an image is far easier to ship without reading than a paragraph is.
There is also a quieter trap in the honest,
helpful sentence about availability. “Works on all your devices”
is fine; “works on iPhone, iPad, and Android” is not. Our rule of
thumb is to describe only the platform whose store you are standing in: on
iOS the phrase is “iPhone and iPad,” on Android it is
“phones and tablets,” and neither listing reaches across the
aisle. The flip side is knowing what is not in scope, so you do not
start sanitising the wrong files in a panic. Our own README,
CHANGELOG, and architecture docs are free to talk about both
platforms all day — they are engineering documents, they never get
uploaded to a store, and no reviewer will ever read them. The rule applies
to exactly the files the store ingests, and to no others.
We do not trust ourselves to remember
Knowing the rule and reliably obeying it are different problems, and only the second one keeps a release on schedule. A cross-platform reference is precisely the kind of small, boring mistake that a tired human proofreader skims straight past, especially in the fields nobody thinks of as copy. So we do not rely on the proofread. Before any store upload, we run a plain text search across every metadata file the store will ingest — the iOS set for “android,” “google play,” “play store”; the Android set for “ios,” “iphone,” “ipad,” “apple,” “app store” — and the expected result is zero hits. One hit and the upload does not go. It is a two-line grep, and it has exactly the job description of a machine: to check the thing a person would swear they already checked.
This is the same instinct we wrote about when a game declared an iOS capability it never used and got rejected twice for it: the fix that matters is never the one edit, it is the check that makes the edit impossible to forget. A rule you carry in your head fails the first busy week; a rule the build refuses to skip does not. And because the audit runs against the actual uploaded files, it catches the keyword nobody re-reads and the release note written in a hurry, which is exactly where a human review would have let it through.
The deeper point outlasts the two app stores. The code behind our games barely notices which store it is bound for — that story, of what genuinely forks between iOS and Android, is its own post. The words are a different matter: the same product has to be described twice, once for each audience that is not allowed to see the other. That is not unique to app stores. Any time the same thing is sold into two contexts that pretend the other is not there, the honest move is not to write one clever sentence that technically survives both — there usually is not one — but to write plainly for the reader actually in front of you, and to let a machine, not your memory, guard the line you keep forgetting you drew. If you want to see the games these listings are describing, they are over on the apps page; the longer version of how these small shipping disciplines compound lives on the WizusLabs Engineering blog. Write for one store at a time, and never name the other.
Notes
This is a first-hand engineering account of a store-metadata discipline we enforce on every release. It contains no invented metrics: we have deliberately attached no rejection count, review-time, or conversion number to any of it, because the point is the rule and the check, not a statistic we did not measure. The exact wording, scope, and enforcement of both stores’ policies are living documents that change over time; the guideline and policy pages we rely on are cited below, and you should verify the current text against Apple’s and Google’s own pages before relying on it for a submission. The forbidden-word lists in this post are the practical set we screen for, not an exhaustive statement of either policy.
Sources
The store requirements this post leans on are documented by the platforms themselves (living documents; accessed 2026-07-26):
- Apple — App Store Review Guidelines, §2.3.10 (Accurate Metadata): app metadata must be about the app itself and must not include names, icons, or imagery of other mobile platforms unless there is an approved, specific reason to reference them.
- Google Play — Metadata policy (Play Console Help): store listing text and assets must accurately and appropriately represent the app on Google Play, and Google restricts promotional and off-platform references in listing metadata.
Keep reading: all posts on the WizusLabs Engineering blog.