Our approved app is held at Pending Developer Release because the production App Store Server API cannot find our notification URL, even though the Production Server URL is saved in App Store Connect. The failure has been constant since August. On October 20 we ran two tests that isolate it, and we would appreciate someone from App Store Server engineering checking the request UUIDs below. What works Sandbox Request a Test Notification, same In-App Purchase key, same bundle ID, same URL string as Production: HTTP 200, token issued, Get Test Notification Status reports sendAttemptResult SUCCESS 280 ms later. 2026-10-20 16:31:13 UTC · request UUID ad1708d2-8536-4204-9a7b-32ded5800d48 · correlation key VULQRUUFGZBAJGT3GLPNLAANJA Production Get Notification History, same key: HTTP 200 (0 records, app not yet released). 2026-10-20 16:40:08 UTC · request UUID 7aedd431-fcf1-b104-42cd-17cc599425e4 · correlation key PLW5IMP46GYQIQWNC7GFTFBF4Q What fails Production Request a Test Notification (both api.storekit.itunes.apple.com and api.storekit.apple.com): HTTP 404, errorCode 4040007, "No App Store Server Notification URL found for provided app." No testNotificationToken is issued, so Apple never contacts our endpoint. Most recent: 2026-09-30 11:25 UTC · request UUID 22a1e218-4cdc-3577-9e18-3e25caf64052 · correlation key EKQ6EGCM3Q2XPHQYHYS4V5SAKI Earlier: f0cf352f-828e-fd40-8c14-2000fb8181e3 (Sept 23), 74a8bbbd-cd43-a18b-c4ac-bba619232d1d (Sept 14), 412d6c9f-511c-4402-ba18-d33fcda1b916 and 4f88fc30-3a4c-b7da-5d67c2f88570 (Sept 4, two different keys) Already done Production Server URL verified as saved in App Store Connect; removed, saved, re-added, waited, retested. No change. Reproduced with Apple's App Store Server Library (Swift) and with a minimal client. Feedback filed: FB24641446. Developer Support escalated the case to engineering on September 18; no engineering response yet. The question In thread 806452 an App Store Commerce Engineer wrote that production API access is unlocked once an app has a release in production. Our production history call succeeds for an unreleased app, so we cannot tell from outside whether the notification URL lookup behind /inApps/v1/notifications/test is gated on first release. If it is, we will release today and retest; a one-line confirmation would end a seven-week hold. If it is not, the production notification URL record for this app appears to be missing or unreadable, and we would ask that it be inspected and rebuilt. Happy to run a fresh reproduction in any time window and post the UUID. App Apple ID 6793806173, bundle com.haullynx.app.

We use StoreKit 2 for auto-renewable subscriptions in one group. Each explicit purchase attempt is durably recorded before calling Product.purchase(options: [.appAccountToken(attemptUUID)]). The app never retries a possibly invoked attempt automatically. Access is based on verified Apple transactions plus current server subscription status and ownership checks. A purchase invocation was interrupted or returned an uncertain result. A later user-initiated AppStore.sync completes, and Transaction.all yields verified transactions for an earlier subscription. Server API v2 history queried using the signed appTransactionId also returns no transaction/renewal containing the later attemptUUID. We preserve the attempt as unknown: an old same-product receipt or an empty lookup does not prove its outcome. Does Apple provide a definitive, supported way to determine whether this exact invocation committed, using the supplied appAccountToken when no transaction ID was received? For an already subscribed customer, can a successful Product.purchase return an existing transaction whose appAccountToken differs from the newly supplied token? What documented correlation should recovery use? If no definitive per-attempt lookup exists, what recovery pattern do you recommend without treating absence as cancellation or permitting duplicate subscriptions across different Apple Accounts? The authentication problem encountered earlier was resolved by following Apple's TestFlight Media & Purchases/Sandbox account-selection instructions. The remaining question is exact purchase-outcome correlation. We are not asking to bypass verification or overwrite Apple account tokens. No app name, bundle ID, customer details, transaction identifiers, tokens, receipts, credentials or screenshots are included in this question.

