I am preparing the first release of my iOS game, Ippon Battle, and testing it on my own physical devices through TestFlight. I am looking for a supported workaround or further diagnostics for inconsistent product prices, and guidance on whether the same behavior can occur in production.
Feedback report: FB25378742 (filed October 31, 2026; currently Open). Apple Developer Support directed me to Feedback Assistant for bug reporting and these forums for technical help. The feedback report includes screenshots and the app-specific identifiers.
- iPhone 15, iOS 27.0.1 (24A446).
- App version 1.7.11; raw catalog diagnostics were captured in TestFlight build 41.
- Two non-consumable products:
ipponbattle.fighters5(Japan: JPY 300) andipponbattle.story(Japan: JPY 400). - The Sandbox account is configured for Japan. The iPhone diagnostic reported Storefront country JPN and currency JPY.
- Japan prices were independently read-verified through the App Store Connect API on October 21, 2026. I have not changed prices as a troubleshooting step.
For each exact product ID, native StoreKit calls returned:
Product.products(for:): price = 1.99, priceFormatStyle.currencyCode = USD
SKProductsRequest: price = 1.99, priceLocale currency = USD
This occurred for BOTH products, despite their different configured Japanese prices. The original in-game shop displayed $1.99 for each. The fighter pack's Apple purchase confirmation sheet showed JPY 300.
On a second physical device, an iPad running TestFlight build 44, a screenshot shows the story product at $1.99 in the shop behind Apple's purchase sheet showing JPY 400. The sheet explicitly identifies it as a test purchase with no charge. I did not capture raw storefront/API diagnostics on that iPad, so I am not assuming its internal storefront state was identical to the iPhone trace.
Both products were successfully test-purchased in earlier tests. Restoration and ownership after relaunch also worked. The issue is the product metadata price/currency, rather than an inability to complete a purchase.
- Install the app through TestFlight and use the Japan-configured Sandbox account.
- Request the two product IDs with
Product.products(for:)and inspect the returned product IDs, price, priceFormatStyle.currencyCode, and displayPrice alongside the current Storefront. - Independently request the same IDs through
SKProductsRequestand inspect price and priceLocale. - Compare those values with the configured Japan prices and Apple's purchase confirmation sheet.
- Signing out of the Apple account did not resolve the problem.
- Product data is matched by product ID, not response order. There is no fixed USD fallback or persistent price cache in the app.
- The TestFlight build does not use a local StoreKit configuration file. These are native API results, not simulated UI test responses.
- The app refreshes product information when the shop opens and clears old quotes on refresh, failure, or storefront changes.
- StoreKit 1 is used only to cross-check catalog data. Purchases, transaction verification, and restoration remain on StoreKit 2.
- As a temporary mitigation for this Japan-only app, prices that cannot be verified as JPN/JPY are hidden. I do not relabel USD amounts as yen, convert them, or substitute hard-coded JPY prices. This prevents the misleading display but does not solve retrieval of the correct catalog prices.
- Is a mismatch between StoreKit product metadata and the purchase sheet a known TestFlight/Sandbox behavior? Is there any supported way to determine whether production is affected before a first public release?
- What supported recovery or refresh procedure should I try to retrieve prices consistent with the purchase sheet, beyond re-requesting products and signing out/in?
- What additional diagnostics, logs, or reproduction details would help the StoreKit team investigate FB25378742?
I found a similar report, but I do not know whether it has the same cause. I have not isolated the cause to the catalog service, OS, or account.
Thank you.