The Fake That Almost Looks Right

You search for your bank's app. Three results come back. Two look identical to the real one: same icon, same name, one letter off in the developer field. You tap the top result and move on. Most people do.

That gap between "looks legitimate" and "is legitimate" is exactly where cloned apps live. The systems designed to catch them are considerably more sophisticated than a human reviewer squinting at a logo.

The First Filter: Certificate Fingerprints

Every app submitted to the App Store or Google Play must be signed with a cryptographic certificate. Think of it as a wax seal on a letter, except the seal is mathematically unique to the developer who created it and cannot be forged without the private key.

When Apple or Google receives a submission, one of the first automated checks compares that certificate's fingerprint against every certificate already on file. If someone clones the Gmail app, strips out the code, reskins it, and resubmits it, their signing certificate will be different from Google's. That mismatch is logged immediately.

This doesn't catch everything. A bad actor can simply generate a fresh certificate under a new developer account. The stores know this, so the certificate check is the first layer, not the last.

Code Similarity Scoring and the 60% Problem

Beyond the certificate, both major platforms run automated static analysis on the app binary itself. The system decompiles the code into an intermediate representation and runs it through similarity-scoring algorithms, comparing it against a database of known legitimate apps.

The threshold that triggers a manual review sits somewhere around 60% structural similarity to a popular app from a different developer. That figure isn't public, but security researchers who've reverse-engineered rejection patterns put it in that ballpark. Reach that score and a human reviewer gets flagged.

Here's how it plays out in practice. Imagine someone clones a popular navigation app called RouteRunner. They keep the core routing logic (the expensive part to rebuild), swap the UI colours, rename the classes, and add a thin layer of ad-tracking code on top. Static analysis strips away the cosmetic differences and compares the function call graph, the string patterns, the permission requests. The skeleton underneath still looks like RouteRunner. The similarity score climbs past the threshold. The submission gets held.

Clone makers have adapted. Badly. The current generation doesn't copy code wholesale; they rebuild the functionality from scratch using the original app as a blueprint, which drops the similarity score dramatically. Which is why the certificate check and code analysis alone aren't sufficient.

Behaviour Sandboxing: Running the App in Captivity

The most revealing test happens at runtime. Both platforms run submitted apps inside isolated sandboxes before they ever reach a user's device. The sandbox monitors what the app actually does: what network calls it makes, what permissions it quietly requests, what it writes to disk, whether it tries to contact any known malicious command-and-control servers.

A cloned banking app might pass static analysis because it was rebuilt from scratch. But when it runs in the sandbox, it sends login credentials to an external server with no affiliation with the bank. That outbound call to a flagged IP range is the tell. It's a bit like a burglar who builds their own lockpick from scratch but still knocks on the same fence post to signal the getaway driver.

Google's Play Protect system extends this beyond the submission stage. It continues monitoring app behaviour after installation, on actual devices, and can retroactively remove an app that starts behaving badly after a quiet update slips through. Apple's approach is tighter at the gate, with more restrictive sandboxing built into iOS itself, which limits what a bad app can do even if it gets through.

What People Consistently Misread About This

The assumption most users carry is that app store review is primarily a human process. It isn't. Human review is the exception, triggered by automated systems. The vast majority of apps are cleared or rejected without a person ever opening them.

The second misread concerns the developer account layer. Both stores require a paid developer account tied to a real identity and payment method. This creates a paper trail. When a cloned app does get through and is later reported, the stores can trace the account, ban it, and use the associated metadata to flag any future accounts created with the same identity. The deterrent is imperfect but real.

And then there's the comfortable myth that clone detection is a solved problem. It isn't. Sophisticated clones that rebuild functionality from scratch, use fresh certificates, and behave cleanly in sandboxes (only activating malicious behaviour after a delay or after a specific user action) can slip through. The stores catch the vast majority. The remainder surface through user reports and third-party security research.

Two Users, One Outcome

Take two people who downloaded what looked like the same password manager around the same time. One downloaded the real app: version 4.2, signed by the legitimate developer, 4.8 stars, 2 million reviews. The other found a version called "Password Manager Pro" with a near-identical icon, 847 reviews (many of them suspiciously similar in phrasing), signed by a developer registered three weeks earlier.

The second app passed static analysis because it was genuinely rebuilt. It passed the sandbox because it behaved perfectly for the first 72 hours. It failed when a user in Brazil reported that her stored passwords had been exfiltrated. Google pulled it within six hours of the first credible report. By then, roughly 4,000 installs had happened.

That's the honest arithmetic of the system. Fast, mostly accurate, occasionally costly.

The Crust That Keeps Building

The stores are in a permanent arms race with clone makers, and the tools get sharper on both sides. Metadata analysis now factors in review velocity (a thousand five-star reviews in 48 hours is a red flag), developer history, geographic clustering of downloads, and even the visual similarity of icon assets run through image-recognition models.

None of it is foolproof. And that raises a question that doesn't have a clean answer: if the automated systems are this sophisticated, why do clones still get through at scale? Because the attackers are optimising against the exact same published research the defenders are using. The playbook is public. The threshold scores, the sandbox evasion windows, the review-velocity flags: all of it has been documented, tested, and worked around.

The best defence a user has is still the same one it's always been. Check the developer name carefully, not just the app name. A five-second look at who actually published the app catches most clones that the automated systems miss.

The stores are very good at finding obvious fakes. Patient, well-resourced ones are a different problem entirely, and treating app store approval as a guarantee of safety is exactly the kind of assumption that makes the patient ones so effective.