Do you need RevenueCat for Apple Retention Messaging?
No. Apple Retention Messaging is a server-to-server cancellation-time API. You can configure messages, promotional offers, realtime URLs, sandbox performance tests, and production runtime behavior without migrating purchases, entitlements, subscribers, or analytics to a full subscription platform.
You can use both. If RevenueCat already powers your purchases and entitlements, keep it. RetainKit operates the Apple Retention Messaging layer beside it — no subscription migration, no SDK swap. RevenueCat stays your subscription system; RetainKit handles Apple cancellation-time retention.
RevenueCat is great for full subscription infrastructure: SDK integration, entitlement management, purchase flows, customer status, experiments across broader paywall journeys, analytics, and lifecycle events. RetainKit is purpose-built for Apple's cancellation-time retention API.
They operate at different layers
RevenueCat commonly sits in the app and backend path for purchases and entitlements. That is a broad role. Apple Retention Messaging sits inside Apple's cancellation flow, after the subscription already exists, when Apple decides whether to ask your server for a retention response.
For this specific API, the operational work is narrower:
- Request Apple Retention Messaging access.
- Sync App Store Connect apps, products, subscription groups, messages, and promotional offers.
- Upload and track Retention Messaging message review states.
- Configure sandbox and production realtime URLs.
- Run the sandbox performance test.
- Publish deterministic retention flows and roll them back safely.
- Observe realtime decisions and latency.
RetainKit vs RevenueCat for this API
| Question | RetainKit | RevenueCat |
|---|---|---|
| Primary job | Operate Apple Retention Messaging: messages, offers, realtime URL, tests, rules, logs, rollback. | Operate broad subscription infrastructure: SDKs, purchases, entitlements, analytics, paywalls, lifecycle data. |
| Need to migrate subscription infrastructure? | No. RetainKit works on top of App Store Connect and Apple Retention Messaging. | Usually yes if you want RevenueCat to become the source of truth for entitlements and purchases. |
| Need an SDK? | No SDK is required for the Apple realtime callback. | RevenueCat's normal integration model uses client SDKs. |
| Need an app release? | No app release when using RetainKit-hosted runtime and existing App Store Connect products. | Usually required when adding or changing SDK-level subscription infrastructure. |
| Realtime URL hosting | Purpose-built hosted endpoint for Apple Retention Messaging, with optional self-hosted runtime export. | Not the same as a dedicated Apple Retention Messaging control plane. |
| Promotional offer signing | Signs Apple retention offers at cancellation time with StoreKit/In-App Purchase key material. | RevenueCat may manage broader promotional offer workflows, but this API still needs correct Apple retention response handling. |
| Best fit | Teams that want to add cancellation-time retention without subscription migration. | Teams that want a full subscription platform across app, backend, purchases, entitlements, and analytics. |
You can use both
If RevenueCat already powers purchases and entitlements, you do not need to undo that. Keep it. RetainKit can operate the Apple Retention Messaging layer beside it. The realtime request from Apple contains the transaction and product context needed for retention routing, and RetainKit can return an approved message, signed promotional offer, or alternate product without owning your entire subscription stack.
The clean boundary is simple: RevenueCat remains the subscription infrastructure layer. RetainKit handles Apple cancellation-time retention operations.
No SDK, no app release, no entitlement migration
This is the practical wedge. Apple Retention Messaging can be added operationally because the callback is server-to-server. You still need Apple access, App Store Connect keys, messages, offers, realtime URL configuration, and sandbox testing. But you do not need to migrate subscriber state or ship a new app build just to respond to Apple's cancellation-time request.
Existing app + existing App Store subscriptions
-> request Apple Retention Messaging access
-> configure RetainKit hosted realtime URL
-> publish retention flows
-> Apple calls RetainKit during cancellation