The black box blinks: seeing App Review happen in your own data

You hit Submit for Review in App Store Connect, and then nothing. No timestamp. No “a reviewer opened your build”. No hint of who is tapping through the flow you spent a quarter building. You refresh the status page and wait, somewhere between In Review and quiet dread.

Here is the thing we noticed while building analytics that join identity to geography to per-build events: a review session is not actually invisible. It has a shape. Once your data can see who did what, from where, on which build, that shape stops hiding in the noise.

How long does App Store review take?

Most submissions clear review within a day or two, and Apple has publicly said the large majority are reviewed within twenty-four hours. But “usually fast” is cold comfort at 2am before a launch. The number that actually calms you down is not an average — it is a reviewer is testing my build right now. Averages describe a population; you have one submission, and you want to know about that one.

The gap between “the median is twenty-four hours” and “mine started forty minutes ago” is the entire problem. One is a statistic. The other is a fact about your app.

Can you tell when Apple is reviewing your app?

Not from App Store Connect directly — it reports state transitions, not activity. But if your analytics already capture sessions with enough resolution, a review session tends to stand out because three signals line up at once:

• A fresh install of the exact build you just submitted. Reviewers test the binary you uploaded, on a clean install, not an upgrade carrying old state. A brand-new session on a build number with zero real-world install base is a strong tell.
• An Apple-attributable network or location. App Review runs from identifiable Apple infrastructure and geography. When your session data derives coarse location and network from IP, traffic originating there rather than from your actual user base is distinctive.
• Timing that clusters right after submission. A session matching the two signals above, appearing in the window immediately following your submission, is far more likely to be a reviewer than a user who somehow found an unreleased build.

None of these alone is proof. Together, correlated, they form a signature — and a signature is something software can recognise.

Where does App Review happen from?

From Apple’s own infrastructure, which means it carries network and geographic characteristics that differ from where your customers live. This is exactly why the capability depends on identity-joined, geography-aware analytics. If your tooling treats every session as an anonymous pageview, a reviewer looks identical to anyone else. The moment you join identity, IP-derived geography and per-build events on the same session, an out-of-pattern origin hitting a brand-new build becomes legible.

We did not set out to build a reviewer detector. Crossdeck joins identity, geography and per-build events because that is what makes analytics honest across layers. Review-session visibility is a consequence of owning those layers, not a bolt-on trick. No single-layer analytics tool can see it, because the signal only exists at the intersection.

What does this actually let you do?

Two useful things, both defensible.

• Stop guessing that review has started. Instead of refreshing a status page, you can see the session that matches the signature and know the process is live. Anxiety replaced by a fact.
• QA the exact path a reviewer walks. Because the events are per-build and per-session, you can watch where a review session goes — which screens, which flows, where it stalls — on the real submitted binary.

That second point is the quiet win. Most review rejections come from a reviewer encountering something you never tested on the shipped build: a broken sign-in, a paywall that misfires, a permission prompt that loops. Seeing the real path closes that gap before it becomes a rejection.

The line we will not cross

This is for visibility and QA. Full stop.

It is never for showing reviewers a different app than your users get, hiding features during review, or gating behaviour because something “looks like a reviewer”. That is App Store review evasion — a well-documented dark pattern, an explicit violation of Apple’s guidelines, and grounds for removal from the store and termination of your developer account. We reject it, we will not help build it, and we would tell you the same thing in a room.

Knowing a reviewer is present should make your app more faithful to what you shipped, never less.

The honest use is symmetric: you learn that review has started, and you make sure the experience a reviewer sees is the same experience your users see — working, complete, and exactly as submitted. Detection that improves your QA is fair. Detection that changes your app’s behaviour for Apple is cheating, and cheating gets apps pulled.

What we learned

Opacity is not always a property of the system. Sometimes it is a property of your instrumentation. App Review feels like a black box partly because most analytics cannot join the layers that would light it up. Give your session data identity, geography and per-build resolution, and a review session stops being a rumour and becomes a row you can point at.

The lesson generalises beyond Apple: the things that feel unknowable in your funnel are often just unjoined. Visibility beats anxious guessing — but only when you draw a bright line around what visibility is for.