Solved

Consumable entitlements disappearing after reinstall

  • 23 February 2022
  • 3 replies
  • 139 views

Badge +2

Hello. This is the fourth app I’m setting up using RevenueCat (so thanks!), only this time not subscription-based.

It is an iOS app using v.3.14.1 of the SDK, still performing tests in the sandbox environment. Basically I am using consumables with entitlements and those entitlements disappear after the app is uninstalled, even when the dashboard still reflects that the user should have the entitlement.

No matter what I try there are zero entitlements in the purchaserInfo after uninstalling the app:

  1. When I use the delegate
  2. When I restore transactions
  3. When I refresh the purchaserInfo

If I check the entitlements before the user deletes the app, even on subsequent app launches, the purchaser info reflects everything correctly. Repurchasing any consumable fixes this, at least until the app is uninstalled again.

Docs seem to indicate that we can use the consumables with entitlements, so am I missing something obvious? I am happy to share logs.

Thanks.

icon

Best answer by Andy 23 February 2022, 21:59

View original

3 replies

Userlevel 5
Badge +8

Hey @Francisco Cantu, happy to help here. 

I’m assuming that you’re using anonymous IDs (i.e.: not passing in userIDs to RevenueCat), let me know if this isn’t the case. 

 

If it is the case, though, then what’s happening is that after uninstalling, our SDK doesn’t have information about who this user is. When you make a purchase, the app sends a receipt, and that receipt will be used to map that user back to the user who made the other purchases. 

 

That said… That should also work if you’re using restoreTransactions. Debug logs would be very helpful here.

 

The only thing that comes to mind with regards to the difference for consumables is that consumables will disappear from the receipt once consumed, whereas subscriptions stay on the receipt forever. To be clear, our backend does still store consumables, so they don’t get lost in the ether, they just don’t show up in Apple’s receipts when our SDK queries them.

 

So maybe an optimization from our SDK that checks whether the receipt has transactions before sending could be preventing the receipt from being sent. 

 

The debug logs would allow us to figure that out. Would you mind attaching them?

Badge +2

Hi @Andy 

Thank you for sharing how it works on your side. I am definitely using manually-set IDs and even that way I was unable to get it to work last night.

But just as I went to gather logs right now, you can probably only imagine what happened... everything just worked. I even deleted the sandbox user from the web portal to retry everything again, and the next purchase stuck around even after deleting the app. I have made no code changes since then so I’ll just attribute it to me doing a mistake somewhere along the way -- but it’s working now!

If I am able to reproduce again in the future, I’ll definitely post again. Thanks again.

Userlevel 5
Badge +8

hahaha I’ve been there. Let us know if anything comes up again!! 

Have a great day!

 

Reply