Purchases.getOfferings() performance issue #755
Comments
|
👀 We've just linked this issue to our internal tracker and notified the team. Thank you for reporting, we're checking this out! |
|
Thanks for the report. Could you please share logs when you reproduce this issue? Verbose logs would really help: Please make sure they include everything starting from SDK initialization. Thanks! |
|
Sure! Here are the RC logs on app opening: Note:
|
NachoSoto
added a commit
to RevenueCat/purchases-ios
that referenced
this issue
Oct 23, 2023
`ProductFetcherSK1` had 2 public methods for fetching products: `products(withIdentifiers:completion:)` and `sk1Products(withIdentifiers:completion:)`. Only one of them was using `TimingUtil` to log slow requests, and that one happened to not be used by `ProductsManager`, which means that we weren't getting these logs. This is evident in RevenueCat/react-native-purchases#755. With this change, we'll now be able to see how long the product request took.
|
Thanks for that! I just realized that with StoreKit 1 product requests we weren't correctly logging a warning if the product request takes too long. I fixed that in RevenueCat/purchases-ios#3327. Unfortunately there isn't much we can do to optimize fetching products from StoreKit. 56 products is indeed a lot of products. We'll make a new release with those logs so we can confirm that indeed this slowness is coming from there. Can you explain your setup? We'd love to understand your motivation and use case for having ~15 offerings and 56 products to be able to think about how to best address this. Thanks! |
|
Thank you for your response! We have multiple offerings segmented by gender and age since we're working on a dating app. On top of that, we occasionally conduct in-house A/B testing, which accounts for the extensive number of products. The issue I'm facing is that I already know which offering I intend to display in the paywall, thanks to a specific route on our server ( Currently, my code looks like this: const offeringId = await getOfferingFromServer(userId);
const offerings = await Purchases.getOfferings();
return offerings.all[offeringId];Ideally, I'd prefer something more efficient like the following to reduce the data fetch overhead: const offeringId = await getOfferingFromServer(userId);
const offering = await Purchases.getOffering(offeringId);
return offering; |
NachoSoto
added a commit
to RevenueCat/purchases-ios
that referenced
this issue
Oct 24, 2023
`ProductFetcherSK1` had 2 public methods for fetching products: `products(withIdentifiers:completion:)` and `sk1Products(withIdentifiers:completion:)`. Only one of them was using `TimingUtil` to log slow requests, and that one happened to not be used by `ProductsManager`, which means that we weren't getting these logs. This is evident in RevenueCat/react-native-purchases#755. With this change, we'll now be able to see how long the product request took.
NachoSoto
added a commit
to RevenueCat/purchases-ios
that referenced
this issue
Oct 25, 2023
`ProductFetcherSK1` had 2 public methods for fetching products: `products(withIdentifiers:completion:)` and `sk1Products(withIdentifiers:completion:)`. Only one of them was using `TimingUtil` to log slow requests, and that one happened to not be used by `ProductsManager`, which means that we weren't getting these logs. This is evident in RevenueCat/react-native-purchases#755. With this change, we'll now be able to see how long the product request took.
|
That makes sense 👍🏻 |
|
Same issues, hope we can make it faster ASAP. Thanks for every effort! |
|
Same issue |
|
Same issue! |
|
Any news? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
On IOS devices calling
Purchases.getOfferings()is extremely slow. For exemple it takes up to 10 seconds on the Iphone 14 I have under my eyes. At least when called for the first time.Environment
Debug logs that reproduce the issue
Not relevant
Steps to reproduce, with a description of expected vs. actual behavior
Other information (e.g. stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, etc.)
I must say that I have about fifteen different offerings. And I am calling this method right after SDK setup in order to display a paywall on app opening.
Not tested on Android yet.
The text was updated successfully, but these errors were encountered: