Skip to main content
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 → Google Play compliance →

​
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 → Run the audit