amountMicros price is zero on iOS target

[alaegin]

• [x] I have updated Purchases SDK to the latest version
• [x] 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 Since I migrated the KobanKat to Purchases the amountMicros from StoreProduct.price.amountMicros became zero. The same code works well on Android, also it worked on iOS before the migration.

StoreProduct.price.formatted works well on both Android and iOS targets.

1. Environment
   1. Platform: iOS
   2. SDK version: 1.0.0-beta.3
   3. OS version: 17.4.1
   4. IDE (e.g. Android Studio, Xcode, Fleet): Android Studio
   5. IDE version: 2024.1.2 Canary 7
   6. Device and/or emulator/simulator:
      • [x] Device
      • [ ] Emulator/simulator
   7. Environment:
      • [x] Closed testing / Sandbox
      • [ ] TestFlight
      • [ ] Production
   8. How widespread is the issue. Percentage of devices affected.
2. Debug logs that reproduce the issue
3. Steps to reproduce, with a description of expected vs. actual behavior
4. Other information (e.g. stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, etc.)

Additional context

[JayShortway]

Hi, thanks for reporting this issue! (And thanks for being an early KobanKat user 😄) We'll have a look at this.

[JayShortway]

I did a quick check and unfortunately it doesn't reproduce on my end.

What's the price you expect to see, and which currency? Do you have the exact same price configured in the Play Console as in App Store Connect?

[alaegin]

I expect to see euro prices for three different SKUs. I don't have the same prices for Android and iOS.

---

I noticed that if I downgrade to beta.2 the amountMicros works as expected. It gave me the idea that something is wrong with beta.3 or my integration due to migration to StoreKit 2 that was made in beta.3.

So, if I change storeKitVersion in beta.3 config to STOREKIT_1 then it works fine.

val config = PurchasesConfiguration(
    apiKey = billingConfig.revenueCatApiKey,
) {
    verificationMode = EntitlementVerificationMode.INFORMATIONAL
    storeKitVersion = StoreKitVersion.STOREKIT_1
}

---

The migration guide says: In-App Purchase Key Required for StoreKit 2. I checked it – I already did before and the credentials are valid as the dashboard says.

[JayShortway]

Thank you! That's a good lead indeed! It looks like it's related to StoreKit 2.

I discussed with the team, and we came up with some more questions to try and get to the bottom of this:

1. I see you ticked "Device". Does it not occur at all on a simulator, or did you not try it on a simulator?
   1. If you have tried a simulator, and it indeed doesn't happen there, are you using a StoreKit config file in that scenario?
2. You mentioned that StoreProduct.price.formatted works fine (on both platforms). Does everything else load fine too? I'm talking about Offerings, Packages and StoreProducts. Is it just the amountMicros that's failing?
3. Which version of PurchasesHybridCommon have you specified in your Podfile or build.gradle.kts? This should be 13.0.1 for beta.3. The SDK checks this at runtime, so I don't think this value can be wrong, but good to double check just in case.
4. Lastly, it would be helpful if you can share your app bundle ID if you're comfortable with that. That we can have a look on our end to do some more digging. If you don't want to share it publicly, feel free to send it to me via Twitter DM (same username). If you don't want to share it at all, that's also fine of course.

[alaegin]

@JayShortway Thank you for investigating this.

1. I didn't try it on a simulator because my app doesn't work on a simulator due to some library that doesn't support arm architecture. (Maybe I'm not good at iOS)

2. I use awaitGetProducts and awaitOfferings in my implementation. Both of them return expected products with expected price (I can click the button and Apple In App Purchase menu opens with correct price and SKU). For now, I don't see anything that doesn't work except amountMicros in StoreProduct.

3. Its 13.0.1 pod 'PurchasesHybridCommon', '13.0.1'

4. app.lumosart

[JayShortway]

Thank you for providing this information. That's very helpful! I'm still investigating this, but haven't found anything definitive yet.

In the meantime, what does StoreProduct.price.currencyCode return for you? Is that what you'd expect?

[JayShortway]

Also, could you double check your language and region settings in the device settings? Maybe even change your region to something else, and back again to what you want it to be? There's some indication it's related to formatting and locales, so just want to rule this out.

[alaegin]

@JayShortway Hello!

In the meantime, what does StoreProduct.price.currencyCode return for you? Is that what you'd expect?

Yes, it returns EUR

Here are all properties from the StoreProduct object of one SKU from my app:

title: 30 credits
id: app.lumosart.credits_30
type: INAPP
price.amountMicros: 0
price.currencyCode: EUR
price.formatted: 2,99 €

All are correct except the amountMicros

[JayShortway]

Thank you! I still haven't been able to reproduce it, but I have a speculative fix in mind. (See the 2 PRs linked above.) My confidence in that fix would be a little higher if the currencyCode you're seeing was also wrong, but it still can't hurt.

We're gearing up for the stable 1.0.0 release. I'm not entirely sure if the speculative fix will be in that version. If it isn't, it will be in the version released the following week. I'll keep you posted.

[JayShortway]

This is gonna be in 1.0.0 as both PRs have been merged already.

[JayShortway]

The stable release was just published. I'm curious to hear whether the speculative fix improved the situation, whenever you have time to update!

[alaegin]

@JayShortway Thank you! I'll try it soon (in a day or so) and post the update

[JayShortway]

@alaegin Sure, no rush!

[alaegin]

Good evening, @JayShortway!

I'd like to say that the issue has gone with the 1.0.0 update. I'll be testing it further but as for now, I can't see any issues.

Great work! Thank you!

[JayShortway]

@alaegin I'm very happy to read that! Thanks for confirming!