One of the purchase related scenarios for my app is removing ads that are normally displayed right after the app is installed.
I was wondering what would be the best way of handling the case where:
1) the user installs the app
2) the user makes a purchase removing the ads (a non consumable)
3) the app is uninstalled
4) the user reinstalls the app on the same or a different device.
At this stage of my project I do not want to maintain a backend server or use Firebase with a login mechanism etc, and instead I would very much like to rely on the RevenueCat alone.
I have tested the scenario on Android and it appears that since it is recommended that the method that restores transactions should be triggered consciously - by tapping a button for example and not when the app is starting up, the only way I can think of to do this is to display a dialog when the app is started for the very first time and give the user opportunity to restore the purchases (if any were previously made) and once the purchase that disables displaying of the ads is found the app should disable the ads.
Now, in a scenario where the transaction details are handled by RevenueCat/Store and again with no dedicated backend maintained by me the app would connect to, is it possible to do this without displaying the initial dialog and calling the restore transactions when the user hits the button?
Thanks for your suggestions!
Best answer by codyView original
If you aren’t providing a custom app user ID from your own backend, we’ll automatically use RevenueCat anonymously generated user IDs. Since a new installation doesn’t know what the previous user ID would have been, we generate a new ID that doesn’t automatically restore transactions. In this case, you’ll need to provide a way for users to restore their purchases to the new user ID.
If you have a way to detect it’s a new installation, you could call ‘Purchases.shared.syncPurchases’ which would automatically sync the user’s receipt with RevenueCat in the background without requiring user input, and transfer the purchases as necessary to the new user. You shouldn’t call this every launch, though.
Otherwise, I’d recommend always including a Restore Purchases button in your paywall. This may prompt users for a sign-in, so this should only be called as a result of direct user action, but this will also transfer purchases as necessary.
Thanks for your response.
Since I am relatively new to implementing purchases in mobile apps and I was precisely hoping for a response like that - pointing me to some call that I wasn’t even not aware existed.
I spent some time reading the RC docs on how the user ids are created and used and also on what is the strategy used for restoring purchases. If I understand it right and taking into account my particular use case which is basically all about enabling users to buy non-consumables that when purchased permanently unlock something in the app I came to conclusion that (thanks be to heavens!) I do not need a backend and instead I can rely on the fact that for both Android and iOS, purchases of non-consumables (Android seems not to make any distinction between consumables and non-consumables) are recorded in the stores against the account the in app purchase is made from.
I carried out some tests in the sandbox (Android only as for now) and with the Restore Behaviour for the App set to “Transfer Purchases” it seems to be working as predicted. Please validate my assumptions here.
I tried the Purchases.synchPurchases you suggested and the only visible difference between this and Purchases.restorePurchases seems to be the former returns immediately and does its work in the background while the app continues and the later waits till the purchases if there were any are restored.
Since on Apple devices there is a requirement that there should be some explicit way of restoring purchases (like a button) I am inclined to display a dialog before the app is run for the first time after being installed and yes there are easy ways to do that and for Android I think I will consider using what you suggested.