Skip to main content

I’m trying to follow the docs for the capacitor purchases plugin. I’m migrating my codebase from the awesome-cordova-plugins approach I used with capacitor 2. Incidentally, docs are not entirely clear as sometimes there’s no capacitor example (only cordova). Anyway, my issue is

If I use one of these ...

const customerInfo = await Purchases.getCustomerInfo();
Purchases.getCustomerInfo().then((customerInfo) => {

Then use this ... it tells me there’s no entitlements property …

customerInfo.entitlements.active

But if I double up the ‘customerInfo’ then it doesn’t complain …

customerInfo.customerInfo.entitlements.active

Note that these issues are showing up in VSCode editor … I haven’t converted all the code yet, so nowhere near actually building/running this.

What’s going on?

 

Not sure if this affects anything but I wasn’t going to uninstall the old plugins until all my new code is written, so all these are still there:

"@awesome-cordova-plugins/purchases": "^5.37.3",
"@revenuecat/purchases-capacitor": "^10.3.4",
"cordova-plugin-purchases": "^2.3.0",

 

I got my head round it eventually. The approach with a listener in the ‘Getting Subscription Status’ docs allows direct access to the customerInfo:

await Purchases.addCustomerInfoUpdateListener(customerInfo => {
  // customerInfo object works e.g. customerInfo.entitlements

But the approach in SDK Quickstart > Check Subscription Status docs, needs the customerInfo to be accessed within the returned object. So because I used customerInfo for the returned object it felt messy (customerInfo.customerInfo). I prefer ...

const infoObject = await Purchases.getCustomerInfo();
// use ... infoObject.customerInfo.entitlements

I feel the Capacitor docs could be improved a bit, especially as the Getting Subscription Status docs only show Capacitor code for some of the documentation :-)

Hey ​@philc ,

Thanks for raising this and for taking the time to investigate and document what you found.

This is indeed quirk of how the Capacitor plugin bridges native data back into JavaScript, it wraps the native result inside a named property. While technically correct and documented (Promise<{ customerInfo: CustomerInfo }>), we totally understand how this can be confusing in practice, especially when migrating or switching between SDKs.

Updating the structure would be a breaking change, so the current shape is intentional, but we agree the docs could do a better job of calling it out clearly and I have flagged this with the team too!

If I could suggest, and if it’s something you’d be willing to do, we have a Contributing section on the SDK, if this is something you would like to explore too. 

Appreciate you sticking with it and sharing your workaround!

Best,

Reply


Terms & ConditionsCookie settings