The Binary Doesn't Lie

You change the app icon. You swap the name. You register a fresh developer account under a spouse's email, and you resubmit the exact same code that got rejected last month. Clean slate, right?

It isn't.

App stores, specifically Apple's App Store and Google Play, have spent years building detection systems that treat the compiled binary as a fingerprint, not just a file. The name on the tin is almost irrelevant. What's inside it looks the same no matter how many times you repaint the outside, and the stores know it.

So how, mechanically, does the detection actually work?

The Code Fingerprint, Explained

When a developer submits an iOS app, Xcode compiles their Swift or Objective-C into a Mach-O binary. For Android, Gradle produces a DEX bytecode package. Both are structured, inspectable artifacts. Not scrambled. They contain class names, method signatures, resource hashes, and dependency trees, and those structures are remarkably stable across superficial repackaging.

Apple and Google both run static analysis on every submission. Think of it like running a perceptual hash on a photograph: you can crop it, adjust the brightness, slap a new border on it, and the hash still lands close enough to the original to flag a match. Rename your main view controller from `HomeViewController` to `MainViewController` and resubmit? The method call graph, the resource bundle checksums, the third-party SDK signatures underneath it all stay nearly identical. The hash moves a few points. It does not escape the threshold.

Google Play uses a technique called APK similarity scoring, comparing structural features of new submissions against a corpus of previously rejected or removed apps. Two APKs sharing the same third-party libraries, the same asset folder structure, and the same permission manifest will score high on similarity even if the package name and display name are completely different.

Apple's review pipeline adds human-assisted machine review on top of that. Automated flags get surfaced to reviewers who can pull both binaries and diff them side by side, in something that works a lot like a code-diff interface. A reviewer who rejected your app for a hidden web-view monetisation scheme will see that your new submission is structurally identical to the one they knocked back three weeks ago.

Developer Identity Is Harder to Fake Than You Think

The binary matching is only part of it. The identity graph is the other half, and it is surprisingly sticky.

Apple ties every developer account to a DUNS number for organisations, or to Apple ID credentials and payment methods for individuals. Two accounts sharing a payment card, a device (identified by the hardware UUID of the Mac used to upload), or an IP address cluster get linked in Apple's internal graph. The new-account trick that might fool a human reviewer does not fool a relational database that has been watching submission metadata for years.

Google Play leans heavily on the developer signing certificate. Every Android app must be signed with a private key, and Google stores the public certificate fingerprint. Sign a repackaged app with the same key as the original and the match is instant, unambiguous, over. Generate a fresh key and the certificate fingerprint is new, but the code-similarity scoring picks up the slack.

Then there is behavioural metadata: device fingerprints from the upload client, browser fingerprints from the developer console, geolocation from login sessions. A developer in Warsaw who gets banned and reappears forty-eight hours later, same city, same ISP, submitting an app with 94% structural similarity to the rejected one, is not invisible to these systems.

What Usually Trips Up the Clever Attempts

Consider a plausible scenario. A developer, call him Marcus, builds a VPN app that gets removed from Google Play for violating data safety policies. He hands the codebase to a friend, call her Selin, who registers a fresh Play Console account, changes the app name and icon, swaps the package name from `com.marcus.vpn` to `com.selin.securevpn`, and resubmits.

Selin's account is clean. The package name is new. The icon is different.

But the underlying VPN library, a third-party SDK with a distinctive binary signature, is still there. The permission manifest still requests `BIND_VPN_SERVICE` plus the same cluster of network permissions. The asset folder still contains the same server configuration files, same byte-for-byte checksums. Google's automated system flags the submission at a 91% similarity score to Marcus's removed app. A reviewer pulls both records. Selin's account is terminated within a week, and Marcus's original removal is noted as a circumvention attempt.

The part that surprises most people: even a 30% code rewrite might not clear the threshold. Similarity scoring is calibrated conservatively, because the stores would rather over-flag than let ban-evaders through. That is not a neutral design choice, it is the right one.

What People Misread About This Process

The common assumption is that obfuscation tools defeat binary matching. ProGuard and R8 on Android rename classes and methods to single-letter identifiers, which sounds like it would scramble the fingerprint entirely.

It doesn't, quite.

Obfuscation changes symbol names but not the structural shape of the code: the call graph topology, the control flow patterns, the ratio of methods to classes, the sizes of compiled methods. Academic research has shown that obfuscated Android apps can be re-identified with accuracy above 80% using graph-based features alone, even when symbol names are fully stripped. The stores have access to far more features than any published paper typically uses.

Using obfuscation to sneak a rejected app past review is roughly as effective as changing your hat before walking past a security camera that already has your face on file.

So ask yourself: if the structural shape of the code survives stripping, renaming, and repackaging, what exactly is the cosmetic makeover hiding from?

There is one genuine caveat worth stating clearly: these systems are not perfect and false positives happen. A developer building two legitimately different apps on the same popular SDK stack might get flagged for similarity to someone else's removed app. The appeals process at both stores is famously opaque, which is a real problem. Detection accuracy and appeals fairness are two entirely separate questions, and the second one has a much less satisfying answer.

But for anyone wondering whether a fresh coat of paint fools the scanner: it doesn't. The binary remembers everything.