Skip to main content
Solved

Mac Catalyst app "stuck" with the RevenueCat app user ID of a single sandbox test user

  • 26 July 2021
  • 2 replies
  • 207 views

I would like to know how to reset a RevenueCat-enabled Mac Catalyst app's in-app purchase state so that I can test the app's in-purchases with different sandbox users and with local StoreKit testing. Below is a more in-depth description of the issue I’ve had and how I've (so far unsuccessfully) tried to resolve it.

(Note: in what follows, references to "app user IDs" are always to the anonymous app user IDs that RevenueCat automatically provides.)

Prior to the introduction of local StoreKit testing for in-app purchases, it was useful to have multiple sandbox accounts to test in-app purchases (since a developer could use any one sandbox account only once to test a particular IAP— as you probably know, there's no way to "roll back" a purchase in a single sandbox account to try testing it again with that account).

When I wanted to test an in-app purchase with a new sandbox user on the same iOS / iPadOS device on which a previous sandbox user was logged in, the following procedure reliably reset the app on the device, so that I could log in on that device with the new sandbox user:

On the iOS / iPadOS device…

  1. I deleted the app.

  2. In the Settings app -> App Store, I signed out of the sandbox account listed there.

  3. I restarted the device.

  4. I re-installed the app using Xcode.

 

Now I am developing a Mac Catalyst version of the app, and the analogous version of the above procedure (described below) fails to reset the app on the Mac— no matter what I do on the Mac (including trying to sign in with a new Sandbox account via Preferences in the App Store app), the app continues to register the same RevenueCat App User ID for the previously-signed-in sandbox user. The result is that on the Mac I can neither try out in-app purchases with a different sandbox user, nor make use of local StoreKit testing on the Mac (after I had previously logged in on it as a particular sandbox user).

Here's the “reset” procedure I've tried:

On the Mac…

  1. I deleted Xcode's entire Derived Data folder (in which is contained the Mac Catalyst app). I also looked for any other preferences / traces of the app on the Mac, and deleted whatever I found.

  2. In the App Store app -> Preferences, I signed out of the sandbox account listed there.

  3. I restarted the Mac.

  4. I re-installed the app on the Mac using Xcode.

 

As noted above, this procedure fails to reset the app on the Mac— no matter what I do on the Mac (including trying to sign in with a new Sandbox account via Preferences in the App Store app), the app continues to register the same RevenueCat App User ID for the previously-signed-in sandbox user. Again, the result is that on the Mac I can neither try out in-app purchases with a different sandbox user, nor make use of local StoreKit testing on the Mac (after I had previously logged in as a particular sandbox user).

To try resolving the issue, I could, of course, simply delete the app user ID via the RevenueCat website. I'm a little wary to do that, though, given that (1) it's irreversible and (2) I want to be absolutely sure I don't accidentally delete the ID for a user with live purchases. I don't think I'll end up doing that with the "stuck" app user ID on the Mac noted above, since it is listed as one of the sandbox app user IDs in my RevenueCat account; but my RevenueCat account also strangely lists the app user ID as one that was "first seen using the app" back in March, despite my logging in to the Mac with the associated sandbox user account for the first time just a few days ago. (That sandbox user account made no purchases prior to a couple days ago, and the stuck user ID has no aliases.) Given RevenueCat's reporting that the user ID was "first seen using the app" back in March, I worry that the user ID somehow got associated with some other (potentially "live purchase") user's use of the app.

If anyone has any suggestions for resetting the app on the Mac (for use with different sandbox users and/or local StoreKit testing), I'd be happy to hear those tips. (And, of course, if any of you think the best idea is still deletion of the app user ID on the RevenueCat website, I'd be happy to hear that, too.) Thanks!

2 replies

sharif
Rank
Userlevel 5
Badge +9

Thanks for the detailed post! I think the trick here is to narrow down exactly which app user IDs are being created and fetched, which will point to the reason why the app keeps using an old one.

From what you describe (somehow fetching information for the same app user ID after a fresh install) it seems like you’re hitting a cache problem. I think the first step is to enable debug logs, launch the app and look for a set of logs like this:

2021-07-26 18:22:59.177449-0400 <APP_NAME>[3698:642172] [Purchases] - DEBUG: ℹ️ Debug logging enabled
2021-07-26 18:22:59.177726-0400 <APP_NAME>[3698:642172] [Purchases] - DEBUG: ℹ️ SDK Version - 3.10.1
2021-07-26 18:22:59.177818-0400 <APP_NAME>[3698:642172] [Purchases] - DEBUG: 👤 Initial App User ID - (null)
2021-07-26 18:22:59.178250-0400 <APP_NAME>[3698:642172] [Purchases] - DEBUG: 👤 Identifying App User ID: <APP_USER_ID>
2021-07-26 18:22:59.216605-0400 <APP_NAME>[3698:642172] [Purchases] - DEBUG: ℹ️ No cached Offerings, fetching from network
2021-07-26 18:22:59.241342-0400 <APP_NAME>[3698:642172] [Purchases] - DEBUG: ℹ️ applicationDidBecomeActive
2021-07-26 18:22:59.669736-0400 <APP_NAME>[3698:642172] [Purchases] - DEBUG: ℹ️ PurchaserInfo cache is stale, updating caches
2021-07-26 18:22:59.675200-0400 <APP_NAME>[3698:642482] [Purchases] - DEBUG: ℹ️ API request started: GET /v1/subscribers/<APP_USER_ID>/offerings
2021-07-26 18:22:59.677938-0400 <APP_NAME>[3698:642482] [Purchases] - DEBUG: ℹ️ There are no requests currently running, starting request GET /subscribers/<APP_USER_ID>
2021-07-26 18:22:59.678071-0400 <APP_NAME>[3698:642482] [Purchases] - DEBUG: ℹ️ API request started: GET /v1/subscribers/<APP_USER_ID>

If you don’t see the two lines Initial App User ID - (null) and Identifying App User ID: $RCAnonymousID:... , it means that the SDK is pulling an app user ID from its UserDefaults cache. The solution would be to uninstall the app in such a way that clears UserDefaults.

If you do see those two lines, then it’s probably a different issue (maybe RevenueCat is recognizing the user based on the transaction IDs in their receipt?)

Finally, while deleting app user IDs is a permanent action, if the user doesn’t have any production purchases (you can toggle sandbox data on and off using the switch at the top right of Customer Profile) then it’s safe to delete them. Users can always restore purchases to create a new customer profile with their previous purchases as well, so it’s not too destructive to delete a user as a troubleshooting step.

Sharif
C
Badge +4

Hi, Sharif.

Thanks for the quick and quite helpful reply. Your mention of the UserDefaults cache reminded me that (as documented in this informative article) the best current way to change a Mac app's preferences / UserDefaults settings is via the defaults command. That article points to the excellent, free Prefs Editor app, which I've used in the past (with great success) to modify a Mac app's preferences / UserDefaults settings.

Just now I used Prefs Editor to search my Mac for any preferences associated with my RevenueCat-enabled app, found the relevant RevenueCat values in the plist file unearthed by that search, deleted those values, and saved the modified plist file. The next time I built and ran from Xcode the Mac Catalyst version of the app, its purchase state had been successfully reset!

So if other RevenueCat users face a similar problem with a RevenueCat-enabled Mac Catalyst app whose purchase state is stubbornly stuck on that of a particular sandbox user, I'd recommend the above procedure (deleting the relevant RevenueCat values from the Prefs-Editor-discovered plist file for the app) to resolve the issue.

Thanks again, Sharif, for helpfully pointing me in the right direction!

Reply


Terms & ConditionsCookie settings