Is there a supported way in StoreKit 2 or the App Store Server API to tell whether a user purchased a paid app or downloaded it through Family Sharing? Transaction.ownershipType covers in-app purchases. Is there an equivalent for the paid app itself in AppTransaction?

Hello Apple Developer Community, I'm developing an iOS app called Rozděluj – společné výdaje (Bundle ID: cz.rozdeluj.rozdelujapp). StoreKit returns no products for any of our four In-App Purchases in TestFlight. Environment iPhone running iOS 27.0.1 Flutter 3.47.5 in_app_purchase 3.3.1 in_app_purchase_storekit 0.4.13 TestFlight builds 57, 58 and diagnostic build 59 Products cz.rozdeluj.plus.yearly — auto-renewable subscription cz.rozdeluj.unlimited.yearly — auto-renewable subscription cz.rozdeluj.plus.lifetime — non-consumable cz.rozdeluj.unlimited.lifetime — non-consumable Diagnostic results Flutter IAP: isAvailable: true Products returned: 0 Not found IDs: all four Error: storekit_no_response Message: StoreKit: Failed to get response from platform. We also added an independent native Swift StoreKit 2 diagnostic using Product.products(for:) with the same four identifiers. Native result: status: ok count: 0 foundIDs: [] missingIDs: all four The native query completed without throwing an error, but returned an empty product array. Configuration verified Bundle ID matches App Store Connect. In-App Purchase capability is enabled. Paid Apps Agreement, bank account and tax forms are Active. Product IDs match exactly. Pricing and worldwide availability are configured. Czech localization is configured for the inspected product. Automatic App Store distribution signing is enabled in Codemagic. All four IAPs currently have Rejected status following an App Review Guideline 3.1.2 rejection related to missing Terms of Use links. The app has since been updated to address that issue. Questions Could the Rejected status prevent these products from being returned by StoreKit 2 in TestFlight Sandbox? Is there another App Store Connect or Sandbox configuration that could cause Product.products(for:) to return an empty array without throwing an error? What additional diagnostics would help identify the cause? I would appreciate guidance before recreating any products or modifying the purchase implementation. Thank you!

Many of my purchases are encountering an issue when using a promotional offer (with a promo offer signature included). On the client side, everything works properly, and the purchase triggers the .success() callback. However, there are no updates in either the transaction/renewal info or via webhooks. According to the documentation, at least one of these server notifications should be triggered: OFFER_REDEEMED or SUBSCRIBED/RESUBSCRIBED. My server did not receive any signals. Furthermore, when I fetched the subscription status using the App Store Server API, the offer identifier did not appear in either the renewal info or the transaction info.

Hello, I am the Account Holder of an Individual Apple Developer Program membership based in the Russian Federation. I am trying to request the StoreKit External Purchase Link Entitlement (RU) for my iOS app. The app itself is free to download. It does not use and is not intended to use Apple In-App Purchase. Premium digital content is provided through a subscription purchased on our external website. Apple currently documents StoreKit External Purchase Link support for Russia. However, when I open the official StoreKit External Purchase Link Entitlement (RU) request form, I cannot submit the request unless I have accepted the latest Paid Applications Agreement. The problem is that the Paid Applications Agreement is not available in my App Store Connect account. Apple Developer Support informed me that, because my Apple Developer Program membership is located in the Russian Federation, I am currently unable to distribute paid applications or applications using In-App Purchases due to applicable sanctions. This creates a circular situation: StoreKit External Purchase Link (RU) is officially available for Russia. The entitlement request form requires the Paid Applications Agreement. My Russian developer account cannot accept the Paid Applications Agreement. Therefore, I cannot submit the entitlement request. My intended purchase flow is: Free iOS app → user account → StoreKit External Purchase Link → external website → digital subscription → access activated in the app. Has anyone with a Russian Apple Developer account successfully obtained the StoreKit External Purchase Link Entitlement recently? Is there an official manual process for Russian developers who cannot accept the Paid Applications Agreement? Can this entitlement request be processed manually by Apple Developer Support or another Apple team? I would especially appreciate guidance from an Apple engineer regarding the officially supported path for this situation. Thank you.

