purchases-ios: Bug: CheckTrialOrIntroDiscountEligibility too slow
- 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
- Platform: iOS
- SDK version: 4.10
- StoreKit 2 (enabled with
useStoreKit2IfEnabled) (Y/N): N - OS version: 15.5
- Xcode version: 13.4.1
- 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
....
}
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 1
- Comments: 21 (9 by maintainers)
Commits related to this issue
- [DO NOT MERGE] `TrialOrIntroPriceEligibilityChecker`: only use SK2 if explicitly enabled Temporary change to debug #1893. — committed to RevenueCat/purchases-ios by NachoSoto 2 years ago
- `TrialOrIntroPriceEligibilityChecker`: only use SK2 implementation if enabled This used to always default to the SK2 implementation if it was available because it was much more reliable. However, as ... — committed to RevenueCat/purchases-ios by NachoSoto 2 years ago
- `TrialOrIntroPriceEligibilityChecker`: only use SK2 implementation if enabled (#1984) This is similar to #1894, but as a permanent change. This used to always default to the SK2 implementation if ... — committed to RevenueCat/purchases-ios by NachoSoto 2 years ago
- Changed `StoreKit2Setting.default` back to `.enabledOnlyForOptimizations` This changes the default back to `StoreKit 1`. We decided to do this for the following reasons: - Purchasing with `Promotiona... — committed to RevenueCat/purchases-ios by NachoSoto 2 years ago
- Changed `StoreKit2Setting.default` back to `.enabledOnlyForOptimizations` (#2022) This changes the default back to `StoreKit 1`. We decided to do this for the following reasons: - Purchasing with `... — committed to RevenueCat/purchases-ios by NachoSoto 2 years ago
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
useSK2IfAvailableflag 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!@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.Packageconform toCodable.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.