Skip to main content
  • Community
  • Get Help
  • SDKs
  • Are originalApplicationVersion and originalPurchaseDate ever expected to be nil in the sandbox?

On one of my devices, I’m consistently getting nil in PurchaserInfo for both originalApplicationVersion and originalPurchaseDate. Based on what I’ve read in the docs and elsewhere, I thought in the sandbox I should always expect originalApplicationVersion to be “1.0” and originalPurchaseDate to be 2013-08-01.

I did notice that in the header for both of these properties, it says:

@note This can be nil, see -bRCPurchases restoreTransactionsForAppStore:]

But that function doesn’t exist.

This seems like pretty odd behavior, since it’s only happening on one of my devices, both in TestFlight and running through Xcode. I can’t confirm it easily, but I think one of my TestFlight testers is experiencing it too.

I also tried a few different versions of the SDK and the issue was the same.

 

Purchases iOS 3.12.3

iOS 14.7.1

Hey @Nate Thompson! 👋

Both of these values can be nil if a receipt for the user has never been synced to RevenueCat. When you’re testing in sandbox, the original application version will be 1.0 only after a receipt has been synced.

To sync a receipt to RevenueCat, you’ll need to either make a purchase or call restoreTransactions. It looks like the docs for the method in the SDK haven’t been updated to reflect the updated method name when it was changed from a prior version. Alternatively, you could programmatically call syncPurchases as it doesn’t require user input (although the receipt may be outdated).

Ultimately, you should plan on these values potentially being nil and provide an option for users to restore purchases.

Hey @Nate Thompson! 👋

Both of these values can be nil if a receipt for the user has never been synced to RevenueCat. When you’re testing in sandbox, the original application version will be 1.0 only after a receipt has been synced.

To sync a receipt to RevenueCat, you’ll need to either make a purchase or call restoreTransactions. It looks like the docs for the method in the SDK haven’t been updated to reflect the updated method name when it was changed from a prior version. Alternatively, you could programmatically call syncPurchases as it doesn’t require user input (although the receipt may be outdated).

Ultimately, you should plan on these values potentially being nil and provide an option for users to restore purchases.

Hi @cody!

Thanks for taking the time to help me out.

I had forgotten that I’m actually using syncPurchases already. So it looks like it’s mostly a sandbox issue, since there’s no app store receipt in that case.

Can you elaborate on how the receipt can be outdated? Does that just refer to the chance that there’s already a receipt on the device but it doesn’t show an active subscription?

Reply


Terms & ConditionsCookie settings