Hello, I am investigating a subscription price mismatch in U&ME, TestFlight version 1.1.0 (20). I submitted Feedback Assistant report FB25210596 on October 16, 2026. The iPhone tester reports iOS 26.5. The exact device model and full OS build still need to be collected. Our latest device diagnostic at 2026-10-16T08:16:52Z shows the same Storefront.current values before and after Product.products(for:): id: 143465 countryCode: CHN currency.identifier: CNY However, the returned products have priceFormatStyle.currencyCode == "USD": com.ume.dailyphoto.duo.monthly: displayPrice US$3.99; introductory offer US$1.99. com.ume.dailyphoto.trio.monthly: displayPrice US$4.99; introductory offer US$3.99. A read-only App Store Connect check confirmed China availability and these configured China prices: duo CNY 25 monthly / CNY 15 for the first month; trio CNY 35 monthly / CNY 25 for the first month. The returned USD prices match our configured US prices. Both subscriptions currently have READY_TO_SUBMIT status. The tester followed the dedicated China-mainland Sandbox Apple Account setup and a subsequent requested device restart. New diagnostics still show CHN/CNY with USD product metadata. These manual account/restart actions are not independently attested by the app logs. The native Swift module reads Apple's displayPrice, price, and priceFormatStyle.currencyCode directly, without currency conversion or a USD fallback. We read Storefront.current before and after the product query, observe Storefront.updates, and invalidate saved quotes when the storefront changes. There is no local StoreKit configuration in the scoped app source we reviewed. Before we added a mismatch guard, the Apple confirmation sheet showed China prices while the app displayed USD. The guard now blocks purchase when currencies disagree; we have not completed a purchase test. I found a similar report at https://developer.apple.com/forums/thread/845478, but I do not know whether our case has the same cause. We have diagnostic screenshots, native-source excerpts and a sanitized regional-price audit. We also prepared a small SwiftUI Xcode sample that reads storefront and product metadata only. It has NOT been compiled or run: our current workspace is Windows and we do not have a Mac available. We have NOT reproduced this in a development-signed build. The code-level support form directed us here because we do not yet have a verified focused reproducer. Could Apple advise: Is there a supported way to obtain product metadata consistent with the CHN/CNY storefront in this TestFlight situation, or a recommended workaround/test configuration? Which logging profile and device diagnostics would help investigate FB25210596? Can the existing TestFlight diagnostics and unverified sample source help, or is a development-signed reproduction required before further technical support? We want to show prices consistent with Apple's confirmation sheet and complete a valid China-region sandbox test. We are not assuming a production release will fix this. Thank you.

Hi everyone, We have already migrated our app to StoreKit 2 for the latest release. However, we are currently planning our long-term strategy (such as implementing forced app updates) for when StoreKit 1 eventually stops working on legacy app versions. I’ve already checked several discussions here regarding the deprecation of the server-side /verifyReceipt endpoint and its potential impacts. Aside from backend validation, I’m particularly curious about the overall client-side StoreKit 1 framework timeline. While I understand that there is no official sunset date announced yet, it would cause significant issues and delays in handling our legacy apps if it were shut down without warning. I was wondering: Has anyone heard or seen any official guidance on how Apple typically handles full deprecations for core frameworks like this? Can we reasonably expect Apple to issue an official announcement (via Developer News, etc.) with a sufficient grace period before StoreKit 1 is fully retired? I'd love to hear your thoughts or if anyone has received any insights from Apple Developer Support regarding this. Thanks in advance!

