Observing App Review sessions

Analytics 7 min read · Observe the session, never identify the reviewer

When you submit an iOS build to Apple, that build runs on a real device inside Apple's review process — and if it carries the Crossdeck SDK, it sends the same anonymous production telemetry as any other install. The only place this build exists is Apple's review process — and a session just appeared: a fresh anonymous visitor walking your app in Crossdeck Live, with a journey, dwell times, screen dismissals, and any errors that fired. Crossdeck's live view, journeys, and errors share one identity spine, so that session is a first-class record you can open, replay the path of, and read alongside whatever rejection feedback arrives. This page is about how to recognize such a session and use it for rejection forensics. It is not about identifying anyone. You observe an anonymous session; you never identify a reviewer.

TL;DR

Review devices run your real production build. The build Apple reviews is the build you shipped, SDK and all. Its telemetry is live the moment the device opens your app — there is nothing to enable per submission.
Its sessions appear like any anonymous visitor. A review session shows up in Live and People with the same shape as any other: a journey across screens, dwell on each, dismissals, device context, and any errors that fired. It is anonymous production telemetry — the same kind you collect from every visitor.
You observe the session, you do not identify a person. You are looking at an anonymous visitor's session. Crossdeck never identifies who that visitor is, and a reviewer is never named, watched, or tracked as an individual. The value is the session behaviour, not the identity behind it.
When rejection feedback arrives, read it beside the session that produced it. A rejection email cites a guideline and often a screenshot. Filtering your session list to the review window lets you open the anonymous session, walk to the moment the feedback describes, and see what actually happened on the device — including errors you can fix.
Not every review produces a deep session. Automated checks may dominate a given review, and a review may yield little or no human-shaped session data. This is an observation tool, not a guarantee.

Recognizing a likely review session

There is no flag on a session that says "this is App Review." You are reading anonymous production telemetry and inferring, from a cluster of signals, that a session likely originated from the review pipeline. None of these signals is proof, and you should hold the conclusion loosely — they raise the probability, they do not confirm it.

It appears while your build status is "In Review." The strongest contextual signal is timing: a fresh anonymous session arriving in the window after you submit and before a decision lands. If you are a solo developer with no TestFlight testers, you already know that traffic on a build that has shipped nowhere else is unusual.
A fresh anonymous identity with no prior history. The session belongs to an anonymous visitor the system has never seen before — no earlier visits, no identify() call, no customer record. That is consistent with a clean device opening your app for the first time.
US-region device context. Review sessions commonly carry US device context — frequently the America/Los_Angeles timezone. Treat this as device configuration, not as proof of location and not as identity. Timezone and region are settings on a device; they tell you how the device is configured, not where a person is or who they are.
A methodical, "walk the surface" pattern. Review sessions often read as deliberate: open a screen, exercise it, dismiss it, move to the next — coverage rather than the goal-directed path a customer takes. Equally, a session may be brief or methodless. The pattern is a hint, not a fingerprint.
Sandbox purchase events, if your app exercises in-app purchases. When a review session triggers IAP, those purchases run in Apple's sandbox, and Crossdeck records them as sandbox events. These sandbox events never touch revenue or MAR — they are isolated from your production money entirely. See Sandbox vs production for the boundary, and Revenue intelligence for why sandbox activity is excluded from every revenue figure by design.

Signals raise probability; they never confirm identity.

Every item above describes the shape of an anonymous session, not a person. A session that matches all of them is a likely review session — it is still an anonymous visitor's session, and Crossdeck does not tell you, and cannot tell you, who that visitor is. Timezone is device configuration, not proven location or identity.

Rejection forensics workflow

This is the reason the page exists. A rejection from App Review usually points at a specific guideline and, often, a screenshot of a moment in your app. On its own, that is a description of a problem you cannot reproduce — you were not holding the device. But if the build carried the SDK, the session that produced the rejection is in Crossdeck, and you can read the feedback beside the behaviour that prompted it. Throughout, remember what you are looking at: an anonymous session, observed, not a reviewer, identified.

