Around September the 3rd, developers started receiving a notice from Apple about the upcoming currency change in Croatia.


Starting next year, Croatia will adopt the euro (EUR) as its official currency, replacing the Croatian kuna (HRK). In accordance with this transition, the pricing for apps and in-app purchases on the App Store in Croatia will change from the kuna to the euro on January 1, 2023. Price tiers will be converted to euros using the statutory fixed conversion rate of 7.53450 HRK = 1.00000 EUR established by the Council of the European Union on July 12, 2022.

For in-app purchases, per the Act on introduction of Euro as official currency in the Republic of Croatia, you’ll need to communicate the statutory fixed conversion rate of 7.53450 HRK = 1.00000 EUR, and both the kuna and euro prices, within your app to customers for the duration of the transitional period from September 5, 2022, to December 31, 2023. This messaging should appear anywhere prices are displayed.

Please note the following will automatically update from kunas to euros on January 1, 2023 and require no action on your part: Prices. Customers with auto-renewable subscriptions will be notified. Your proceeds from sales in Croatia. Your Sales and Trends reports and monthly financial reports for Croatia. If you’ve selected the kuna, the currency for your bank in App Store Connect.


A short call to action notice with a brief list of requirements that should be fulfilled starting on September the 5th. Yes, you’ve read that right, a two days notice. It’s pretty clear Apple was also caught off guard by this since Council of the European Union made the decision on July the 12th, 2022.

Okay, what now?

What this means for us developers? Will Apple take down apps that are not ready just yet to comply with the new regulation? Hardly. Will they reject the submissions of updates and a new apps that are being sold in Croatia but not displaying prices in both the Croatian Kuna and Euro? They actually might to comply with the new regulations. There aren’t a lot of information around and the questions are many. If you don’t want to risk having your apps rejected at some point during the review, keep reading to find out how I tackled the problem.

It doesn’t look like there will be any additional support from Apple regarding the matter like an API with the automated display of dual pricing. As reported, prices in Croatian Kuna will automatically convert to EUR on Jan the 1st 2023. But until then, it seems like we should update our prices manually in the app for the Croatian storefront. Luckily, there’s a fixed conversion rate so all we have to do is to show that rate and calculate the EUR prices. Apple published a table showing the current prices in Croatia in Kuna and the converted prices in EUR. But if we look just at the first two price tiers, they don’t quite match the agreed conversion rate. Showing the conversion rate and the converted prices that don’t match it doesn’t seem correct. So this published prices must be the prices effective from the Jan 1st, 2023.

As prices come from the backend (right? 😃) and the price tiers are also subject to change, I decided the best way to do it would be to simply calculate the prices manually using the fixed conversion rate. That is, after detecting the prices displayed to a user are in Croatian Kuna.

Detecting the storefront

Before playing with different storefronts, it’s a good idea to create multiple testing accounts on the App Store Connect and assign them different countries you wish to test with. You can do so even for the existing testing accounts under Users and Access > Sandbox > Testers. Just keep in mind that you’ll have to log out with that tester account on your machine first for changes to take effect.

And this option is probably not somewhere you would expect it on a Mac. Open the Mac App Store app and under Preferences there’s info about the Sandbox account you’re currently using and a Log Out button. Hit it and the next time you try to make a purchase in your development-signed app, a popup will appear asking you to log in with a Sandbox account.

One thing that keeps bugging me for Sandbox accounts are the constant popups about upgrading account security with 2 factor authentication. Let’s be clear, 2FA is an awesome thing, but I don’t see this type of accounts really need it. Luckily, it’s not mandatory so on the popup choose Other options and then Do not upgrade.

There’s a new StoreFront API which you could use to detect the storefront.

Something like

await Storefront.current?.countryCode

will return HRV for the Croatian storefront or for example, USA for United States.

The problem is, there’s no guarantee that prices in Croatian storefront will be in Croatian Kuna. Additionally, as this is a relatively new API, requirement for macOS 12.0 and iOS 15.0 made it go out of the consideration for my case.

So I figured my best bet would be just to check if the SKProduct prices are in Croatian Kuna after loading.

Detecting the prices

After loading the SKProduct list from the StoreKit API, it’s pretty simple to check if the price is in Croatian Kuna (HRK symbol):

product.priceLocale.currencySymbol == "HRK"

If it is, we can simply calculate the price in EUR using the fixed conversion rate 7,53450 HRK = 1,00000 EUR.

let fixedKunaEuroConversionRate = 7.53450
let euroPrice = product.price.doubleValue / fixedKunaEuroConversionRate

What’s left is to display them properly.

The UI

Now the interesting part. My UI was already pretty packed with the content.

Popcorn Prices in Croatian Kuna

Since this screen is not something very suitable for scrolling, I had to add prices in Euro and a label with conversion rate somehow without changing the layout too much.

As a fan of simple solutions, I opted for showing prices in EUR inline next to the prices in HRK and for an additional conversion rate label below everything.

Popcorn Prices in both Croatian Kuna and Euro

Prices in EUR we calculated are formatted using NumberFormatter which does the rounding, adds the EURO symbol and most importantly, the correct decimal separator.

let formatter = NumberFormatter()
formatter.numberStyle = .currency
formatter.currencyCode = "EUR"
let euroPriceString = formatter.string(from: price)

Additionally, when the prices in HRK are detected, I just unhide the conversion rate text label. Notice the comma as a decimal separator here. This is the correct decimal separator style for currency in Croatia while the decimal point is just a number separator. Using the NumberFormatter is usually the best idea, but if you want to cut a few corners, feel free to just hardcode the conversion rate in a label as this is the only country in the world we’re making adjustments for.

Without changing the layout too much, this was the quickest and the most effective solution. Maybe not the most visually pleasant one but it should hopefully do the trick for this few months of a transitioning period.

Bonus points

The prices from the StoreKit API will automatically change to EUR currency on Jan 1st 2023. By directly checking whether the current price is in Croatian Kuna, we’re also covering that future scenario. As that check will not go through, the converted prices and the conversion rate label won’t be shown so the App won’t need an update for this sole adjustment.

The screen should like it currently does for other EU countries using EUR currency.

Popcorn Prices in Euro

Notice how App Store prices in EUR are not exactly the same as converted ones.

Conclusion

As Croatia is switching Croatian Kuna for Euro as a main currency, a Council of the European Union made a decision of a transitioning period during which all prices in Croatia should be displayed both in Kuna and Euro using the statutory fixed conversion rate. Since Apple apparently got caught off guard by that, these requirements ended up being a sole responsibility of a developer. By not having much info or support from the official API, we’re left to implement them manually.

Luckily, it shouldn’t be hard once you figure out what exactly you need to do. I opted for the quickest solution without too many UI layout interventions as this change is only temporary during this transitioning period.

If you decide to take a different approach, don’t forget to conditionalize the prices and a conversion rate label so you don’t need another update when the final transition takes place. This is how I did it for my Mac app, but iOS apps should follow the similar principles. Also, if you’re aware of something I’m not, let me know on Twitter.