Skip to main content
Solved

Removing RC integration


Forum|alt.badge.img+3

I integrated RC when StoreKit 1 was my only other option. I do not use or plan to use any of the various RC advanced features (experiments, paywalls, etc) and am still on the RC legacy Starter plan.

I’ve looked into StoreKit2 and it does everything I need these days. I think that the analytics that ASC currently provides plus what Apple has promised in terms of new metrics this year is all I need there, too. So I am seriously considering migrating off of RC and only using StoreKit2 directly (reduces App complexity without having an intermediate layer on top of SK2, removes dependency on 3rd party, etc).

I’m having trouble finding documentation regarding this, but I’m wondering exactly what the process is… and whether this means any new transactions I handle via StoreKit2 on new versions will not go to MTR.

Existing/legacy versions of the app will of course still use RC as I can’t take back those versions out there in the wild ;)

I do not have the “Track new purchases from server-to-server notifications” setting enabled on my RC projects.

I guess my questions are:

  1. If I remove the RC SDK and use SK2 directly for new versions of my apps, will any transactions from the newly published versions no longer count towards MTR?
  2. Do I still need to leave the “App Store Server Notifications” production and sandbox server URLs pointing to RC inside the ASC settings?
  3. Assuming I don’t delete my RC projects, entitlements, or my RC account itself, will existing versions of my app with RC integration out there in the wild continue to work?
  4. Are there any other considerations I may have missed?

 

Best answer by guilherme

Hey ​@Gabriel Hauber,


Sorry to hear you are considering migrating off RevenueCat. Totally understandable that you’re looking to slim the stack now that StoreKit 2 covers your purchase needs. 
 
Let me run through each of your questions:
 
1. Will new SK2 purchases be counted in RevenueCat MTR?
 
No. Any transaction that never touches the RC SDK (and given that “Track new purchases from server‑to‑server notifications” is turned off), will be invisible to RevenueCat and therefore excluded from MTR. Renewals of subscriptions that were created through RC will still be counted, so expect MTR to taper off rather than drop to zero.
 
2. Do I need to keep the App Store Server Notification (ASSN) URL pointing at RevenueCat?
 
Yes, for as long as a live build still contains the RC SDK. That endpoint is what lets RC pick up renewals, refunds, grace‑period exits, etc., even if a user never opens the old build again. RevenueCat will ignore brand‑new SK2 purchases because the tracking switch is off (as in, no SDK to send through), so leaving the URL in place won’t inflate MTR.
 
3. Will existing RC‑integrated builds continue to work?
 
They will, provided you keep the RC project (and its API keys) active and leave ASSN pointed at RC. Customers on old versions will see no change.
 
As to things to consider/watch out for, you’ll need your own secure receipt‑validation backend (App Store Server API v2) for fraud checks, grace‑period exits, etc. and also lookout for any post‑migration Apple revenue, making sure that won’t appear in RC webhooks, integrations, or Customer Profiles. 
 
One last point to mention would be to consider data continuity by exporting your historical RevenueCat data before fully transitioning (use Scheduled Data Exports), to plan on how to handle any customer support queries about said historical purchases and also plan for subscription status checks across both systems during this transition.
 
This should get you in the state you're expecting to be using only SK2 directly.
 
Best,

View original
Did this post help you find an answer to your question?
This post has been closed for comments

2 replies

guilherme
RevenueCat Staff
Forum|alt.badge.img+6
  • RevenueCat Staff
  • 98 replies
  • Answer
  • July 23, 2025

Hey ​@Gabriel Hauber,


Sorry to hear you are considering migrating off RevenueCat. Totally understandable that you’re looking to slim the stack now that StoreKit 2 covers your purchase needs. 
 
Let me run through each of your questions:
 
1. Will new SK2 purchases be counted in RevenueCat MTR?
 
No. Any transaction that never touches the RC SDK (and given that “Track new purchases from server‑to‑server notifications” is turned off), will be invisible to RevenueCat and therefore excluded from MTR. Renewals of subscriptions that were created through RC will still be counted, so expect MTR to taper off rather than drop to zero.
 
2. Do I need to keep the App Store Server Notification (ASSN) URL pointing at RevenueCat?
 
Yes, for as long as a live build still contains the RC SDK. That endpoint is what lets RC pick up renewals, refunds, grace‑period exits, etc., even if a user never opens the old build again. RevenueCat will ignore brand‑new SK2 purchases because the tracking switch is off (as in, no SDK to send through), so leaving the URL in place won’t inflate MTR.
 
3. Will existing RC‑integrated builds continue to work?
 
They will, provided you keep the RC project (and its API keys) active and leave ASSN pointed at RC. Customers on old versions will see no change.
 
As to things to consider/watch out for, you’ll need your own secure receipt‑validation backend (App Store Server API v2) for fraud checks, grace‑period exits, etc. and also lookout for any post‑migration Apple revenue, making sure that won’t appear in RC webhooks, integrations, or Customer Profiles. 
 
One last point to mention would be to consider data continuity by exporting your historical RevenueCat data before fully transitioning (use Scheduled Data Exports), to plan on how to handle any customer support queries about said historical purchases and also plan for subscription status checks across both systems during this transition.
 
This should get you in the state you're expecting to be using only SK2 directly.
 
Best,


Forum|alt.badge.img+3

Thanks. This is helpful information as I work through my options.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings