Solved

StoreProduct PriceFormatter issues with StoreKit 2

  • 2 December 2022
  • 3 replies
  • 231 views

Badge +5

Hiya! Our paywall screen has a “[currency]0.00” — free option, with the currency based on offering?.availablePackages.first?.product.priceFormatter?.locale.

 

With StoreKit 1, this properly returns the expected, matching locale, like Optional(en_US@currency=INR (fixed))

But now that we’re starting to test out StoreKit 2 support, we get back Optional(en_US (autoupdatingCurrent))

...when using a .storekit file with the storefront changed via Editor > Default Storefront. We can also reproduce this on device.

 

It’s unclear to me if this would be a RevenueCat or a StoreKit 2 bug?

icon

Best answer by sharif 6 December 2022, 19:18

View original

3 replies

Userlevel 5
Badge +9

Hello! We’ve seen StoreKit 2 bugs to the extent that you should probably default to StoreKit 1. However, in this specific instance, I’m not sure if this is just something specific to the StoreKit test framework or something attributable to StoreKit 2. Is there a reason you’re moving to StoreKit 2?

Userlevel 5
Badge +9

Quick update here from our mobile engineers, this is expected behavior because StoreKit 2 doesn’t provide a price formatter like StoreKit 1 does, so we create one with autoupdatingCurrent and currency. Let us know if you run into any issues with it!

Badge +5

Hey, thanks for the update! Yeah, we’re certainly still defaulting to StoreKit 1 — we introduced a feature flag locally to test the waters.

> this is expected behavior because StoreKit 2 doesn’t provide a price formatter

 

:( Good to know, suppose I’ll file a feedback with Apple. Thanks!

The reason why this doesn’t work is because what we’d need is a locale that is used with the App Store, i.e. the locale of the Apple ID, rather than the user’s actual locale used on the device.

Is there a reason why RevenueCat is still exposing this in StoreKit 2 rather than omitting it, like Apple has done?

Reply