Skip to main content

In apps that sell consumables items (e.g. gems), from what I understand, it’s necessary to provide a server to track the gem balance for a particular user. I’m not clear on what the requirements are for the origin of that user. Is there a way to avoid creating auth flows in the mobile app and rely upon RevenueCat to coordinate the various anonymous IDs associated with the Apple ID? Can this work between app deletes and re-installs?

 

In summary: Is there a way to track consumables (and the their balances) between app re-installs without needing to implement auth in the client.

 

Thanks!

Usually, we can use a receipt to “restore” and alias two anonymous users together. However, consumable purchases only show up in the receipt file for a limited time and therefore won’t be able to be aliased after a delete and reinstall.

 

One option might be to use the keychain and something like Firebase to persist the auth info in the app group, but this isn’t without its tradeoffs. The best option is some kind of login system. 

Thanks so much, Jacob! Firebase is a no for us, so Login System it is!

I know it’s a couple of years later but I’ve been kicking around an idea, as I work on my own coin-based system that’s going to have to pass Apple’s restore rules.

I think you can have a transaction log stored in a “document” that’s backed up and so can be restored on another device.

Apple’s guideline says 

you should make sure you have a restore mechanism for any restorable in-app purchases.

I spoke to one of the advisors at Apple in the WWDC23 lab on App Store Review about my ideas and his feedback was positive - sounds OK to him and there’s no obligation to share purchases on one device to another provided am clear to the user about the model.

ie: unlike subscriptions - consumables can be device-specific, just have to be conveyed to a replacement device

Reply


Terms & ConditionsCookie settings