In January 2024, Craig Raw, the developer of the real Sparrow Wallet, a Bitcoin wallet app, warned that a fake version of his app was live on the Apple App Store. He reported it repeatedly, but the listing stayed up.
By August 2025, three people had lost a combined $1.8 million to it: Jalen Delgado (about $120,000 in May 2025), James Ramirez (about $875,000 in July 2025), and Christopher Ellis (about $840,000 in August 2025). All three are now suing Apple. The complaint, Ramirez, et al. v. Apple Inc., alleges Apple failed to properly vet and monitor software on the App Store. Apple hasn't filed a motion to dismiss; it has publicly said it removed apps impersonating Sparrow Wallet, and there's no ruling, dismissal, or settlement yet.
This case follows a pattern that repeats across app stores: a fake app stays up for months despite repeated reports because the impersonated developer is the only one watching.
Most brand monitoring covers the open web: domains, social media, marketplaces, and the occasional dark web forum. App stores rarely make the list, largely because they feel like someone else's responsibility — Apple's and Google's, specifically.
That assumption is true until you notice that Apple and Google police their platforms, not your brand. The platforms have no way of knowing that a listing named after your product, using your logo, or citing your organization in its description deserves a second look before a customer downloads it.
App stores also don't behave like the rest of the web. They're closed, curated catalogs with no crawlers that index the way search engines index public websites, so the monitoring your team already relies on has never looked inside the Apple App Store or Google Play. It's a structural blind spot, and attackers found it long before most security teams did. Closing it means building a monitoring approach for how app stores work, not bolting a workaround onto tools designed for something else.
That approach now has a name. App Store Threat Detection is rolling out now in beta to Breach Risk customers. It adds continuous visibility into the Apple App Store and Google Play to Threat Monitoring, surfacing apps that reference your brand, whether or not you own or authorize them.
.png)
App Store Threat Detection isn't about managing the apps you've already built; it's about spotting unauthorized, lookalike apps using your name before they can defraud your customers. Best of all, it uses your existing brand search rules, the same Transforms already powering your Threat Monitoring, so there's nothing new to configure. If you're already on Breach Risk Threat Monitoring, this capability is fully integrated. There are no new configurations, no additional Threat Credits, and no price change.
Why do attackers bother with app stores at all when the open web is right there? The answer comes down to uncomfortable math. Publishing a convincing phishing site takes real effort: hosting, a domain that hopefully doesn't get flagged, and some social engineering to drive traffic. Publishing a fake app in the App Store or Google Play takes a name, a description, and an icon, and it inherits a decade of platform trust for free. You'd hesitate before clicking a suspicious link, but you'll download an app from "the App Store" without a second thought, because the App Store is supposed to be the safe platform.
That’s where traditional monitoring falls short. It guards the fence line of the open web while rogue apps walk right through the front door, wrapped in the credibility of a trusted platform.
193,000 developer accounts shut down. 371,000 copycat submissions blocked. Even at that scale, platform reviews can't keep up with the steady rise in deceptive uploads, and standard monitoring tools weren't built for this gap.
So how does it work? The threat detection process starts by doing what a potential customer would: running automated searches across the Apple App Store and Google Play for your brand name. This mimics real user behavior and catches the most visible impersonators right away.
Because searches alone can miss listings that don't rank, it uses a scraping-based approach to scan structured backend listing data, like app titles, descriptions, and developer names, so nothing slips through the cracks.
Finding a match is only half the job; what happens next is what makes it usable every day. A match doesn't turn into a new asset you're forced to manage. Instead, it surfaces as a Threat Monitoring event, not a false claim of ownership or infrastructure on your side.
App Store Threat Detection exposes the impersonating app and compiles the forensic evidence behind it. Filing the official takedown request with Apple or Google remains a step your team (or process) owns.
There's also a noise problem hiding in that setup, and Breach Risk handles it before it reaches you. Your official apps could match another brand-name search just as easily as an impersonator does, so Breach Risk identifies and auto-dismisses those. Everything else surfaces as a Threat Monitoring event flagged for brand impersonation, which your analysts can work through.
This brings us back to Craig Raw. He did everything right: spotting the fake app, warning users, and reporting it repeatedly. None of it was enough to get it removed before more people lost money. A public warning reaches the people who see it, but it doesn't watch app stores for you the next day or the one after.
That's the ongoing watch. App Store Threat Detection provides continuous monitoring of both platforms, so unauthorized apps carrying your name surface as an event before your team has to go looking for them. If your brand is worth impersonating, it's worth watching in the app stores too.
Ready to see it in action? Request a demo of Breach Risk or start a free trial to see what's currently listed under your brand's name.