TestFlight: storefront CHE but direct fetchProducts returns USD — safe way to test localized subscriptions?

[kaischoene]

Hi OpenIAP / expo-iap maintainers,

We would appreciate guidance on a TestFlight price/storefront mismatch. We have read the legacy expo-iap issue #126 and the sandbox currency FAQ. We are not assuming this is an SDK bug.

Environment

• Physical iPhone 17 Pro, iOS 26.6 beta.
• TestFlight app version 0.1.0, build 17.
• Expo 57.0.25, React Native 0.86.3, expo-iap 5.3.2.
• The installed expo-iap package pins OpenIAP Apple 3.2.1. We have not independently verified the resolved Podfile.lock from the cloud build.
• Two auto-renewable monthly subscriptions, referred to below as A and B (actual product identifiers omitted).

Observations

App Store Connect was checked read-only on September 28, 2026. Both subscriptions have Switzerland as their only selected sales territory. Current prices for new subscribers are CHF 49.00 (A) and CHF 89.00 (B).

State	Storefront before/after fetch	A displayPrice / currency	B displayPrice / currency
Before signing out of Media & Purchases	USA / USA	$59.99 / USD	$99.99 / USD
After Media & Purchases sign-out and app restart	CHE / CHE	$59.99 / USD	$99.99 / USD

The controlled test signed out only under Media & Purchases, not iCloud, with an existing Swiss sandbox tester configured under Developer settings. Prices and territory configuration were not changed.

In the earlier state, Apple's purchase sheet for A showed EUR 69.99 and the normal Media & Purchases account, with the test-only/no-charge notice. The purchase was not confirmed. There is no purchase-sheet observation in the later CHE state: our app blocks purchase initiation when the Swiss storefront is paired with non-CHF product data.

Diagnostic path already checked

Our read-only diagnostic calls the exported expo-iap.fetchProducts({ skus, type: 'subs' }) function directly and displays displayPrice and currency from that call's return value. It does not read useIAP().subscriptions, persisted UI product state, or a fallback price. It checks getStorefront() before and after the request.

The numeric price field was not recorded in this diagnostic. We have not run an independent native Product.products(for:) probe outside expo-iap/OpenIAP, so we cannot establish whether the mismatch originates in StoreKit or elsewhere in the SDK path. We have not verified production behavior.

Questions

1. Does the documented TestFlight USD-metadata limitation also explain this case where getStorefront() is already consistently CHE after sign-out/restart, but the direct product response remains USD?
2. What is the recommended way to test the localized Swiss purchase flow without substituting a hard-coded CHF price or broadly disabling our price-consistency guard? Is there a supported refresh procedure or different test setup?
3. Is there a relevant known fix for this SDK version? If further evidence is needed, which minimal additional fields or native comparison would you recommend before we build another diagnostic binary?

No purchases were confirmed during these checks. Thank you for helping us distinguish a known sandbox limitation from an actionable SDK issue.

[selmancanklnc]

@kaischoene Great write-up. Here is how I would separate "sandbox limitation" from "SDK issue".

1. Why the storefront and the product currency can disagree in TestFlight

Storefront.current and the product metadata come from two different paths. The storefront updates as soon as the account changes, but StoreKit caches product responses, and TestFlight/sandbox product metadata is not guaranteed to follow the storefront the way production does. The sandbox also does not enforce sales territories the way production does, which is why a Switzerland-only product still comes back at all while the storefront reads USA. So a CHE storefront with USD product data in TestFlight is consistent with the documented limitation. On its own it does not point to an expo-iap bug.

2. The minimal native comparison before another diagnostic build

To rule the SDK in or out, log the same product natively right next to the expo-iap call:

let products = try await Product.products(for: ["<product id A>"])
for p in products {
  print(p.id, p.displayPrice, p.price, p.priceFormatStyle.currencyCode, p.priceFormatStyle.locale.identifier)
}
print(await Storefront.current?.countryCode ?? "nil")

If priceFormatStyle.currencyCode is already USD here, StoreKit is returning it, and expo-iap is only passing it through. If the native call returns CHF while fetchProducts returns USD, that is an actionable SDK issue worth filing, with both outputs attached.

3. Testing the Swiss flow without a hard-coded price or turning off your guard

• Deterministic local test: add a StoreKit configuration file (.storekit) in Xcode, synced from App Store Connect, set its default storefront to Switzerland and its locale to de_CH, and run from Xcode. Product data, currency and the purchase sheet then all come from the chosen storefront, with no network cache involved.
• Keep the guard, but scope it by environment: read AppTransaction.shared and check environment. Enforce the storefront/currency consistency check only when the environment is .production. In .sandbox and .xcode, log the mismatch instead of blocking. That way the guard stays fully active for real users, while TestFlight stops tripping over sandbox metadata.

This keeps your production safety check intact. TestFlight still gets you through the purchase flow, and the .storekit run checks the localized UI.

[hyochan]

Created #503 from this discussion to track the investigation; the cause is still unconfirmed. Thanks @selmancanklnc for suggesting the native comparison.

@kaischoene, please compare native Product.products(for:) with fetchProducts in the same build, including numeric price and currency, and confirm the resolved OpenIAP version in Podfile.lock.

One clarification: .storekit testing validates localized UI, rather than live App Store Connect pricing. For a CHF pricing comparison, try a development-signed build with your Swiss sandbox account and StoreKit Configuration disabled.

[selmancanklnc]

Good clarification, thanks. The .storekit file is a local snapshot, so it proves the localized UI but not what the sandbox actually returns for CHF. The dev-signed build with the Swiss sandbox account is the right check for pricing. I'll follow #503.