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

Are originalApplicationVersion and originalPurchaseDate ever expected to be nil in the sandbox?

N
Forum|alt.badge.img+3

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 -[RCPurchases 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

Best answer by cody

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.

View original
Did this post help you find an answer to your question?

2 replies

cody
RevenueCat Staff
Forum|alt.badge.img+8
  • cody
  • RevenueCat Staff
  • 497 replies
  • Answer
  • August 19, 2021

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.

N
Forum|alt.badge.img+3
cody wrote:

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


Most helpful members this week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings