Appstore country

Hey @QQQ!

This is a little outside of what I think I can help support with since this is a specific implementation but..

• If you are supporting iOS 13+, you should be able to get it from `SKStoreFront`
• You can also get it from the `priceLocale` on `SKProduct` (which is available on SDK v3 and SDK v4 via the `sk1Product` method)

More info can be found in a Stack Overflow post like this one - https://stackoverflow.com/questions/49368525/ios-knowing-app-store-country

In terms of formatting the price per country, `NumberFormatter` class can format a price string but it takes a country locale (not a country code) so you might have to do some manual mapping if that is what you want to do.

For almost all cases (unless you are doing something highly specific), it is suggested to use the formatting with country locale provided by RevenueCat (and Apple) as that is what the user is most likely expecting based off of their settings 😇 

Hopefully this helps!

Thank you @joshdholtz ,

that was helpful.

Now I am still in sandbox and not logged in in sandbox account. My account is outside US and I got

priceLocale:       en_US@currency=USD (fixed)
store country:     Optional("USA")

I think this is beacuse I am on sandbox, can you please confirm?

Once I log on sandbox account to make the purchase, will I use the US store or my account store?

Also, once I will move in production with no Sandbox, how can I test all is ok on the various stores around the world in regards to price/currency? Just fingers crossed?

Also how is the “standard” behaviour for an app when the appstore country is X, and the user changes the app language to Y, or the ntire phone to Y, where Y has another currency? Are the prices still kept at the original currency as they are proper of the store location of the account?

Thank you.

Hey @QQQ!

Fingers crossed is one way of doing it 🙃 RevenueCat’s pricing formatting is matured and well tested so is should be correct for all currencies and locales in the way Apple has intended it. We have automated tests that do test these different formats. But… sometimes issues do happen but you are also welcome to test them out yourself if you’d like!

You should be able to test all the currencies with sandbox by following the instructions over here - https://developer.apple.com/documentation/storekit/in-app_purchase/testing_in-app_purchases_with_sandbox

And then you can change the language on your device to see how all the different languages change the formatting of the currencies.

It’s a little bit of a manual process to do all of that but I think that’s what you are trying to do! And if you test on sandbox like this you shouldn’t need to test on production because they behave the same 😊 

Thanks!

@joshdholtz ,

that looks promising. Thanks for that!

The problem is that we dont have localizedPriceMonthly on the Flutter SDK.

So we have to calculate and format it ourselves which is very error prone… 

Please, add this simple attribute to the Flutter SDK ASAP

Hi ​@tmaihoff,

I’ve shared your feedback with the SDK team since it’d be a great improvement. In the meantime, you can achieve the same result by using priceString for the price and combining it with the packageType from the Package to determine the billing period (e.g., / month). Alternatively, you can also use subscriptionPeriod from the StoreProduct to format it accordingly.

This should avoid issues or having to hardcode it on your end.

Best,

Hi Joan, 

thanks for forwarding this to the SDK team, i hope this gets implemented fast!

Because it’s not that simpel as you write. 

Ofc, I have the `priceString`, and i know the `subscriptionPeriod`. But I have no possibility to format the calculated monthly price the same way as `priceString` after dividing it by the `subscriptionPeriod`.

e.g:

In Romania, the `priceString` from the SDK is `289,99 RON`.

If i calculate the monthly price, that’s `24.16`.

If I use the flutter build-in currency formatting,

final formatter = NumberFormat.simpleCurrency(name: currencyCode);

final formattedMonthlyPrice = formatter.format(calculatedMonthlyPrice);

the output is: `RON24.16` which differs from the RevenueCat SDK formatting. Not only is the currency symbol at the beginning of the price and misses the whitespace, but the thousand separator is also different. 

Sure, I can try to catch these cases and write workarounds, but as I said, that’s very error-prone and i don’t want to have to this on that very sensible topic pricing when it’s easy to have that value directly from the SDK.

I hope you can value these insights and can push the topic for higher priority.

I would highly appreciate a fast implementation.

Best, 

Tobias