> ## Documentation Index > Fetch the complete documentation index at: https://recurr.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Anonymous + Apple Sign In subscribers > How the migration handles subscribers without a deliverable email — Apple Sign In private relay, Google anonymous flow, and the in-app email-collection prompt for the small residual. The single biggest reachability question on a migration: **can you actually email your subscribers?** For most subscriber cohorts the answer is straightforward yes. The cases that need attention are subscribers who signed up anonymously or through a flow that obscures their email. This page covers what happens in each case. ## Apple Sign In + private relay — works by default Apple Sign In subscribers using **private relay** (`@privaterelay.appleid.com` addresses) are reachable. The relay forwards email to the subscriber's real Apple ID inbox; deliverability and engagement track normal email rates. Concretely: * The migration email lands in the subscriber's inbox via the relay forward * Click-through to checkout works normally * The web subscription can be created against the relay address as the canonical contact email — Recurr stores the relay address, not the underlying real address (which Apple doesn't expose) * If the subscriber later disables relay or changes Apple ID settings, Recurr's email-deliverability monitoring flags the new bounce rate; the subscriber is moved to the "needs in-app prompt" bucket below Private relay isn't a reachability blocker. The framework treats it as a regular email channel with one extra delivery hop. ## Google Sign In — works by default Google Sign In subscribers provide a real Gmail-resolved address (Google doesn't run a relay equivalent). Email reaches them directly; no special handling needed. ## Anonymous or no-auth subscribers — the residual case A smaller cohort: subscribers who subscribed without any account at all, or with an obscured / one-time-use email (some apps allow this for low-friction onboarding). These subscribers don't have a reachable email on file at all, so the migration email has nowhere to go. For this cohort, the framework uses an **in-app email-collection prompt** — the only in-app surface the migration touches. ### When the prompt fires The prompt is scoped narrowly: * **Cohort gate** — only fires for subscribers identified as having no deliverable email on file (validated against bounce rate + email-verification signal) * **Pre-wave** — fires during the wave window the cohort is scheduled for, not earlier (so the prompt isn't sitting in the app indefinitely) * **Once per subscriber** — dismissed or completed, doesn't re-fire on the same app session ### The prompt UX Framed around **account recovery**, not migration. Subscribers see a one-screen prompt asking for an email so they can: * Recover access if they lose their device * Receive subscription receipts * Manage their subscription outside the app The prompt doesn't mention migration, doesn't link to web pricing, and doesn't reference external billing. Out-of-app communication is gated to email channels Recurr operates outside the app. ### What the framework does with the collected email Once an email is captured, the subscriber moves from the "no deliverable email" bucket into the regular migration cohort: 1. Email is added to the tenant database + flagged as "account-recovery captured" 2. The subscriber is included in the next available wave matching their other cohort axes 3. The migration email lands like any other subscriber's The collection-to-migration window is typically 2–4 weeks — long enough for the recovery framing to feel separate from the migration ask, short enough that the cohort doesn't get stranded. ### Why this is the only in-app surface Recurr operates outside the app binary by design. The email-collection prompt is the single exception, scoped narrowly because there's no other way to reach an anonymous subscriber. The prompt's content is framed around account recovery — a legitimate subscriber benefit that holds independent of whether migration is later offered — so the in-app surface is compliant with Apple's and Google's policies on out-of-app communication. [Apple compliance →](/compliance/apple) [Google Play compliance →](/compliance/google-play) ## Family plans, child accounts, shared payment methods Adjacent reachability questions worth flagging: * **Family-plan members** — the family organiser typically pays for the subscription and is the reachable party. Member-level accounts inherit access; migration of the organiser's payment cascades to the members' access without per-member outreach * **Child accounts (Apple Family Sharing children, Google supervised accounts)** — same as family-plan members; reach the paying parent, not the child * **Shared payment methods (multiple subscribers, same card)** — rare in the ICP but flagged during cohort sizing. Each subscriber gets their own email; payment-method overlap is handled at the Stripe Connect customer level ## What the Migration Review covers on this If your app has a meaningful anonymous or Apple-Sign-In-heavy cohort, the Migration Review walks the exact numbers for your subscriber base: how many fall into each reachability bucket, what the per-bucket conversion expectation is, and how the in-app prompt cohort interacts with the wave sequencing. [Identity continuity →](/integration/identity-continuity) [Run the audit](https://recurr.dev/audit)