Skip to main content
Solved

`checkTrialOrIntroductoryPriceEligibility` shows Apple ID sign-in alert ONLY in TestFlight

  • January 30, 2022
  • 2 replies
  • 181 views

Forum|alt.badge.img+4
  • New Member
  • 4 replies

Hello,

 

I hope all is well. I’ve implemented checkTrialOrIntroductoryPriceEligibility in my iOS app to be called whenever the annual product is successfuly retreived and we’re about to show the user the prices. When testing with Xcode, everything runs smoothly, but in TestFlight a sign-in to your Apple ID prompt will appear everytime it’s called. This prompt is not shown when you download the same build from the App Store, only when it’s downloaded from TestFlight.

 

This has been happening since I’ve added the code in mid-December, but now I would like to add test users to TestFlight and do not want to show this prompt everytime. I’ve seen that there’s been other posts about this, with only one of them having a workaround

 

I was wondering/hoping if there has been any new developments on this or anything else that we should try? Using CocoaPods and Purchases 3.13.2.

 

Any advice is greatly appreciated. Thank you in advance!

 

Best answer by cody

Hey @fra!

This is prompting for a sign-in because if we don’t find an existing receipt on the device, we’ll automatically fetch it - and when fetching a receipt from the App Store in the case of a receipt not existing, a sign-in is required. This is currently expected behavior (implementation, `refreshPolicy: .onlyIfEmpty`), so you’ll want to be sure you are calling this method at a time where it is appropriate for a user to potentially sign in.

This typically won’t occur in production as production installs almost always have a receipt available, and so the SDK doesn’t have to fetch it.

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

2 replies

Forum|alt.badge.img+4
  • Author
  • New Member
  • 4 replies
  • January 30, 2022

Actually, I was wrong, it shows up during development as well. So it shows for TestFlight AND when developing, but NOT in the App Store version. 

 

Here are the logs that show when the sign-in prompt appears. The first one is when the prompt appears and the two marked with “[Purchases]” show after pressing cancel on the sign-in pop-up.:

  • 2022-01-30 13:32:32.528332-0800 <SKReceiptRefreshRequest: 0x600001dfe860>: Finished refreshing receipt with error: Error Domain=ASDErrorDomain Code=907 "Unhandled exception" UserInfo={NSUnderlyingError=0x6000010f9380 {Error Domain=AMSErrorDomain Code=100 "Authentication Failed" UserInfo={NSLocalizedFailureReason=The verify credentials call failed., NSLocalizedDescription=Authentication Failed, NSUnderlyingError=0x6000010f9290 {Error Domain=AMSErrorDomain Code=6 "Authentication Failed" UserInfo={NSLocalizedFailureReason=User cancelled, NSLocalizedDescription=Authentication Failed, NSUnderlyingError=0x6000010f9470 {Error Domain=AMSErrorDomain Code=15 "An unknown error occurred. Please try again." UserInfo=0x600001db3a60 (not displayed)}}}}}, NSLocalizedFailureReason=An unknown error occurred, NSLocalizedDescription=Unhandled exception}
  • 2022-01-30 13:32:32.529197-0800 [Purchases] - ERROR: 🍎‼️ SKRequest failed: The operation couldn’t be completed. (SKErrorDomain error 2.)
  • 2022-01-30 13:32:32.530185-0800 [Purchases] - WARN: 🍎‼️ Unable to load receipt, ensure you are logged in to a valid Apple account.

 

 


cody
RevenueCat Staff
Forum|alt.badge.img+8
  • RevenueCat Staff
  • 497 replies
  • Answer
  • February 1, 2022

Hey @fra!

This is prompting for a sign-in because if we don’t find an existing receipt on the device, we’ll automatically fetch it - and when fetching a receipt from the App Store in the case of a receipt not existing, a sign-in is required. This is currently expected behavior (implementation, `refreshPolicy: .onlyIfEmpty`), so you’ll want to be sure you are calling this method at a time where it is appropriate for a user to potentially sign in.

This typically won’t occur in production as production installs almost always have a receipt available, and so the SDK doesn’t have to fetch it.


Reply


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