The support tickets arrive first: users charged for a subscription in an app the brand does not publish, or locked out after entering their real password into a login screen that was not real.
By the time support connects the dots, the fake may have thousands of installs, because store search rewards the exact brand term the impersonator targeted and the copy is good enough at thumbnail size.
Three monetization shapes recur. Ad and subscription abuse: a thin utility wearing your brand, free to install, aggressive weekly subscription behind a fake feature wall. Credential and payment harvesting: a login screen styled as yours, collecting credentials that are then tested against your real service, tying app impersonation to account takeover. And traffic resale: the app works just enough, as a web view of your public site wrapped in extra trackers, monetizing your audience's data en route.
Naming the shape matters for the report. Stores triage deception and data harvesting above simple trademark similarity, and your filing should lead with the user harm you can document, screenshots of the fake login, subscription screens, and user reports, not only the logo comparison.
Both major stores have intellectual property and impersonation reporting channels separate from user reviews. File with your trademark registration details, your official app's listing as the reference, and the specific policy violations: impersonation, deceptive behavior, and trademark use. Keep a template filing updated with your current marks and official listings so a new fake is a fifteen minute report, not a research project.
Where the fake harvests credentials, add the security dimension: notify your fraud team, watch for credential stuffing patterns against accounts, and consider in app and email warnings to users if install counts suggest real exposure. The store removal stops new installs; it does nothing for the passwords already collected.
Set store monitoring on your brand terms and common misspellings, and check new releases weekly in your main markets, including regional stores where the impersonator may launch first to avoid attention. Icon similarity search and developer name watching catch the repeat offenders, who return under new developer accounts with the same assets. Each removal should feed the watch list: same icon set, same screenshot style, new name. Keep the evidence pack from each case, the store listing captures, your filing, and the removal confirmation, in one folder per incident. The second filing against the same operation goes faster with the first case attached, and a pattern across incidents is what eventually interests regulators as well as stores.
They submit a benign build that behaves at review time, keep the abusive monetization behind server side switches or delayed flows, and rely on the brand assets doing the persuading. Review screens for policy violations, not for your trademark specifically.
Trademark registration, your official listing for comparison, and documented user harm: fake login screens, subscription traps, support reports from deceived users. Lead with impersonation and deception, not only similarity.
If install counts or support reports suggest real exposure, yes: name the fake's store listing details, state your official app's publisher name, and advise anyone who entered credentials to change passwords. Silence protects the impersonator's funnel.
Not permanently, but monitoring plus fast template filings compress their window to days. Repeat offenders also accumulate store level strikes; your consistent reporting is what builds that record.