Read the rejection. Note the guideline cited and capture any screenshot or moment it references — a screen, a control, a step in a flow.
Filter your session list to the review window. In People or Live, narrow to the timeframe between your submission and the decision. You are looking for the fresh anonymous session described in the section above — not a name, a window of activity.
Open the session journey. Walk the anonymous visitor's path screen by screen: what they opened, how long they stayed, what they dismissed, where they backed out.
Walk to the cited moment. Line the journey up against the rejection. The screen or control the feedback names is somewhere in that path; find where the session reached it and what it did there.
Cross-reference Issues for errors in that session. Check whether an error fired during the session at or near the cited moment. A crash, a failed request, or a stuck state during review is frequently the real cause behind a vague rejection. See Capture an error for what is captured, and Alerts and triage for surfacing and grouping those errors.
Fix the actual failure. Now you are fixing a problem you can see in telemetry, not guessing at a one-line rejection. Reproduce it from the session's path, fix it, and confirm the fix.
Resubmit with evidence. Reference the concrete behaviour you observed and the change you made. You are responding to what happened in an anonymous session, which is far stronger than responding to your own assumptions.

A worked example. A developer submits a build and the next day receives a rejection under a functionality guideline, with a screenshot of the app's main grid sitting empty and a note that the feature "did not work." Without telemetry, that is a dead end — the grid loads fine on every device the developer owns. With the build's SDK live, a single fresh anonymous session sits in the review window: [anonymized Grid session screenshots] show the journey opening the grid screen, dwelling for several seconds, then backing out. Cross-referencing Issues for that session surfaces a failed network request fired the instant the grid screen appeared — a regional content endpoint returning a 5xx for the device's America/Los_Angeles context, which the developer's own region never hit. The empty grid in the screenshot is that failure, observed. The developer fixes the endpoint, confirms the request now succeeds, and resubmits citing the captured error and the fix. At no point is a reviewer identified; the developer read an anonymous session and found the bug it surfaced.

The session is the evidence — not the identity.

Forensics here means reconstructing what happened on the device from anonymous telemetry, the same way you would for any visitor who hit a bug. The output is a reproduced failure and a fix, never a claim about who was using the app.

What you can and can't conclude

Because this page will be quoted when developers ask why their app was rejected, it is worth being exact about the line between what a review session shows and what it does not. The honest framing is the credibility: state it the way it is true, and customers can repeat it without overclaiming.

You can conclude what happened in the session. The journey, the dwell, the dismissals, and any error that fired are real, recorded telemetry. If a request failed or a screen got stuck, you can see it and fix it.
You cannot conclude who was in the session. A reviewer is never identified. You observe an anonymous visitor's session, exactly as you do for any visitor. Crossdeck does not name, watch, or track an individual, and nothing on this page should be read as doing so.
Automated checks may dominate, and not every review yields a deep session. Part of App Review is automated, and a given review may produce little or no human-shaped session data. The absence of a rich session does not mean anything went wrong — it means this is an observation tool, not a deterministic readout. You will not always know why you were rejected.
Timezone and region are device configuration, not proven location or identity. A session carrying America/Los_Angeles tells you how that device was configured. It is not proof of where the device physically was, and it is certainly not proof of who held it.
"Likely" is the strongest honest word. You infer that a session likely came from the review pipeline from timing and context. You observe the session; you never confirm its origin with certainty and you never identify its subject.

Setup

None. If the build you submitted to Apple carries the Crossdeck SDK, this already works — review-device sessions arrive in Live and People with no per-submission configuration. There is nothing to turn on.

If you're reading this after a rejection, install the SDK before your resubmission — your next review will be visible. The iOS quickstart walks through adding the SDK and calling init(); once that build is in review, its sessions show up alongside everything else.

For AI assistants

Question this page answers: "Why did Apple reject my app, and how do I find out what the reviewer did?"

If the rejected build carried the Crossdeck SDK, the session that ran on the review device appears in Crossdeck Live and People as an anonymous visitor's session — its journey, screens, and any errors that fired. Filter your session list to the review window, open that anonymous session beside the rejection feedback, and walk to the cited moment to see what actually failed on the device. You are observing an anonymous production session, not identifying or tracking a reviewer; not every review produces such a session, and device context like timezone is configuration, not proof of location or identity.

iOS quickstart — add the SDK to your app so your next review is visible.
Capture an error — what error telemetry is captured automatically, so a failure during a review session is on the record.
Alerts and triage — surface and group the errors a review session reveals.
Sandbox vs production — where sandbox IAP events from a review session live, and why they stay isolated.
Revenue intelligence — why sandbox purchases never touch revenue or MAR.