You download an app, find it clunky, and wonder how it ever got approved. Somewhere a reviewer saw something you didn't.
Not a different version. The same code, reading the room.
This is a well-documented pattern in mobile development, with a long history and a few genuinely clever mechanics underneath it. It's also, depending on what a developer does with it, either reasonable engineering or straightforward fraud.
The signals an app can read
When Apple or Google sends a reviewer to evaluate a submitted app, that reviewer operates from a specific environment: a particular device, a particular network, a particular account type. Apps, if their developers choose, can read every one of those signals.
The most common detection method runs through Apple's StoreKit framework, which exposes a property called `isSandboxReceipt`. It tells an app whether its purchase receipts are coming from the test environment rather than the live store. A reviewer's device always runs in that sandbox. So a developer who checks that flag knows, with reasonable confidence, that the current user is probably not a paying customer who stumbled in organically.
Geolocation is another lever. Apple's review team operates primarily out of Cupertino, California, and a developer who hard-codes a check for that IP range gets a crude but functional detector. Crude because VPNs exist. Functional because most reviewers don't bother using one.
Account age matters too. A fresh Apple ID that's never purchased anything, running a brand-new install, looks nothing like a two-year-old account with a purchase history and saved preferences. Apps with enough instrumentation can score that difference and act on it, quietly, before you've tapped anything.
Put those signals together and you have a fairly reliable fingerprint for "this is a review session."
What changes when the app thinks it's being watched
The practice ranges from defensible to genuinely deceptive, and the line is sharper than most coverage suggests.
At the defensible end: some apps suppress aggressive monetization during review. A game that would normally demand a rating after thirty seconds of play, or push a subscription upsell before the first level loads, might hide those flows entirely when it suspects a reviewer. The argument holds up. Those prompts are designed for real users; surfacing them to someone speed-running the onboarding just creates friction that obscures the actual product.
At the other end sits behavior that is, plainly, deception. Apps have been caught hiding the exact features that triggered policy violations. An app flagged for adult content would detect the review environment and swap in clean images. The reviewer saw nothing wrong. Real users got the original experience. Apple and Google have both caught and removed apps for this, though detection is genuinely hard, because the reviewers are, by design, seeing a different product than everyone else.
Then there's the grey zone, which is where most of the interesting cases live. Consider two developers who built near-identical social apps. One, call her Priya, ships with review detection that pre-loads a demo feed of pleasant, populated content so the app doesn't look like a ghost town to a reviewer. The other, call him Tom, ships without it. His app gets rejected because reviewers see an empty state with broken placeholder text. Same product quality, different outcomes. Whether Priya's approach is smart engineering or gaming the system is not a question with a clean answer, and anyone who tells you otherwise is selling something.
What people misread about this
The reflexive assumption is that review detection is inherently shady. It isn't, not automatically. The shadiness lives entirely in what the app does differently once it thinks no one real is watching.
Showing a reviewer a stable, populated demo environment is not unlike a restaurant doing a soft launch for critics before opening to the public. Hiding a functional defect or a policy violation from the reviewer while exposing it to real users is fraud. Full stop. Those are not the same category of behavior, and treating them as equivalent does nobody any favors.
The harder structural problem is that platform reviewers are time-limited in ways that determined developers are not. They spend minutes, not hours, with each app. They can't convincingly mimic long-term users. They can't easily mask their network signatures. They're reviewing thousands of apps a week, which makes the whole process less like a audit and more like airport security: mostly a performance of thoroughness, occasionally catching something real.
Both Apple and Google have responded by adding post-publication monitoring, automated scanning, and user-report pipelines. The review moment is no longer the only checkpoint, which matters.
But the incentive to perform for the reviewer remains, baked into the economics of the approval gate itself. As long as a single gatekeeper moment determines whether your app lives or dies, developers will study the lock before they build the key.
The app you downloaded has already passed its audition. What you're running now is the performance that came after.