Multiple anonymous aliases for my users

Thank you - I have checked everything now and it’s setup as it should be.  I suspect I broke things as I had incorrectly implemented this in a previous version which I just had to mop up now.  I think.  This was my previous broken code:

configuration.purchasesAreCompletedBy = PurchasesAreCompletedByRevenueCat();
    await Purchases.configure(configuration);

    if (authService.currentUser != null) {
      log.t(
          '2. User is logged in, setting app user ID to ${authService.currentUser!.uid}');
      configuration.appUserID = authService.currentUser!.uid;

      if (authService.currentUser!.displayName != null) {
        Purchases.setDisplayName(authService.currentUser!.displayName!);
      }
      if (authService.currentUser!.email != null) {
        Purchases.setEmail(authService.currentUser!.email!);
      }
    } else {
      log.t('4. User is not logged in, setting app user ID to null');
      configuration.appUserID = null;
    }

As you can see, I ran configure first and then tried to set the appUserId.  It seems that anyone who opened the app with this version and then upgraded, got new accounts created instead of aliases.  (I’m posting it here in case someone else ever has the same issue).

AuthService is fully up and running before the RevenueCat is instantiated and it’s instantiated only once during start up.

In addition, I also have a listener set up to listen for auth state changes:

    _authListener = authService.onLogInLogOut.listen((user) async {
      if (user != null) {
        await Purchases.logIn(user.uid);
        if (user.displayName != null) {
          Purchases.setDisplayName(user.displayName!);
        }
        if (user.email != null) {
          Purchases.setEmail(user.email!);
        }
      } else {
        await Purchases.logOut();
      }

I’m assuming the way I have it set up now, aliases will be created instead of new users - it’s just anyone who used the previous version of my app with the buggy code, will have new accounts created instead of aliases?

EDITED TO ASK:  Should I use Purchases.logIn(uid) instead of configuration.appUserID = uid ???

Hey ​@Mulder00 ,

Your current setup is much closer to best practice now, but just to clarify a few things (which I think are worth noting).

In your earlier implementation, the issue came down to the order of operations:

await Purchases.configure(configuration); configuration.appUserID = authService.currentUser!.uid; // too late

This is because when Purchases.configure() is called, the SDK reads the appUserID from the configuration object at that exact moment. If it's null or unset, the SDK initializes with an anonymous user.

Setting appUserID afterward has no effect, it doesn’t retroactively apply, and no error is thrown.

As a result, users who had previously been assigned an anonymous ID were seen as new users when the app updated with the fixed code. Since there was no aliasing between the anonymous and known IDs, the SDK created a new account, leading to the duplicate user entries you're seeing.

As to your new update, you're now doing two things correctly:

• initializing RevenueCat only once, during app startup;

• using an auth listener to call Purchases.logIn() or Purchases.logOut() in response to login state changes.

This is the recommended approach!

When a user logs in after being anonymous, logIn() creates an alias between the two IDs, ensuring entitlements and purchase history are preserved.

As to the appUserID vs logIn() approach, to explain a bit the difference/behavior:

• Use appUserID in the PurchasesConfiguration object only before calling configure(), when the user’s ID is already known. If you have it before calling configure() this is okay to do;

• For any login state changes after SDK initialization, use Purchases.logIn() and logOut().

In Flutter, and as we exemplify in Identifying Customers it’s common to use the cascade operator (..) to perform a sequence of operations on the same object, without having to repeat the object’s name. This is why this works, during the configure() call:

await Purchases.configure(
    PurchasesConfiguration('your_public_sdk_key')
      ..appUserID = authService.currentUser!.uid
);

It ensures the appUserID is set at the correct moment, before the SDK initializes.

As for users who launched the buggy version, they likely ended up with two separate accounts  (as we investigated, with anonymous and UID), because aliasing didn't occur. Your current setup fixes that, and going forward, new logins will be correctly aliased.

If you have users missing entitlements due to this, it’s worth prompting them to use the Restore Purchases feature in your app. This will help RevenueCat associate the correct entitlements with the current user ID. 

NOTE: It’s best to encourage users to use the “Restore Purchases” feature themselves, rather than triggering it programmatically in your app. Typically, this is presented as a button in your app’s settings or purchase screen, something like “Restore Purchases” or “Restore Subscriptions.”

This approach gives users control and clarity, especially if they’ve reinstalled the app, switched devices, or are troubleshooting access to their purchases. It also helps avoid confusion or unexpected changes to their account.

You should only trigger a restore programmatically if you’re absolutely certain it’s needed (for example, during a specific migration flow or if you have a very controlled use case).

For most apps, letting the user initiate the restore is the best practice.

Best,
Gui

Thank you for your helpful and comprehensive responses, I appreciate it!  And for what it’s worth, I don’t even have restore purchases in my code - I use the Paywall feature which has a Restore Purchases button, so if anyone contacts me, I’ll let them use that in the first instance to restore their purchases.

Despite these teething issues, I have no idea how I would have ever implemented subscriptions in my app without RevenueCat - I’m sure you can imagine what a mess I would have made if I had to do this separately for iOS and Android 😆.