Skip to main content
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

Central entitlement source

RevenueCat, Adapty, or a custom backend that can read store subscription state and accept web subscription state.

Subscriber reachability

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

Stripe readiness

An existing Stripe account or a finance owner who can complete Stripe Connect onboarding.

DNS access

Ability to add a CNAME for branded checkout, such as subscribe.yourdomain.com.

Analytics access

Subscriber-level fields for cohorting: plan, tenure, renewal date, geo, engagement, and lifecycle state where available.

Support owner

A named owner for migration-related subscriber questions during pilot waves.

​
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 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 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 covers the integration surface in detail.