Skip to main content

Hi,

Thanks for your blog post: Converting a Paid iOS App to Subscriptions. It was very helpful! I have a few follow-up questions:

  1. Is all the code and information in the post still up to date after a few years?

  2. Regarding the syncIfNeeded function: it checks the info returned from RevenueCat, and if that fails and a receipt exists, it attempts to sync. But what happens if the receipt doesn't exist, or syncing isn’t sufficient? Is that a possible scenario? How should we handle users in that situation?

  3. In such cases, should we fall back to calling restorePurchases, which might trigger the system sign-in prompt? The article doesn’t mention this.

Also, I noticed that appStoreReceiptURL is now deprecated, and Apple recommends using the AppTransaction API. I've tried this in my app, but in some cases, I can't access the original app version or purchase date unless I explicitly call AppTransaction.refresh(), which often causes a sign-in prompt. This seems similar to RevenueCat’s restorePurchases(), right?

So with Apple’s native SDK, there seem to be cases where retrieving the original purchase data requires prompting the user to sign in.

Does RevenueCat handle this better? For example, is a receipt always available (even if outdated), which would still allow access to original purchase data?

Or am I essentially in the same situation, where some users will inevitably need to go through restorePurchases / AppTransaction.refresh() and sign in to Apple?

Thanks again!

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,

Reply


Terms & ConditionsCookie settings