We are planning to use the "block restore" configuration on Revenue Cat for our iOS application and wanted to make sure (1) it's the right option for us given our business logic and (2) if we use it, can/should we avoid RC anonymous IDs altogether since we require a user to have an account and thus internal UUID (app user id) in our application before subscribing? We want to have a single source of truth for identifying a user, and to avoid having lots of anonymous IDs and the network calls to RC API that would unnecessarily create them (if possible).
1. Our application requires users to create an account in order to subscribe, and we want to prevent the sharing of a subscription linked to a single Apple ID across multiple user accounts / internal app_user_ids that live in our application database. This makes it seem like the "block restore" option is the way for us to go since that should prevent both (a) the sharing of an Apple ID’s subscription from User A to User B (where both users are associated with the same Apple ID), as well as (b) the revocation of that subscription from User A in case User B tries to subscribe while logged into the same Apple iD – this is what the "transfer purchases" configuration would enable, which could open a can of worms for us.
We were somewhat hesitant to run with the "block restore" approach given the "Use with caution " disclaimer associated with it in the documentation: https://docs.revenuecat.com/docs/restoring-purchases#block-restores – but is it still the right option for us given the above? We understand we will need to have special flows / messaging for users who are blocked in order to help them get access to their subscription entitlements.
If I understand correctly, when someone installs and opens our application for the first time, the Revenue Cat SDK will create an anonymous ID for that person so long as we configure/initialize RC SDK on app launch, i.e. before a user signs up. If the person then creates an account on our application as User A, we will pass new User A's UUID (let's say RevCatA) to the Revenue Cat SDK through the login() method described here: https://docs.revenuecat.com/docs/user-ids#login-behavior
This will merge our internal app_user_id “RevCatA” with the anonymous RC ID for the same subscriber record synced via Revenue Cat API, making the anonymous ID an alias.
Scenario 1: User A never subscribes, but we create a RC subscriber record with a RC anonymous ID and our provided RecCatA app_user_id in RevenueCat’s database via the RC SDK. User A signs out, and User B creates a new account on our system while logged into the same Apple ID.
Will Revenue Cat block a subscription attempt by a User B associated with the same Apple ID because User A exists in Revenue Cat’s DB associated with the same Apple ID, even though User A never subscribed?
Scenario 2: User A subscribes, creating a record of their subscription on Apple and Revenue Cat. They delete their account through our application while their subscription is active, which triggers a DELETE subscriber call from our API to Revenue Cat, deleting the record of the subscriber and all subscription history on RC. User B then creates a new account in our system while logged into the same Apple ID as User A – because there is no record of the active Apple ID subscription on Revenue Cat, but there is a record of the active subscription on Apple, Revenue Cat will allow User B to use the active subscription recognized by Apple.
Is this correct?
Scenario 3: User A subscribes, creating a record of their subscription on Apple and Revenue Cat. They do not delete their account. User B signs up while logged into the same Apple ID as User A and attempts to subscribe. Revenue Cat blocks the subscription request because a record of the subscription exists for User A with the same Apple iD in the RC database.
Is this correct?
2) Given that we will always need a user account and internal app_user_id in our database for the user to subscribe, is there any reason to use RC’s anonymous IDs? While there is a state in our application with no internal user ID available (no user is logged in), there’s no possibility that the person can subscribe until they create a user account in our system, and thus not a clear need to have an anonymous ID / record on Revenue Cat for the anonymous user.
Should we instead defer the instantiation of the RC SDK until after the user logs in and we have their internal app_user_id? This would avoid the creation of the anonymous ID, but is it recommended even if we don’t want to create a RC subscriber until a user can actually subscribe according to our application logic? Based on this, it seems we should instantiate immediately (generate anonymous ID ) and logIn() the user when we have their internal app_user_id, but that doesn’t let us avoid the creation of the RC anonymous ID.
Is there a proper way to create a subscriber on RC with the app_user_id we provide while preventing RC from generating an anonymous ID before our user authenticates?
Additionally, the logout() method makes another network request to create a new anonymous user, which again is redundant in our case. We don’t see why we would need a new anonymous ID generated upon logout() – is it possible/advisable to log the user out without creating an anonymous user?
Best answer by sharifView original