I’m unable to retrieve a newly configured auto-renewable subscription from the Apple Sandbox environment. Product information Bundle ID: com.reynaga.Imoox Product ID: com.reynaga.Imoox.subscription.monthly Subscription status: Prepare for Submission Price: USD 1.99 per month Introductory offer: one-week free trial Result The app requests the product using StoreKit 2: let products = try await Product.products( for: ["com.reynaga.Imoox.subscription.monthly"] ) The request doesn’t throw an error, but the returned products array is empty. I also tested with SKProductsRequest. The Sandbox response is: Valid products: [] Invalid product identifiers: ["com.reynaga.Imoox.subscription.monthly"] Configuration already verified The Bundle ID and Product ID match App Store Connect exactly. The app uses an explicit App ID, not a wildcard. In-App Purchase is enabled for the App ID. The development certificate and provisioning profile are valid. There is no StoreKit Configuration file active in the Run scheme. The Apple Developer Program membership is active. The Paid Applications Agreement is active. Banking and all required tax forms show an Active status. The subscription has a price, localizations, tax category, and availability. Mexico and the United States are included in its availability. The Sandbox Apple Account belongs to the same developer team. The app is development-signed and installed from Xcode 26.2 on a physical iPhone. I signed out and back into the Sandbox account, deleted and reinstalled the app, restarted the device, and cleaned the Xcode build. The issue has persisted well beyond the documented metadata propagation period. Apple Developer Support reviewed the administrative configuration and referred me to the Developer Forums. According to Apple’s documentation, an In-App Purchase doesn’t require prior App Review approval to work in Sandbox. Could an Apple StoreKit or App Store Connect Commerce engineer verify whether the app-to-subscription catalog association is correctly provisioned in Sandbox and refresh or reprocess it if necessary?

StoreKit 2 Product.products(for:) returns an empty array (no error) for all 6 in-app purchases of my app in TestFlight. Setup: App: Apple ID 6816296214, bundle ID com.nh2s.eggmage-dungeon (first version 1.0, not released yet) IAPs: egg_gems_80, egg_gems_500, egg_gems_1200, egg_gems_2500, egg_starter_pack (consumable), egg_no_ads (non-consumable) Each IAP: status Ready for Review, price set (175 regions, base KRW), English and Korean localizations Business: Paid Apps Agreement Active, Free Apps Agreement Active, bank account Active, W-8BEN, U.S. Certificate of Foreign Status and Korea tax form all Active. The latest Program License Agreement and Paid Applications Schedule are accepted. Explicit App ID with In-App Purchase capability enabled TestFlight build 1.0 (2610141319), canMakePayments = true, storefront USA (143441) The agreements and tax forms became Active yesterday, and the products still don't load after many full app restarts. The app uses Unity IAP 5.4.3, which calls Product.products(for:) with the six IDs above. Is there anything else on the account or app side that could make the sandbox return no products? This looks like the same issue as https://developer.apple.com/forums/thread/849426 (first app, consumables, tax forms activated recently, empty product response). Thank you.

We've been approved for the Advanced Commerce API. After receiving the approval, we completed the initial setup requirements (submitted a generic product ID and shared our subscriptions page deep link). When testing the Migrate Subscription to Advanced Commerce endpoint in the sandbox, we receive a 5000000 error. What could be the reason/s for it? There is no information, and the API call we make includes all required parameters. Could it be related to the fact that our new generic product ID status is "Missing Metadata"? Is there a way to understand what the issue is on Apple's side?

