Skip to main content

Users started complaining that they need to click "Restore Purchase" when installing on a new device. They say they don't have to do it in other apps (also without login, on Android). 

Are there any risks or drawbacks with running for instance syncPurchases the first time the app is started on a new device?

syncPurchases on Android?
Would it work in this scenario? Any drawbacks?

restorePurchases on Android?
Would it work in this scenario? Any drawbacks?

syncPurchases on iOS?
Here kaitlin wrote : syncPurchases unfortunately won’t work at fresh app install on a new device for anonymous ids, it just syncs the receipt on the device. So if there is not a receipt on the device, it definitely won’t work (still silently).
But in production there is always a receipt when downloading the app from the App Store, right?
Wouldn’t that mean that syncPurchases should work fine to restore proactively?

restorePurchases on iOS?
Could trigger a login prompt - not good.

Hey @Björn,

It’s probably not the worst thing to call syncPurchases on launch but without knowing much more about your app it’s tough for me to recommend it. It’s actually quite standard to have the customer initiate the call to syncPurchases when the app is freshly installed. However, I can talk a little bit about how syncPurchases works to help you evaluate.

So what Kaitlin was referring to is that syncPurchases uses a device API that simply pulls the receipt from the device cache without refreshing it with Apple (on Android no such equivalent API exists so it gets pulled directly from Google’s servers every time.) This is what prevents syncPurchases from prompting for a login. This is also what Kaitlin meant by “if there’s not a receipt on the device” - if an updated one hasn’t been pulled from Apple’s servers, which can happen, then the call silently doesn’t work, which is what most people want anyway since syncPurchases is designed to work in the background based on some automated action.

One important thing to note with syncPurchases (and restorePurchases) is can result in “aliasing” users. You can read more about that here: https://www.revenuecat.com/docs/getting-started/restoring-purchases if you don’t have any user authentication system in place then aliasing users will be quite a normal occurrence and you probably won’t really notice any bad effects from calling syncPurchases once on launch.

Finally, one reason why you don’t see users having to manually call syncPurchases on Android is that the RevenueCat Android SDK actually calls an internal implementation of syncPurchases due to some unique constraints of Android compared to iOS. So if that’s the behavior you want, calling syncPurchases on launch sounds appropriate.

Thank you @sharif. You wrote “Finally, one reason why you don’t see users having to manually call syncPurchases on Android is that the RevenueCat Android SDK actually calls an internal implementation of syncPurchases due to some unique constraints of Android compared to iOS.” Do you actually mean RevenueCat Android SDK or did you mean Android SDK? If you do mean RevenueCat Android SDK I do not understand why I need to call syncPurchases...

Hi @Björn,

Good question, I did mean that the RevenueCat Android SDK will call syncPurchases on first launch. That means that on Android you don’t need to call syncPurchases but to replicate the same behavior on iOS you have to call syncPurchases on iOS on first launch.

Reply


Terms & ConditionsCookie settings