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!

I am seeing different StoreKit storefronts and localized prices between a direct Xcode installation and TestFlight on the same iPhone. Environment: App: CountAdd iPhone 15 Pro In-App Purchases: non-consumable App Store Connect base country/region for IAP pricing: Japan (JPY) Japan is enabled for app and IAP availability Results on the same device with the same app code: Xcode Debug: Storefront: JPN Prices: JPY Xcode Release: Storefront: JPN Prices: JPY (¥250 / ¥1,250 / ¥2,500) TestFlight Build 10: Storefront: USA Prices returned/displayed by StoreKit: USD ($1.99 / $7.99 / $14.99) Using macOS Console with the physical device connected, I confirmed that the TestFlight build logs: Storefront updated to ... countryCode: "USA" For the Xcode Release build, the same device reports: countryCode: "JPN" I also deleted the TestFlight app and reinstalled Build 10 to eliminate local app data as a possible cause. The issue remained: TestFlight returned USA/USD. The Sandbox Apple Account is configured for Japan. In some tests, although the app displays the StoreKit product price in USD, Apple's purchase confirmation sheet displays the price in JPY. I am not manually converting or hardcoding prices. The app displays the localized product price returned by StoreKit. I have already reported this through Feedback Assistant: FB25014147 I also contacted Apple Developer Support: Case 102983767864 Developer Support advised that they cannot investigate technical issues involving Sandbox IAP testing and directed me to Feedback Assistant. My main questions are: Is it expected or a known issue for a TestFlight/Sandbox build to receive a USA storefront and USD product metadata while a direct Xcode build on the same device receives JPN/JPY? More importantly, can this TestFlight/Sandbox behavior affect the production App Store version? When a user in Japan installs the production app from the App Store, should StoreKit return the Japanese storefront and JPY localized prices? I am trying to determine whether it is safe to submit/release the app without implementing any manual currency conversion or hardcoded pricing.

Hello everyone, I am currently refining our server-side transaction verification and purchase tracking using StoreKit 2 and the App Store Server API. We are looking into how our backend can accurately track the specific App Store commission rate applied to each individual transaction. With potential future regulatory changes in various markets that might introduce different fee structures between device types, it is becoming crucial for our system to distinguish these details at the transaction level. I contacted Apple Support regarding this but couldn't get a technical clarification, so I would like to ask the community and Apple engineers here: (1) Commission Rate: Is there any standard field in the StoreKit 2 Transaction payload or the JWS payload from the App Store Server API (V2) that explicitly indicates the applied commission rate (e.g., 15%, 30%) or a specific commission tier for that transaction? (2) Device Type: If the commission rate is not directly included, is there a native field in the real-time transaction payload to identify whether the purchase was made on an iPhone or an iPad? (I understand we can use appAccountToken as a workaround to link client-side device info to our backend, but I am wondering if there is a built-in identifier.) (3) Official Verification Method: If real-time API payloads contain neither, would using the App Store Connect API to retrieve the "Summary Sales Report" or "Subscriber Report"—and deriving the commission rate from Customer Price and Developer Proceeds—be the recommended approach? Are there any other best practices for handling this at scale? Any insights from Apple engineers or developers who have implemented similar tracking would be highly appreciated. Thank you in advance!

In my TestFlight app, StoreKit reports the Japan storefront (JPN, ID 143462), but product prices are returned in USD. Environment: iPhone 15, iOS 26.6.2 TestFlight version 0.4.2 (build 52) Product ID: line_stamp_8pack_1980 Product type: consumable Feedback Assistant report: FB25133058 Steps to reproduce: Sign out of the regular account under Media & Purchases. Sign in to a Sandbox Apple Account configured for Japan under Settings > Developer. Launch the TestFlight app and request product information. Expected result: The current Japan price configured in App Store Connect is JPY 1,980. The base country is Japan, and no future price changes are listed. Actual result: Storefront country: JPN Storefront ID: 143462 Product price: 11.99 Currency: USD Display price: $11.99 StoreKit 1 priceLocale: en_US@currency=USD I compared native StoreKit 2 Product.products(for:), StoreKit 1 SKProductsRequest, and expo-iap fetchProducts. All three returned the same USD price without errors. The storefront remained JPN before and after each request. The issue persists after restarting the app and rebooting the iPhone. No purchase was performed. What additional diagnostics or configuration checks would help identify why the product currency differs from the reported storefront? Is there a supported workaround for testing Japanese prices in this situation?