Hello, We are contacting you regarding an issue we are currently experiencing during the App Review process related to In-App Purchases and StoreKit product retrieval. After extensive internal testing and investigation, we believe the behavior we are seeing is identical to the issue discussed in the following Apple Developer Forum thread: https://developer.apple.com/forums/thread/827016 Our application was rejected under Guideline 2.1 - Performance because the subscription plans reportedly failed to load during review. According to the review notes, the In-App Purchase product list appeared empty in the review environment, which prevented the paywall from loading correctly. We would like to provide additional technical context because, despite significant testing efforts on our side, we have been unable to reproduce this behavior outside of the App Review environment. The exact same binary that was reviewed by App Review has been thoroughly tested by us through TestFlight on multiple physical devices, including iPhone and iPad devices, using multiple Sandbox tester accounts and different network conditions. In all of our tests, the subscription system functions correctly and consistently. Specifically, we verified that: StoreKit successfully retrieves all configured subscription products RevenueCat offerings load correctly without timeout or empty states Localized pricing information is displayed properly Subscription packages appear correctly in the paywall UI Purchase flows complete successfully Restore purchases functionality works correctly Products are returned both on cold launch and repeated application launches The issue does not occur intermittently in TestFlight or Sandbox testing on our side We also carefully reviewed our App Store Connect configuration and verified the following items multiple times: All In-App Purchase subscriptions are attached to the submitted app version Product identifiers used in the application code exactly match the identifiers configured in App Store Connect All products are marked as “Cleared for Sale” Paid Applications Agreement has been accepted and remains active Tax and banking information are complete and active Subscription localization settings are configured properly Pricing information is active and visible The products are available in the storefronts being tested The submitted binary is identical to the binary tested successfully through TestFlight Additionally, we implemented defensive handling in the application to minimize the impact of temporary StoreKit failures. The application now includes: Retry logic for offerings retrieval Graceful fallback handling for empty offerings Protection against infinite loading states Additional RevenueCat and StoreKit logging UI fallbacks when products temporarily fail to load Despite these safeguards, the review feedback still indicates that the products are not being returned in the App Review environment. At this point, because the issue cannot be reproduced externally and only appears during App Review, we suspect there may be an intermittent or environment-specific issue affecting StoreKit product retrieval in the review sandbox environment. One important detail is that the exact same build consistently works in TestFlight immediately before and after submission. This makes the behavior particularly difficult for us to diagnose because there appears to be no configuration difference between our successful tests and the App Review scenario. We also understand from Apple documentation and previous App Review communication that In-App Purchases are tested within an Apple-provided sandbox environment. Based on the evidence currently available to us, the failure appears to occur specifically within that review sandbox process rather than within the application logic itself. If possible, we would greatly appreciate assistance with the following: Verifying whether StoreKit product retrieval is functioning correctly in the App Review sandbox environment Confirming whether the review device successfully established communication with App Store sandbox services Providing any available diagnostic logs related to the failed product request Confirming whether the product identifiers were visible to StoreKit during review Sharing any guidance on how we may reproduce the App Review behavior locally Clarifying whether there are known intermittent issues affecting StoreKit product loading during App Review We are fully committed to resolving the issue and ensuring complete compliance with App Store requirements. However, because the issue currently appears environment-specific and non-reproducible from our side, we are struggling to determine what additional changes are necessary. If there are any additional diagnostics, logging methods, StoreKit verification steps, or App Review recommendations you would like us to implement, we would be happy to do so immediately. Thank you very much for your assistance, support, and time. We sincerely appreciate your help in investigating this issue. Best regards, Mert Akgün

I'm investigating a Restore Purchases failure in my app, PW Paycheck, which uses StoreKit 2. TestFlight purchases of consumable checks and an annual subscription have succeeded, but restoring purchases repeatedly fails. The failing call is: try await AppStore.sync() Apple displays an account password prompt. I enter my password and tap OK, after which the call throws. Our typed error classifier and NSError conversion report: StoreKitError.unknown StoreKit.StoreKitError: 2 This is the StoreKit.StoreKitError domain, not SKErrorDomain. We have not established whether authentication succeeded internally or what causes the failure. Environment: Physical iPhone 16 Pro; installed through TestFlight. App version 1.0 (20), bundle com.ggeller.pwpaycheck. In-app OS report: Version 26.6.2 (Build 23G90). Reported StoreKit price storefront: USA / 143491. Annual subscription: com.ggeller.pwpaycheck.pro.annual. Developed and uploaded using Swift Playgrounds on iPad. I have a Windows laptop and no Mac access. Steps: Open the TestFlight app with an existing unexpired annual test subscription. Open Payment Options and tap Restore Purchases. Enter the password in Apple's prompt and tap OK. AppStore.sync() throws the error above. The app then refreshes entitlements and displays a restore failure message. Observed results: Verified active subscription access is recognized before and after the failed operation. We do not count this as successful restoration. The subscription was canceled but still unexpired during the captured attempt. Build 19 produced the same NSError domain/code on Wi-Fi and cellular. Build 20 captured the typed .unknown classification on Wi-Fi. Our logger captured no additional underlying error. The latest attempt started at 2026-10-14T13:59:09Z and completed at 13:59:25Z, including the post-failure entitlement refresh. We are not treating this as evidence of a timeout. The restore action is user initiated, guarded against duplicate operations, and waits for an earlier entitlement refresh to finish before calling AppStore.sync(). What supported diagnostic or configuration check would help distinguish possible causes of this error, particularly without access to Xcode's device console? Also, how should we isolate a TestFlight-specific restore failure in a focused sample while preserving the relevant app/account context? A separate sample has been prepared, but compilation and reproduction are still pending.

