Skip to main content

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.

The most common question from CTOs and legal reviewers is: “is this allowed?” Yes, with specifics. The framework is designed to keep migration outreach and checkout outside the app binary.
Last reviewed: May 2026. Apple policies can change; Recurr reviews policy posture before each migration wave. This page is operational guidance, not legal advice.

Relevant Apple guideline shape

Apple’s App Store Review Guidelines separate two ideas that both matter here:
  • Out-of-app communication: Apple’s 3.1.3 section allows developers to send communications outside the app to their user base about purchase methods other than in-app purchase.
  • Multiplatform services: 3.1.3(b) allows apps that operate across multiple platforms to let users access subscriptions or features acquired on other platforms or the developer’s website.
Recurr’s default migration posture uses the conservative lane: email and owned channels reach the subscriber; the app binary is untouched; the app continues granting access through the existing entitlement system. Official source: Apple App Review Guidelines

What stays outside the app

The migration is reachable only via:
  • Email as the primary channel
  • Owned customer surfaces such as newsletter, support portal, or marketing site
  • Web checkout at the customer’s branded subdomain, such as subscribe.yourdomain.com
  • Direct support channels the customer is already using
The migration explicitly does not put any of the following in the app:
  • In-app links to web pricing
  • In-app buttons that direct to external checkout
  • In-app messaging about migration offers
  • Push notifications mentioning external subscription paths

What’s still allowed in-app

Compliance doesn’t mean the app goes dark. The migration framework can support:
  • Email collection prompts where needed, framed around account recovery rather than migration
  • Account-recovery flows that establish web identity continuity
  • Customer support that answers billing questions through existing support channels
  • Post-migration access where the user returns to the app and the entitlement check confirms the active web subscription

App release cadence

For supported apps, the framework runs without an app release. There is no SDK to install, no binary change, and no App Review submission. The app team’s roadmap stays on whatever it was; migration runs alongside the product org, not through it.

What the framework needs from you

Your role on the compliance side:
  • Don’t add in-app pointers to migration unless the framework explicitly scopes that path for a specific jurisdiction.
  • Coordinate subscription-related in-app messaging. If help screens, FAQs, or in-app emails mention billing, run the wording through the migration review.
  • Surface active App Store communication. If Apple has flagged something in App Review, it is relevant context before launch.
Google Play compliance