Skip to main content
Question

Managing Multiple User Accounts on Same Device


Forum|alt.badge.img+1

Hello RevenueCat community,

I am experiencing a challenge in managing in-app subscriptions for multiple users on the same device. Here's the situation:

  1. User A has an active subscription and is logged into the app on a device.

  2. User A logs out, and User B logs in on the same device. User B doesn't have an active subscription, so they are correctly presented with the paywall.

  3. When User B attempts to purchase a subscription, Apple's system sends an alert that a subscription already exists (referring to User A's subscription).

  4. Upon dismissing the alert, the purchase process proceeds, and User A's subscription gets linked to User B's account.

  5. When User A logs back in, they are incorrectly presented with the paywall, and RevenueCat's records show User B as the owner of the subscription.

In this situation, my goal is to keep User A's subscription linked to User A, and alert userB that there is already an active subscription linked to the current appleID, and therefore cannot proceed with the. The challenge is to prevent the "subscription already exists" alert from Apple and the subsequent linking of User A's subscription to User B's account.

I would greatly appreciate any guidance or advice on how to resolve this issue.

Thank you in advance!

4 replies

kaitlin
RevenueCat Staff
Forum|alt.badge.img+6
  • RevenueCat Staff
  • 328 replies
  • July 20, 2023

Hey @etienne_ ,

What happened here comes down to the restore behavior that you have set, “Transfer to new App User Id”. This is our default behavior, which ensures that a user can always access their subscription, even if they are on a different device, but the subscription is always only owned by one user id. You can read further about it here: https://www.revenuecat.com/docs/restoring-purchases#transfer-to-new-app-user-id

The goal that you describe sounds like it could possibly be met by one of the other restore behaviors, which are: 

  • Transfer if there are no active subscriptions” - a transfer would only occur in the case of there being no active subscriptions. In the scenario you described above, the transfer wouldn’t occur and User B wouldn’t be able to purchase at all.
  • Keep with original app user id” -  This would meet your goal but is a pretty strict behavior. When User B attempted to purchase, it would throw an error. We only recommend this behavior for apps that have strict log in logic and never allow a user to access their app without logging in. 

You can follow the links at each bullet point to read more about the behaviors and decide which works best for your app!


vic-a563d7
Forum|alt.badge.img+6
  • Dedicated Member
  • 44 replies
  • October 24, 2023

So on this topic, what is the best approach like the OP mentioned? Where would the user A userId be stored? If one option is picked, does it mean user A trying to login to a different device will or will not get their entitlements?

The confusing part for me is how does it work when say user A deletes their account with the app without doing anything else. Then after a couple days goes back and creates a new account. Will restore work even if user A now has a new userId inside the app?


vic-a563d7
Forum|alt.badge.img+6
  • Dedicated Member
  • 44 replies
  • November 18, 2023

@kaitlin are you able to help determine best way to setup the transfer configuration in the scenario described above?


Forum|alt.badge.img+1

Although it’s not subscription and it’s one time product which are consumable, I prevents transfer, (in ios) and login with account A to purchase then login with account to purchase, two products belongs to account A both.
It’s ridiculous, it mean app user id is useless!!

And in android, it’s totally different, two products belongs account A and account B separately. I suppose android is the expected!


Reply


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