Skip to main content

Hi team,

We would like to ask for clarification on finishing transactions for consumables on iOS.

RevenueCat currently finishes transactions automatically. It is left to integrators to ensure the purchase is honoured, for example through CustomerInfo.

This is in direct contradiction to Apple’s guidelines, which state that the transaction should only be finished if all content has been delivered to the user first.

As of this writing, and iOS SDK 5.14.4, it is our understanding that any app using RC for non-subscriptions is likely in violation of Apple guidelines.

I wonder if something like a flag passed by integrators that influences the shouldFinish logic might solve this by ensuring we have provided users with the corresponding content?

As a follow-up topic, with more and more apps offering a mix of renewing subscriptions, consumables, non-consumable, and non-renewing subscriptions, I second ​some of RC’s staff comments on the PR thread that more granular access may be provided in the future based on the exact product type.

Thanks in advance!

Hi ​@joey_ ,

While you are correct that unlocking the correct content is left to the integrating app, we don’t believe that this violates Apple’s policies – the policies are written this way mostly to ensure that customers do not make a purchase that then isn’t unlocked. As long as you process `CustomerInfo` correctly, this should not happen – in other words, the successful posting of the purchase to the RevenueCat backend and the associated update of the `CustomerInfo` object is considered to be the unlocking of the content granted by the purchase.


Thanks for the answer Jens!

Transactions should definitely be finished after content has already been delivered, which is currently impossible when integrating with RC — I have confirmed this with Apple.

I do agree though that with the transaction safely captured in `CustomerInfo` the likelihood of issues is minimal.

It would still be greatly appreciated if the team considered this for future consideration. 

Thanks again 👍


As a follow up, this is making it harder for us to keep track of which user purchased a consumable for fraud reasons, necessitating access to `appAccountToken` (as far as I can tell not currently supported).

Per above, it would be very useful if we could avoid the additional work for this in our own systems.