Skip to main content
Question

checkTrialOrIntroDiscountEligibility caching

  • 13 June 2024
  • 2 replies
  • 44 views

I’m using the `await Purchases.shared.checkTrialOrIntroDiscountEligibility(product:)` method to check if a user is eligible for the intro offer of a product. I noticed that while the result of this method seems to be cached between calls, the cached values do not persist across app launches. This is problematic for us because we need to check intro discount eligibility on app launch, and this significantly slows down or app launch times. Since this value should rarely change, is there a way to tell the SDK to do more aggressive caching?

This post has been closed for comments

2 replies

Userlevel 5
Badge +9

Hey @fitbee,

I’ll raise this with the mobile engineering team but for now you could potentially cache the result manually in the device’s local key value storage. The reason it’s not cached is that it’s a computation that happens by parsing the local receipt, rather than being an API request. So you can simply store the last value of that call and update it as needed. The caching strategy that the SDK uses in general is to always return the cached value and update it in the background so that the next call is fresh.

Userlevel 5
Badge +9

Hi @fitbee,

The team informed me that this is indeed the case, since the eligibility check needs to take in new information on every app launch, it isn’t cached by our SDK across launches. Caching it yourself is the way to go, but just be wary that you will want to update your cache often since eligibility can change quickly. You’ll likely want to also tie your cache updates to any updates the SDK gives you, like when calling purchasePackage, login, etc, as all of those can affect eligibility.