Hello Apple Developer Community, I need technical assistance with a recurring StoreKit subscription issue affecting my iOS application, DRIVER BRAIN. Application details: App: DRIVER BRAIN Bundle ID: com.oney.driverbrain Subscription Product ID: com.oney.driverbrain.premium.monthly Subscription price: $9.99 USD per month Introductory offer: 3-day free trial Development framework: Flutter (iOS) Problem: During Apple's App Review, the subscription product is not being returned by StoreKit. The purchase screen displays the message: "Apple has not returned the subscription yet." As a result, App Review cannot complete the subscription purchase flow, and the application has been rejected under Guideline 2.1 – App Completeness. Checks already completed: Subscription Product ID verified. Bundle ID verified. In-App Purchase capability enabled. Three-day introductory trial configured in App Store Connect. Paid Apps Agreement active. Banking and tax information active. Subscription availability reviewed. Sandbox account configuration and physical iPhone testing performed. Despite these checks, Apple's reviewers continue to encounter the subscription loading problem. I would appreciate assistance from Apple's StoreKit engineers or experienced developers with the following questions: Why might an auto-renewable subscription product not be returned during App Review? How can I identify whether the issue originates in StoreKit product retrieval, App Store Connect configuration, or the review environment? Which StoreKit diagnostic logs or code excerpts would help identify the root cause? What is the recommended technical solution to ensure the subscription product loads reliably during App Review? I am looking for a definitive diagnosis rather than repeating configuration checks that have already been completed. Thank you for your assistance.

I'm investigating a price/currency mismatch in a TestFlight app. Environment: iPhone 15, iOS 26.6.2 App version 0.4.2 (Build 47), distributed through TestFlight Consumable product ID: line_stamp_8pack_1980 Diagnostic comparison: October 5, 2026, at 11:22:47 JST (UTC+09:00) For the same product, all three product lookup paths returned price 11.99, currency USD, and display price $11.99: StoreKit 1: SKProductsRequest / SKProduct StoreKit 2: Product.products(for:) expo-iap: fetchProducts The direct StoreKit calls were made through native Swift diagnostics in the app. All three lookups succeeded without errors. StoreKit 2 reported storefront country USA and ID 143462 before and after its lookup. expo-iap also reported USA before and after its lookup. StoreKit 1's storefront was unavailable before its request. Afterward, it reported USA, with storefront identifier "143462-9,29". Our diagnostic initially labeled this as a storefront change, but an unavailable-to-available result does not establish an actual country change. During the same testing session, Apple's purchase confirmation sheet for this product displayed ¥1,980 and stated that the purchase was for testing only. I canceled the sheet without completing the purchase. The Media & Purchases account's country/region is Japan. App Store Connect pricing for this product is ¥1,980 in Japan and $11.99 in the United States. What could cause the product lookup APIs to return the US storefront price while the purchase confirmation sheet displays the Japanese price? What additional diagnostics should I collect to identify the cause and obtain a product price consistent with the purchase sheet? Thank you.

Does changing the price of an already-approved In-App Purchase trigger a new App Review, or does the new price take effect without review? App Store Connect Help states that changes to localized information require review and that 'New pricing will go into effect immediately', but never says explicitly whether a price change alone is exempt from review. We need this for a non-renewing subscription sold in the Saudi Arabia storefront.

Hi, I am designing a database schema to store App Store transaction data for our backend system, and I have a question regarding the uniqueness of transactionId. According to the documentation (apple.com), transactionId is a unique identifier for a transaction. However, it is not explicitly clear whether this uniqueness is guaranteed across different environments.Could you please clarify the following points? Is transactionId guaranteed to be unique across both the Production and Sandbox environments? (i.e., Is there any possibility that the exact same transactionId is generated in both environments?) For database design, is it safe to use transactionId alone as a Primary Key? Or is it strongly recommended to use a composite key consisting of both environment and transactionId? Any insights or best practices from Apple engineers or the community would be highly appreciated.Thank you.