We are seeing a consistently reproducible StoreKit Sandbox issue involving Apple’s refund request sheet. Our app uses: Transaction.beginRefundRequest(for:) The refund sheet is successfully presented, but instead of loading the refund reason form, the Apple-provided sheet consistently displays: “Cannot Connect” This prevents the Sandbox refund request from being submitted. Environment: App: BTY Norebang Admin iOS: 26.6.1 Physical iPhone StoreKit environment: Sandbox Product type: Consumable Product: BTY Room – 1 Hour Development-signed build We have confirmed: Normal consumable purchase succeeds Transaction retrieval succeeds beginRefundRequest successfully presents Apple’s refund sheet App Store Server API calls succeed App Store Server Notifications V2 TEST delivery succeeds Get Test Notification Status reports sendAttemptResult = SUCCESS The problem persists after rebooting the device The problem persists after signing out and back into the Sandbox Apple Account Different network conditions have been tested The issue reproduces in an isolated Xcode/StoreKit test project with no BTY backend, authentication, or app networking dependency Expected behavior: The Sandbox refund request sheet should load the refund reason selection and allow the refund request to be submitted. Actual behavior: The Apple-provided refund sheet opens but displays “Cannot Connect.” No refund is submitted and no App Store Server Notification V2 REFUND event is generated. Feedback Assistant report: FB24527792 The Feedback Assistant report includes sysdiagnose and relevant diagnostic logs. This is currently the only remaining external blocker preventing us from completing full and prorated Sandbox refund end-to-end validation before enabling Production App Store Server Notifications. Could an Apple StoreKit / App Store Commerce engineer confirm whether this is a known Sandbox issue or advise whether any additional configuration or diagnostic information is required? We can provide a focused reproduction Xcode project, additional sysdiagnose logs, and Sandbox transaction details if needed.

We are testing an annual auto-renewable subscription with the monthly 12-payment commitment in App Store Sandbox. The Sandbox tester is configured for 3-minute monthly renewals. Is commitmentExpiresDate supposed to follow that accelerated schedule? Our signed transactions initially report an end almost six days away, but the commitment actually completes in about 41 minutes. In one complete 12-payment lifecycle on 8 Oct 2026 (all times UTC): Payment 1: purchased at 16:34:04; installment ends at 16:37:04; commitmentExpiresDate is 14 Oct 06:13:04 — almost six days away. Payment 2: commitmentExpiresDate is 13 Oct 19:04:04. Payment 3: commitmentExpiresDate is 8 Oct 17:28:04. Payment 4: commitmentExpiresDate is 12 Oct 18:24:02 — jumping forward by about four days. Payments 6 and 9 again report ends on 8 Oct, while payments 7 and 8 report dates days away. Payment 12: both expiresDate and commitmentExpiresDate are 8 Oct 17:14:44, followed by EXPIRED/VOLUNTARY. The actual elapsed time since payment 1 was 40 minutes 40 seconds, including delayed Sandbox renewals. We compared all 12 signed App Store Server Notifications V2 transactions with independently fetched signed transactions from the Sandbox Get Transaction Info API. The values match. billingPeriodNumber advances from 1 through 12 on the same commitment. There was no DID_RENEW/BILLING_RECOVERY. The first date changes occurred before we disabled post-commitment renewal after payment 3. Apple’s documentation says to use commitmentExpiresDate from the latest transaction and describes a changed date after billing recovery. Here it changes drastically on ordinary renewals, and the initial date appears incompatible with the Sandbox renewal rate. Is this a known Sandbox issue? Should commitmentExpiresDate reflect the 3-minute/month schedule? Can we rely on it remaining consistent across ordinary payments in production, or is there another recommended source for the full commitment end date? We can provide the transaction IDs and all 12 decoded transactions privately for investigation.

