Bug: CheckTrialOrIntroDiscountEligibility too slow #1893

jesus-mg-ios · 2022-09-08T11:40:32Z

I have updated Purchases SDK to the latest version
[-] I have read the Contribution Guidelines
[X ] I have searched the Community
[ X] I have read docs.revenuecat.com
[ X] I have searched for existing Github issues

Describe the bug
Add any other context about the problem here.

We are using checkTrialOrIntroDiscountEligibility in iOS with swift after get the product, and we notice that this call is too slow (even 45s - 1 min).

Purchases.shared.checkTrialOrIntroDiscountEligibility(productIdentifiers: ["productIdentifier"]) { result in
....
}

Environment
1. Platform: iOS
2. SDK version: 4.10
3. StoreKit 2 (enabled with useStoreKit2IfEnabled) (Y/N): N
4. OS version: 15.5
5. Xcode version: 13.4.1
6. How widespread is the issue. Percentage of devices affected: Unknown/Random
  Additional context

Environment: Real device & simulator. iOS 15.5
SDK Version: "4.10.0"
Code that is too slow

Purchases.shared.checkTrialOrIntroDiscountEligibility(productIdentifiers: ["productIdentifier"]) { result in
....
}

The text was updated successfully, but these errors were encountered:

RCGitBot · 2022-09-08T11:40:47Z

👀 SDKONCALL-120 We've just linked this issue to our internal tracker and notified the team. Thank you for reporting, we're checking this out!

aboedo · 2022-09-08T12:02:24Z

Thanks for reporting!
I get the feeling that the problem is actually coming from StoreKit 2.

Currently we use StoreKit 2 for this particular API regardless of whether usesStoreKit2IfAvailable is true, because with StoreKit 1, intro eligibility calculation is sadly a "best guess" approach, since it's not technically possible to get an accurate value for all edge cases with StoreKit 1.

Could you share the debug logs for your device?
We might try allowing you to disable SK2 for this particular feature, would you be open to trying that out using a branch from our SDK?

… explicitly enabled Temporary change to debug #1893.

aboedo · 2022-09-08T19:07:13Z

@jesus-mg-ios would you mind trying out the branch intro-eligibility-checker-sk1 from this PR to see if you get better results? #1894

It just disables SK2 for this particular operation.

Let me know if you need any instructions for using the SDK from that branch

jesus-mg-ios · 2022-09-08T21:34:13Z

Thanks, I'm gonna try it!

stale · 2022-09-15T23:39:28Z

This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Please reach out if you have additional information to help us investigate further!

jesus-mg-ios · 2022-09-20T18:53:04Z

Hi @aboedo, the change was amazingly faster.

We're gonna share with you the logs before and
after the change.

RevenueCatLogsBeforeFixBranch_4_11_0 copy.txt

RevenueCatLogsAfterFixBranch_4_12_0 copy.txt

aboedo · 2022-09-20T19:05:28Z

@jesus-mg-ios thanks for getting back to us.

This confirms that the issue is StoreKit 2's underlying API being very slow for this...

Which is frankly unfortunate because it's the only one that's technically guaranteed to be perfectly accurate (with StoreKit 1, 100% accuracy for intro eligibility is technically not possible 🤕). It will still be correct for the vast majority of use cases, though.

We're going to think about the best way to provide flexibility for this API.

cc @NachoSoto

stale · 2022-09-27T21:14:56Z

This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Please reach out if you have additional information to help us investigate further!

jesus-mg-ios · 2022-10-05T14:20:04Z

@aboedo we're experimenting delays also in the simulator (with no appleid configured and not Apple ID signed in).
Is it expected?

cc: @unxavi

timfraedrich · 2022-10-07T13:34:25Z

We are also experiencing this issue, might it be possible to request and cache the eligibility properties together with the offerings on app start? From my understanding the values should not change except if a product is purchased at which point RevenueCat should know about it and could invalidate the cache. I may be missing something here though.

tcwalther · 2022-10-14T13:16:17Z

@timfraedrich I just came here because of the same issue - being able to cache offerings and eligibility would be great. Afaics this would require making RevenueCat.Package conform to Codable.

NachoSoto · 2022-10-14T16:07:27Z

Afaics this would require making RevenueCat.Package conform to Codable.

Caching eligibility totally makes sense. But this approach wouldn't be trivial / possible. Package has StoreProducts, which have underlying StoreKit products we can't fully serialize.

jesus-mg-ios · 2022-10-14T17:26:37Z

