> ## 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. # Apple - App Store guidelines and out-of-app comms > How Recurr keeps migration outside the app binary and aligned with Apple's current out-of-app communication rules. 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. 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.** [Guideline 3.1.3](https://developer.apple.com/app-store/review/guidelines/#3.1.3) permits out-of-app email about web pricing. This is not interpretation — it is Apple's own clarification, made in the *Cameron v. Apple* developer settlement (August 2021). * **Multiplatform services.** 3.1.3(b) qualifies that for multiplatform services: signed-in users may access content acquired elsewhere, including on the developer's website. Apple's exact words from that settlement: > To give developers even more flexibility to reach their customers, Apple is also clarifying that developers can use communications, such as email, to share information about payment methods outside of their iOS app. As always, developers will not pay Apple a commission on any purchases taking place outside of their app or the App Store. Users must consent to the communication and have the right to opt out. The 2025 *Epic v. Apple* ruling went further still — US apps may now link to external checkout in-app, commission-free — but Recurr's migration does not rely on it. Migration runs on the conservative out-of-app email lane Apple sanctioned in 2021: **email and owned channels reach the subscriber; the app binary is untouched; the app continues granting access through the existing entitlement system.** ## 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 The framework runs without an app release. No SDK to install, no binary change, 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.** The framework operates outside the app binary by design — keep it that way. * **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](/compliance/google-play)