Skip to main content
Question

Unexpected Alias in Sandbox: Why are separate Sandbox Apple IDs being merged into one RevenueCat Profile?

  • February 3, 2026
  • 1 reply
  • 17 views
K
Forum|alt.badge.img

I am testing a "No-Login" app (Anonymous IDs only) using RevenueCat in the Apple Sandbox environment. My project also uses Firebase and AppsFlyer. I am trying to simulate two completely different users, but RevenueCat is automatically aliasing them into a single Customer Profile.

The Workflow I Followed:

User A: Installed the app → Generated $RCAnonymousID_1 → Purchased Weekly Plan using Sandbox Account A.

Cleanup: Uninstalled the app from the device.

Switch: Signed out of Sandbox Account A in developer Settings and signed into Sandbox Account B.

User B: Freshly installed the app → Generated $RCAnonymousID_2 → Purchased Monthly Plan using Sandbox Account B.

 

The Issue: Instead of creating a second Customer Profile for $RCAnonymousID_2, RevenueCat added $RCAnonymousID_2 as an alias to the first profile.

Integrations in Use:

  • Firebase: I use the Firebase integration. (Are Firebase Instance IDs or UIDs being used by RevenueCat to link these sessions?)

  • AppsFlyer: I have the AppsFlyer integration active. (Could the persistent AppsFlyer Device ID be causing RevenueCat to see this as the same device/user?)

Questions:

  • Does RevenueCat link users based on the original_transaction_id even if the Sandbox Apple ID has changed?

  • How do the Firebase and AppsFlyer integrations affect aliasing when no explicit logIn is called?

  • Is the device's IDFV (Identifier for Vendor) persisting across these uninstalls and causing a conflict?

  • How can I achieve a truly "clean" state for testing multiple unique users on a single physical device without hitting the 50-alias limit?

Environment:

  • SDK: Swift

  • Device: iPhone 14 pro max physical device

1 reply

Tarek
RevenueCat Staff
Forum|alt.badge.img+1
  • Tarek
  • RevenueCat Staff
  • February 4, 2026

Hi ​@kamal,

Thank you for reaching out. I'm Tarek, from the support team, and I'll happily help you understand what's going on.

 

The aliasing you witnessed could be explained by the Transfer to new App User ID Restore Behavior, which is the default one. 

Under this behavior, if an anonymous ID restores and the owner of the receipt is also anonymous, the anonymous identifiers will be merged (aliased).

I suspect the receipt might stick around under some conditions. However, in order to investigate more deeply, I would need the IDs of the affected customers. Feel free to open a ticket and share this information privately. (Please tell me if you do, so I can catch the ticket)

 

About your questions, here are my answers:

Does RevenueCat link users based on the original_transaction_id even if the Sandbox Apple ID has changed?

 

RevenueCat links by what's in the receipt it finds. The configured behavior will also apply if an identified App User ID makes a new purchase and the device receipt is already associated with a different identified App User ID in RevenueCat.

 

How do the Firebase and AppsFlyer integrations affect aliasing when no explicit logIn is called?

Without calling logIn, it shouldn't affect aliasing.

 

Is the device's IDFV (Identifier for Vendor) persisting across these uninstalls and causing a conflict?

IDFV can persist, but it would have an effect on analytics/attribution, not aliasing.

 

How can I achieve a truly "clean" state for testing multiple unique users on a single physical device without hitting the 50-alias limit?

One way to be 100% sure of what receipts your device expose is to use StoreKit local testing with Xcode. You'll be able to simulate actions of a real store, with the caveat that it would be a local only option. 

If you share with me affected IDs through a support ticket, I'm confident we can find the source of the issue and thus the remedy to allow you testing without hitting the limit.

 

Best regards,

Tarek, Developer Support Engineer at RevenueCat.

Terms & ConditionsCookie settingsAccessibility statement