> ## 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.

# Technical readiness

> The checklist for whether an app can run a Recurr pilot without adding migration work to the product roadmap.

Recurr is designed for apps that already have the basic subscription infrastructure needed to support web billing alongside app-store billing.

## Required for a pilot

<CardGroup cols={2}>
  <Card title="Central entitlement source" icon="cube">
    RevenueCat, Adapty, or a custom backend that can read store subscription state and accept web subscription state.
  </Card>

  <Card title="Subscriber reachability" icon="envelope">
    Email or another owned contact point for the majority of subscribers in the pilot cohort. Apple private relay counts once the sending domain is registered with Apple (one-time setup, see below).
  </Card>

  <Card title="Stripe readiness" icon="credit-card">
    An existing Stripe account or a finance owner who can complete Stripe Connect onboarding.
  </Card>

  <Card title="DNS access" icon="globe">
    Ability to add a CNAME for branded checkout, such as `subscribe.yourdomain.com`.
  </Card>

  <Card title="Analytics access" icon="chart-bar">
    Subscriber-level fields for cohorting: plan, tenure, renewal date, geo, engagement, and lifecycle state where available.
  </Card>

  <Card title="Support owner" icon="headset">
    A named owner for migration-related subscriber questions during pilot waves.
  </Card>
</CardGroup>

## Sign in with Apple setup

For apps with subscribers who use Sign in with Apple, two one-time configurations are required to support web subscription flows. Both live in your Apple Developer Account and your DNS, similar in concept to Apple Pay domain verification.

### Web sign-in configuration

So a migrated or new subscriber can authenticate with Apple on your web checkout:

* Create a Services ID for your subscribe domain (e.g. `subscribe.yourdomain.com`) under **Identifiers** in your Apple Developer Account.
* Configure the return URLs Apple will redirect to after authentication.
* Verify domain ownership by hosting the file Apple provides at `/.well-known/apple-developer-domain-association.txt`.

Once configured, Sign in with Apple works on your web subscribe surface — same Apple ID, same identity, no re-prompt to create an account. See [Apple's documentation](https://developer.apple.com/documentation/signinwithapple/configuring-your-webpage-for-sign-in-with-apple) for the full developer-portal flow.

### Email forwarding registration

So emails from your sending domain forward through Apple's private relay to the subscriber's real inbox:

* Register your sending domain (e.g. `mail.yourdomain.com`) under **Services → Sign in with Apple for Email Communication** in your Apple Developer Account.
* Add the SPF DNS TXT record Apple provides to your DNS provider.
* Confirm verification in the Developer portal.

Once registered, emails sent from your verified domain to `*@privaterelay.appleid.com` addresses forward to the subscriber's real Apple ID email. Without this setup, Apple bounces or quarantines the message. See [Apple's documentation](https://developer.apple.com/documentation/signinwithapple/communicating-using-the-private-email-relay-service) for the full developer-portal flow.

Both steps run as part of Recurr's onboarding — your team provides DNS access and Apple Developer Account access; Recurr handles the configuration.

**Apple Pay is separate.** It's enabled via Stripe Connect during the payments setup phase, not through your Apple Developer Account. Stripe registers the Apple Pay merchant identity for you; your team hosts the domain association file Stripe provides at `/.well-known/apple-developer-merchantid-domain-association` on your subscribe domain. Recurr handles deployment as part of the checkout setup.

## Not a current fit

StoreKit-only apps with no centralized entitlement source are not a current fit for Recurr.

Recurr can integrate with RevenueCat, Adapty, or a custom backend. It does not currently add a new mobile SDK or replace a StoreKit-only entitlement architecture. That may become a future platform direction, but it is not part of the current migration offer.

## Expected engineering load

For apps that meet the readiness profile:

* Initial integration is typically **2-4 engineering hours**.
* Active migration review is typically **1-2 hours per week**.
* No app release is required.
* No migration build goes onto the product roadmap.

The Migration Review is where edge cases get surfaced: custom auth, anonymous subscriptions, unusual entitlement flows, multiple Stripe accounts, or pending store-review work.

[What you actually integrate](/integration/no-sdk) covers the integration surface in detail.