Converting a Paid App to In-App Subscriptions: Is the blog post still up to date and complete?

Hi ​@perr,

Honestly that guide is a bit outdated (you can probably tell by the screenshots). We keep having it posted and active because it can still be useful if you update the deprecated methods. I’ll make an internal note to have it refreshed with the latest APIs.

Regarding your other questions, `syncPurchases` should always be enough. We don’t recommend calling `restorePurchases` without a user interaction - triggering the popup without the user knowing it can be frustrating and confusing for the user. What syncPurchases does is looking at the purchase history of the user and synchronize it with our servers if needed.

When it triggers the sign-in prompt, is it only in sandbox or also production? Here’s Apple docs on how to get the original purchase using AppTransaction. 

Said that, if you have a db with customer I would grant free entitlements to all users which would reduce a lot your workload.

Best,

​@joan-cardona,
> Regarding your other questions, `syncPurchases` should always be enough.

Hm, I’m afraid that might not actually be true.

I deployed a production version that explicitly tries to call Purchases.shared.customerInfo() and check for originalPurchaseDate.
If there's no purchase date, it then calls Purchases.shared.syncPurchases() and checks again in the returned info. Finally, it tracks an event with the result of that test.

Apparently, this works for around ~80% of users — but for ~20%, originalPurchaseDate is still missing even after syncPurchases(). It seems like restorePurchases() is needed to retrieve it (which isn’t great, for the reasons you mentioned).

This matches pretty closely with my earlier tests using the AppTransaction API directly (which I assume you’re using under the hood?).
Often, calling await AppTransaction.shared fails (again, about 20% of the time, and I’m skipping network issues). In those cases, I have to call await AppTransaction.refresh(), which can trigger the same sign-in popup — also not ideal.

While I might be missing something (?), I don’t really see any better workaround, either using your API or Apple’s. So I think it’s worth mentioning this in the blog post, since the migration might not be as smooth as outlined. You’ll likely need a strategy for handling that 20% edge case — either grant premium access to users even without a verified purchase, or accept the risk that some paying users might see the paywall.

Hi ​@perr,

Thank you a lot for your detailed answer. Let me look into it and see if we can update the blog post as well as giving you a final answer.

Best,