And it is possible to use a configuration parameter to disable (opt), the case that @aboedo reverted? I think that solve our problem for now. @NachoSoto . At this moment we have not require a 100% of accuracy in this.

tcwalther · 2022-10-14T17:35:33Z

@NachoSoto afaics one can encode at least an SK2Product using jsonRepresentation, but I can't see how to decode it again.

I think in general though, being able to cache as much as possible of the pricing would be highly desirable. In our app, for example, we just added a lock screen widget that on the free version just sends a user to a paywall. That could very well happen from a cold start, and it would be great if we could display prices instantly.

aboedo · 2022-10-14T20:00:33Z

Hey folks, thanks for the feedback!
We're discussing best approaches here. Caching is possible, although like all caching things it's not trivial and we'd want to get it right. So we'll add it, but I don't have an ETA for that yet and it might take us a bit longer to get to it.

In the meantime, we're also discussing the possibility of reusing the useSK2IfAvailable flag that's available when configuring the SDK to control the implementation of this method too. That would provide a low-risk solution that's easy to add on our side. We'll keep you posted!

… enabled This used to always default to the SK2 implementation if it was available because it was much more reliable. However, as we've learned (#1893), it can be significantly slow. Until we implement caching for it ([CSDK-493]), this for now allows users to disable it if it's too slow. For users that don't specify `useSk2IfAvailable`, SK2 is now the new default, so this class will continue to use the "better" implementation for them too.