Hi, I’m experiencing a StoreKit 2 issue with my iOS app Live Gigs. App: Live Gigs Bundle ID: com.leicomusic.LiveGigs App Apple ID: 6817866296 Subscription Product ID: livegigsmaandelijks Subscription Apple ID: 6817868044 The auto-renewable subscription is Approved in App Store Connect and is available in all countries and regions. Pricing, localization, subscription group, Paid Apps Agreement, banking and tax have all been checked and are active. The actual problem is that the subscription does not appear in the app at all. When a customer opens the subscription screen, there is no product and therefore the Apple purchase sheet cannot be opened. The customer cannot purchase the subscription. The app calls: Product.products(for: ["livegigsmaandelijks"]) StoreKit returns an empty array without throwing an error. I have tested this on a physical iPhone using a signed build. Interestingly, the same product works correctly when using a local Xcode StoreKit Configuration: the €6.99/month product appears and the purchase flow can be started. I have checked the requirements described in TN3186/TN3188, including the Bundle ID, product ID, subscription status, availability, pricing, localization, agreements, banking, tax, IAP capability and signing. Has anyone else experienced an approved subscription suddenly disappearing from the StoreKit catalog like this? Could this be an Apple-side StoreKit/App Store Commerce catalog issue? Any advice from Apple engineers or developers who experienced the same issue would be greatly appreciated.

Live App Store app. Since 2026-09-01 PDT, StoreKit no longer returns our approved auto-renewable subscriptions on signed builds. The same SKUs load normally in Xcode when using a local StoreKit configuration file. New purchases are blocked. Monthly auto-renewals that were collecting normally through August 31 began failing their renewal attempts starting September 1, with all observed attempts entering Billing Grace / Billing Retry. App Name: Moonlit Bundle ID: moonlit.reading Versions affected: 1.1.1 — App Store version that was already live and working normally before September 1 1.1.2 — subsequently released to the App Store specifically to test whether a fresh production release would restore StoreKit behavior. It did not. Approved auto-renewable subscriptions, both in the same subscription group: moonlit.monthly.subscription moonlit.yearly.subscription Paid Apps Agreement, banking, and tax are Active in App Store Connect. We use an explicit App ID with the In-App Purchase capability enabled. Distribution builds do not contain a StoreKit Configuration file. The local .storekit file is used only for Xcode Run. Through August 31, 2026, Product.products(for:) and SubscriptionStoreView returned both SKUs and their prices correctly on production builds. Beginning September 1, 2026, and continuing through at least September 11: Every production paywall we can measure receives an empty StoreKit catalog with no product IDs, no prices, and no thrown StoreKit error. SubscriptionStoreView remains on its loading state. Our Terms / Privacy footer still renders because it does not depend on StoreKit. showManageSubscriptions / manageSubscriptionsSheet also hangs or fails to connect on the same signed builds. App Store Connect subscription events for the monthly SKU show a complete reversal beginning September 1. All observed renewal attempts in the affected window entered Grace from Paid, with no successful renewals, whereas the comparable August window showed normal successful renewals. Sales reports show no IAP proceeds for the affected September window. App downloads continue to appear normally, so the app itself remains available for sale. What still works Xcode + local StoreKit Configuration: Both products load Prices display The purchase sheet presents normally Analytics and logging continue to function, so this is not an app crash or missing paywall UI. The subscriptions are not Rejected and are not in Developer Action Needed. TN3186 / TN3188 checks have already been completed. This appears similar to other recent reports where App Store Connect contains a valid product catalog but StoreKit does not serve the products to signed builds: https://developer.apple.com/forums/thread/838171 https://developer.apple.com/forums/thread/841722 https://developer.apple.com/forums/thread/838773 https://developer.apple.com/forums/thread/836183 Developer Support case: 102959783559 Request Could an App Store Commerce or StoreKit engineer verify whether the app-to-IAP catalog association for moonlit.reading is populated and being served correctly on Apple’s side, and refresh or reprocess the production catalog if appropriate?

