Proactive restoring

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.