Hello Apple Developer Community, I need technical assistance with a persistent StoreKit subscription issue in my iOS app, DRIVER BRAIN. App details: Bundle ID: com.oney.driverbrain Subscription Product ID: com.oney.driverbrain.premium.monthly Price: $9.99 USD per month Introductory offer: 3-day free trial Problem: During App Review, Apple has repeatedly reported that the subscription product is not returned by StoreKit. The paywall displays the message "Apple has not returned the subscription yet," preventing reviewers from purchasing or accessing the application. We reproduced this issue on a physical iPhone using a TestFlight build. However, when testing locally through Xcode with the DriverBrain.storekit configuration file, the subscription and introductory offer appeared correctly, and the purchase test succeeded. Checks already performed: Subscription Product ID matches the application configuration. In-App Purchase capability is enabled. Paid Apps Agreement, banking, and tax information are active. Subscription pricing and 3-day introductory offer are configured in App Store Connect. Physical-device, sandbox, and TestFlight testing have been performed. Multiple App Review submissions have encountered this issue. Questions for Apple engineers: What could cause StoreKit to return zero subscription products in TestFlight or App Review while the local StoreKit configuration works? Could subscription availability, App Store Connect configuration, or App Review environment issues explain this behavior? Which specific StoreKit diagnostics or logs should we collect to identify the root cause? We would appreciate technical guidance to isolate this issue rather than repeat configuration checks already completed. Thank you for your assistance.

We use StoreKit’s ExternalPurchaseCustomLink for an external card-payment flow available in Germany. On an iPad simulator, the app reports “This payment method is currently available only in the German App Store” and stops before showing Apple’s disclosure sheet or opening Stripe. On an iPhone installation, the disclosure sheet and Stripe have opened, but we have not confirmed that both devices use the same build or App Store storefront. The app is intended for distribution in Germany. Can App Review test an iPad app using a storefront other than Germany? Which Storefront does ExternalPurchaseCustomLink.isEligible use during App Review, and what should developers provide so reviewers can exercise a Germany-only flow?

Hello Apple Developer Community, We are experiencing a reproducible StoreKit pricing issue in our Flutter iOS app, Tablichko. App details: Bundle ID: bg.tablichko.tablichko In-App Purchase: bg.tablichko.tablichko.fullversion Product type: Non-consumable TestFlight build: 22 Source commit: 587834b App Store Connect pricing: Bulgaria: EUR 6.99 United States: USD 5.99 The issue: On the same physical iPhone, using the same Apple Account and Bulgarian storefront, we observe different prices depending on how the app is installed. A standalone development-signed StoreKit 2 test app correctly returns EUR 6.99, with displayPrice showing "6,99 €" and storefront BGR/EUR. Our full Flutter application, built from the same source commit in release mode and development-signed, also correctly displays EUR 6.99. After reinstalling TestFlight build 22, the exact same Flutter app displays USD 5.99. However, when initiating the purchase from TestFlight, Apple's native purchase confirmation sheet correctly displays EUR 6.99. Our app uses the price returned by StoreKit (Product.displayPrice) without manually converting currencies or applying any hardcoded price. Expected behavior: StoreKit should return EUR 6.99 for the Bulgarian storefront in both development-signed and TestFlight installations. Actual behavior: The TestFlight app displays USD 5.99, while Apple's purchase confirmation sheet displays EUR 6.99. Questions: Why would StoreKit return a USD localized price only in TestFlight while the development-signed version correctly returns EUR? Could this be caused by stale StoreKit product metadata or TestFlight-specific caching? Is there a known issue with localized In-App Purchase pricing in TestFlight? Is there a recommended diagnostic procedure or workaround to ensure StoreKit returns the correct storefront-specific price? Any guidance from Apple engineers or developers who have encountered this issue would be greatly appreciated. Thank you!