Hello everyone, In our iOS app, we offer multiple auto-renewable subscription tiers within the same subscription group: Lite (Monthly / Yearly) Basic (Monthly / Yearly) Plus (Monthly / Yearly) Pro (Monthly / Yearly) We are using Apple's native Offer Code redemption sheet (SKPaymentQueue.default().presentCodeRedemptionSheet() / AppStore.presentOfferCodeRedeemSheet). The Issue We Are Facing: The user navigates to our subscription screen and selects the Pro Plan. The user taps our in-app "Redeem Offer Code" button, which presents Apple’s native redemption sheet. The user inputs an offer code that was created in App Store Connect specifically for the Basic Plan. When the user taps "Continue", Apple accepts the code and immediately presents the Apple Pay / Face ID confirmation to charge/subscribe the user to the Basic Plan. Because presentCodeRedemptionSheet() does not take any product ID parameter, Apple accepts the code for whichever product it was created for, regardless of the tier the user had selected on our paywall. By the time our transaction observer receives the transaction callback (paymentQueue(_:updatedTransactions:)), the payment/purchase has already been finalized by Apple. Questions: Can we restrict the native sheet to a specific Product ID? Is there any way with StoreKit 1 or StoreKit 2 to pass an expected productID to the redemption sheet so Apple only accepts codes eligible for that specific product? Can we intercept or validate the code before payment? Is there any delegate callback or hook when the user taps the "Continue" button on the "Redeem Offer" sheet so we can validate if the code matches the selected plan before the transaction is charged? What is Apple's recommended best practice? If a user redeems a code for a different tier (e.g., Basic instead of Pro), is the recommended approach to automatically switch and activate the redeemed plan on our backend since Apple has already completed the purchase, rather than rejecting it? Any guidance from Apple engineers or developers who have handled this multi-tier scenario would be greatly appreciated!

Hi, I have an user experiencing networkError(Foundation.URLError(_nsError: Error Domain=NSURLErrorDomain Code=-1008 "(null)")) when my app calls AppTransaction.shared on macOS 15.6. They have tried multiple internet connections, but the issue persists. What could be the root cause ?