… enabled (#1984) This is similar to #1894, but as a permanent change. This used to always default to the SK2 implementation if it was available because it was much more reliable. However, as we've learned (#1893), it can be significantly slow. Until we implement caching for it ([CSDK-493]), this for now allows users to disable it if it's too slow. For users that don't specify `useSk2IfAvailable`, SK2 is now the new default, so this class will continue to use the "better" implementation for them too. [CSDK-493]: https://revenuecats.atlassian.net/browse/CSDK-493?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

stale · 2022-10-21T20:20:46Z

This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Please reach out if you have additional information to help us investigate further!

aboedo · 2022-10-21T20:30:29Z

Update here: we've updated checkTrialOrIntroDiscountEligibility so that it uses our StoreKit 1 implementation if useSK2IfEnabled = false.
This will go out very soon in release 4.13.3, PR is here #1988

NachoSoto · 2022-10-24T16:05:00Z

I also filed CSDK-493 to add a caching mechanism to TrialOrIntroPriceEligibilityChecker.

stale · 2022-11-01T09:38:41Z

This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Please reach out if you have additional information to help us investigate further!

…ons` This changes the default back to `StoreKit 1`. We decided to do this for the following reasons: - Purchasing with `PromotionalOffer`s does not work with StoreKit 2 due to an Apple bug (see #2020 (comment)) - `checkTrialOrIntroDiscountEligibility` is significantly slower with StoreKit 2 (#1893). We're adding optimizations to help with that (#2007), but the underlying logic will still be slow. - A rare race-condition where `StoreKit 2` does not have transactions after a purchase ([TRIAGE-82]). We have some workarounds (#1945), but it's still being investigated. _ Note: This effectively reverts 0ee540a. That commit made it easier to only change the default in one place which is why this PR is basically just one line._

…ons` (#2022) This changes the default back to `StoreKit 1`. We decided to do this for the following reasons: - Purchasing with `PromotionalOffer`s does not work with StoreKit 2 due to an Apple bug (see #2020 (comment)) - `checkTrialOrIntroDiscountEligibility` is significantly slower with `StoreKit 2` (#1893). We're adding optimizations to help with that (#2007), but the underlying logic will still be slow. - A rare race-condition where `StoreKit 2` does not have transactions after a purchase ([TRIAGE-82]). We have some workarounds (#1945), but it's still being investigated. _Note: This effectively reverts 0ee540a. That commit made it easier to only change the default in one place which is why this PR is basically just one line._ [TRIAGE-82]: https://revenuecats.atlassian.net/browse/TRIAGE-82?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

aboedo · 2022-11-09T13:19:22Z

Final update here: the implementation of checkTrialOrIntroDiscountEligibility will now respect the preference for useStoreKit2IfAvailable.
Our latest release uses StoreKit 1 by default, which is the speedy implementation. So this should no longer be a problem by default, and if you're setting useStoreKit2IfAvailable to true, changing the value to false should solve it.

github-actions · 2022-11-17T00:23:54Z

This issue has been automatically locked due to no recent activity after it was closed. Please open a new issue for related reports.

jesus-mg-ios added the bug label Sep 8, 2022

NachoSoto added a commit that referenced this issue Sep 8, 2022

[DO NOT MERGE] TrialOrIntroPriceEligibilityChecker: only use SK2 if…

0ad5083

… explicitly enabled Temporary change to debug #1893.

NachoSoto mentioned this issue Sep 8, 2022

[DO NOT MERGE] TrialOrIntroPriceEligibilityChecker: only use SK2 if explicitly enabled #1894

Closed

stale bot added the status: waiting-for-reply Issues that are waiting for a reply label Sep 15, 2022

stale bot removed the status: waiting-for-reply Issues that are waiting for a reply label Sep 20, 2022

stale bot added the status: waiting-for-reply Issues that are waiting for a reply label Sep 27, 2022

aboedo removed the status: waiting-for-reply Issues that are waiting for a reply label Sep 29, 2022

NachoSoto mentioned this issue Oct 14, 2022

TrialOrIntroPriceEligibilityChecker: only use SK2 implementation if enabled #1984

Merged

stale bot added the status: waiting-for-reply Issues that are waiting for a reply label Oct 21, 2022

stale bot removed the status: waiting-for-reply Issues that are waiting for a reply label Oct 21, 2022

NachoSoto mentioned this issue Oct 28, 2022

Created CachingTrialOrIntroPriceEligibilityChecker #2007

Merged

stale bot added the status: waiting-for-reply Issues that are waiting for a reply label Nov 1, 2022

NachoSoto mentioned this issue Nov 4, 2022

Changed StoreKit2Setting.default back to .enabledOnlyForOptimizations #2022

Merged

stale bot closed this as completed Nov 9, 2022

github-actions bot locked and limited conversation to collaborators Nov 17, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bug: CheckTrialOrIntroDiscountEligibility too slow #1893

Bug: CheckTrialOrIntroDiscountEligibility too slow #1893

jesus-mg-ios commented Sep 8, 2022

RCGitBot commented Sep 8, 2022 •

edited by jira bot

Loading

aboedo commented Sep 8, 2022

aboedo commented Sep 8, 2022 •

edited

Loading

jesus-mg-ios commented Sep 8, 2022

stale bot commented Sep 15, 2022

jesus-mg-ios commented Sep 20, 2022

aboedo commented Sep 20, 2022

stale bot commented Sep 27, 2022

jesus-mg-ios commented Oct 5, 2022 •

edited

Loading

timfraedrich commented Oct 7, 2022

tcwalther commented Oct 14, 2022

NachoSoto commented Oct 14, 2022

jesus-mg-ios commented Oct 14, 2022 •

edited

Loading

tcwalther commented Oct 14, 2022

aboedo commented Oct 14, 2022

stale bot commented Oct 21, 2022

aboedo commented Oct 21, 2022

NachoSoto commented Oct 24, 2022 •

edited by jira bot

Loading

stale bot commented Nov 1, 2022

aboedo commented Nov 9, 2022

github-actions bot commented Nov 17, 2022

Bug: CheckTrialOrIntroDiscountEligibility too slow #1893

Bug: CheckTrialOrIntroDiscountEligibility too slow #1893

Comments

jesus-mg-ios commented Sep 8, 2022

RCGitBot commented Sep 8, 2022 • edited by jira bot Loading

aboedo commented Sep 8, 2022

aboedo commented Sep 8, 2022 • edited Loading

jesus-mg-ios commented Sep 8, 2022

stale bot commented Sep 15, 2022

jesus-mg-ios commented Sep 20, 2022

aboedo commented Sep 20, 2022

stale bot commented Sep 27, 2022

jesus-mg-ios commented Oct 5, 2022 • edited Loading

timfraedrich commented Oct 7, 2022

tcwalther commented Oct 14, 2022

NachoSoto commented Oct 14, 2022

jesus-mg-ios commented Oct 14, 2022 • edited Loading

tcwalther commented Oct 14, 2022

aboedo commented Oct 14, 2022

stale bot commented Oct 21, 2022

aboedo commented Oct 21, 2022

NachoSoto commented Oct 24, 2022 • edited by jira bot Loading

stale bot commented Nov 1, 2022

aboedo commented Nov 9, 2022

github-actions bot commented Nov 17, 2022

RCGitBot commented Sep 8, 2022 •

edited by jira bot

Loading

aboedo commented Sep 8, 2022 •

edited

Loading

jesus-mg-ios commented Oct 5, 2022 •

edited

Loading

jesus-mg-ios commented Oct 14, 2022 •

edited

Loading

NachoSoto commented Oct 24, 2022 •

edited by jira bot

Loading