Hello, We are troubleshooting product discovery for three consumable In-App Purchases in our first iOS game, ION RUSH. All three remain unavailable in TestFlight. Environment and result: Physical iPhone 13, iOS 27.0.1 (24A446). App version 1.0 (80), installed through TestFlight. Direct native StoreKit 2; no RevenueCat or other purchase SDK. Product.products(for:) returns zero products before application filtering, without throwing an error. Earlier independent development-build diagnostics also returned zero products for batch and individual StoreKit 2 requests; SKProductsRequest reported all three identifiers as invalid. Checks completed: Product IDs exactly match App Store Connect: nova_pack_5, nova_pack_15, nova_pack_40. The explicit bundle identifier matches the app record and code; In-App Purchase is enabled for the App ID. All three consumables show Ready for Review, have prices and localizations, and are available in all 175 configured territories, including the US. Developer membership, Paid Apps Agreement, bank account and tax forms are active. The Account Holder checked the Developer account for outstanding agreement signatures; none were visible. The Developer Program agreement was accepted September 29. Tax forms were submitted October 3 and now show Active. The financial setup was only recently completed, so delayed activation remains a possibility. The release scheme has no local StoreKit Configuration override. TestFlight reinstallation, device restart and repeated product refreshes did not restore the products. A re-export of the exact build 80 archive with the original App Store Connect signing settings selected an explicit App Store profile with beta-reports-active=true and get-task-allow=false. This checks the signing configuration; the original uploaded IPA was not available for direct inspection. Selected storekitd messages from October 4, 2026 (UTC+3): 09:59:22.963356 Requesting Media API product batch ["nova_pack_15", "nova_pack_40", "nova_pack_5"] 09:59:22.990339 summary for task success {transaction_duration_ms=1, response_status=200, cache_hit=true} 09:59:22.991595 Ignoring empty product response The request targets amp-api.sandbox.apple.com/v1/catalog/us/in-app-purchasables with the correct bundle and product IDs. Its account mediaType is com.apple.AppleMediaServices.accountmediatype.appstore.beta. A second request one second later produced the same HTTP status, cache flag and empty-product message. We did not capture the raw HTTP response body. Local StoreKit configuration tests work, but we understand this does not validate the live Sandbox catalog. We also understand that prior IAP review approval is not required for Sandbox testing. Questions: What additional developer-side check would distinguish incomplete account activation, product configuration or cached catalog state in this situation? Has anyone resolved this after completing agreements/banking/tax, especially when the products were created before financial activation? What exact action or elapsed time resolved it? If all TN3186 checks pass, what evidence and official escalation route should we use to request investigation of the app-to-product catalog association? Related reports: https://developer.apple.com/forums/thread/849165 (same storekitd messages, but after membership lapse/renewal; our situation differs) https://developer.apple.com/forums/thread/844545 (zero StoreKit 2 products and invalid StoreKit 1 identifiers after TN3186 checks) We can provide further redacted diagnostics and account details privately to Apple. Thank you.

Hello all, I'm posting here today in hopes the internet can help me find a solution for an issue I'm having with integrating with subscriptions created in App Store Connect. I'm receiving no products back from StoreKit 2 for my list of product IDs. Things I've verified so far: No errors are coming from StoreKit The product IDs I'm requesting match the configured product IDs in the subscriptions The provisioning profile matches the bundle ID of the built app. The provisioning profile includes the in-app purchases capability. All subscriptions are priced, include localization, have an availability region set, and include a tax category. The subscriptions have been set for a week. Well over the typical one hour metadata update window. My banking, tax info, and paid apps agreement are up to date and active. I'm signed out of Media & Purchases and signed into a sandbox account under developer mode on the test device. The region of the sandbox account matches the region availability of the subscriptions. Under Signing & Capabilities in Xcode, my team matches the team the app is created under in App Store Connect, In-App Purchase is included, and we are signing with my team's certificate. The app under test is a production release build installed via Test Flight. Logging the StoreKit environment shows that it's in the sandbox and matches the region configured for the sandbox user and subscriptions Device: iPhone 14 OS: iOS 26.5.2 Thanks in advanced for any help and insight you may have.

Hi everyone, I'm a new iOS developer, and my first app has been rejected twice because of In-App Purchase issues. Setup: Flutter, in_app_purchase 3.3.0, in_app_purchase_storekit 0.4.10 (StoreKit 1) One auto-renewable subscription and one non-consumable lifetime purchase Both products show "Ready for Review" in App Store Connect. Paid Apps Agreement is active. First review: The prices were visible on an iPad, but the subscription purchase failed (Guideline 2.1(b)). Second review: Neither product showed a price on an iPhone (Guideline 2.1(b)). Apple also noted missing subscription information (Guideline 3.1.2(c)). On my iPhone 15, both products load correctly and test purchases work in TestFlight using my regular Apple Account. Product IDs, pricing, availability, and localizations appear correct. My question: What could cause queryProductDetails / SKProductsRequest to return no products during App Review when everything works in TestFlight? Any suggestions would be greatly appreciated. Thanks! :)