General: Forums topic: StoreKit Forums tag: In-App Purchase App Store Pathway Simple and safe In-App Purchases Auto-renewable subscriptions In-App Purchase documentation Getting started with In-App Purchase using StoreKit views documentation Supporting business model changes by using the app transaction documentation Testing at all stages of development with Xcode and the sandbox documentation App Store Server Notifications documentation App Store Server API documentation Simplifying your implementation by using the App Store Server Library documentation TN3185: Troubleshooting In-App Purchases availability in Xcode technote TN3186: Troubleshooting In-App Purchases availability in the sandbox technote TN3188: Troubleshooting In-App Purchases availability in the App Store technote Understanding StoreKit workflows sample code Implementing a store in your app using the StoreKit API sample code What’s new in StoreKit and In-App Purchase video

I am investigating a repeatable StoreKit 2 restore failure in SommPal, TestFlight 1.0.0 (20), on a physical iPhone running iOS 26.6.2. Feedback report FB24795995 has been submitted with attachments. An explicit user tap calls try await AppStore.sync(). Apple presents an Apple Account password prompt. The tester enters the password for the displayed account and presses OK; no visible authentication error appears. The call then throws typed StoreKitError.unknown, bridged as NSError domain StoreKit.StoreKitError, code 2. Traversal through NSUnderlyingErrorKey exposes no nested cause. This is not SKErrorDomain code 2, and we are not interpreting it as user cancellation. The tester reports Media & Purchases signed out and a dedicated Sandbox Apple Account configured under Developer settings. The prompt displays the personal Apple Account rather than the dedicated sandbox account. Sandbox subscription management loads successfully. Controlled tests on September 15, 2026: Isolated refresh on Wi-Fi: same unknown error. Normal Restore: available purchases are independently verified by our server and annual access remains active, but explicit Apple sync fails. Isolated refresh on cellular: same error. Full iPhone restart, then isolated refresh on cellular: same error. The isolated test serializes app-initiated StoreKit operations and waits for previous operations to finish. It skips local transaction recovery and acknowledgement before calling sync. Native Transaction.updates observation remains active; we have not isolated Apple internal work. Our native probe imports only Foundation and StoreKit and directly calls AppStore.sync(). It catches StoreKitError.userCancelled separately, then classifies other typed StoreKitError cases and records safe NSError domain/code values. The application uses React Native/Expo with our own Swift bridge. The isolated action performs a server permission check before entering the native restore method. Native entitlements are enumerated only if sync succeeds; the isolated action does not acknowledge or finish transactions. The failure occurs at sync, before that enumeration. We retain signature, ownership and expiration verification. Valid access is not removed solely because sync fails. A previous application-account ownership conflict was separately identified; using the rightful application account restores access but does not resolve this sync failure. We have prepared a dependency-free SwiftUI/Xcode sample containing the same probe, but it has not yet been compiled or tested as a standalone app. We have not reproduced on a second physical device. Automated error-mapping tests pass but do not establish that real Apple authentication works. We are not claiming a confirmed iOS defect. What supported diagnostic step, logging profile, call context, or integration change would help distinguish an integration problem from an account/device/service issue? Is the personal-account prompt expected in this TestFlight configuration? Additional private diagnostics can be supplied through FB24795995. The attached screenshot shows the isolated failure after restarting the iPhone.

App name: Hold My Bouquet Bundle ID: com.holdmybouquet.app App Store Connect App ID: 6807080553 In-App Purchase Product ID: com.holdmybouquet.app.page_unlock (Non-Consumable, £3.99) Our app was rejected on Guideline 2.1 because the reviewer could not complete this in-app purchase. Since the rejection, we have verified and corrected every configuration item we can control, but the purchase still fails identically in sandbox testing on a physical device. Confirmed correct: Paid Applications Agreement: Active com.holdmybouquet.app.page_unlock: status "Ready to Submit," Cleared for Sale, pricing and availability set Bundle ID matches exactly across Xcode, App Store Connect, and our purchase provider (RevenueCat) Product ID matches exactly, no typos or case mismatches Sandbox tester account verified and signed in on-device (Settings → Developer → Sandbox Account) No local StoreKit Configuration file overriding real data (confirmed "None" in the Xcode scheme) To rule out our purchase provider entirely, we bypassed it and called Apple's native StoreKit 2 API directly from the app: let products = try await Product.products(for: ["com.holdmybouquet.app.page_unlock"]) This also returns zero products, with no error — confirming the issue is not a third-party SDK integration problem. Has anyone seen this before, or can anyone from Apple advise what else to check? We are otherwise ready to resubmit for review.

All auto-renewable subscriptions for Domiai (bundle app.domiai, App ID 6799989904, group 22305757) stay MISSING_METADATA via ASC API for weeks. Metadata complete for each product: fi+en-US localizations, group localizations, pricing, multi-territory availability, review screenshot COMPLETE (1290×2796). Business (Paid Apps, Banking, Tax, DAC7) all Active. Even a newly created control product domiai_meta_unstick_monthly (6801762338) with full config is also MISSING_METADATA. TestFlight StoreKit / RevenueCat: “products could not be fetched”. Feedback: FB24775023 Support case: 20000138025601 (closed without investigating ASC state) Has anyone seen MISSING_METADATA persist after Paid Apps became Active with screenshots+localizations complete? Any known account-level unblock? Product IDs: domiai_plus_monthly/yearly, domiai_ai_monthly/yearly.

Hi everyone, I'm encountering an issue where the storefront country code returns "USA" unexpectedly in TestFlight builds, and I'd appreciate any insights from the community. Issue Description When executing SKPaymentQueue.default().storefront?.countryCode in our TestFlight builds, the property returns USA. However, we expect it to return JPN because both the Sandbox test user account and the Apple Account region configured on the device are set to Japan. Behavior Across Environments Xcode Debug & Ad Hoc Builds: Returns JPN as expected. TestFlight Builds: Returns USA unexpectedly. Related Threads I've noticed several threads reporting similar issues without a clear resolution: https://developer.apple.com/forums/thread/660817 https://developer.apple.com/forums/thread/794932 https://developer.apple.com/forums/thread/800078 https://developer.apple.com/forums/thread/814178 https://developer.apple.com/forums/thread/810860 Questions Is this USA value a known TestFlight/Sandbox-specific limitation or bug? Will production users in Japan correctly receive JPN (and see JPY prices) once the app is approved and published on the App Store? Is there any workaround or project configuration fix required on our side prior to App Store submission? Has anyone experienced this recently or confirmed the behavior in the production environment after release? Thanks!

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?

Live App Store app; approved non-consumable in-app purchase is not returned by production StoreKit, so customers cannot buy it. Product.products(for:) returns nothing; the paywall shows "purchases aren't available." ~15 days since first release (2026-07-06). Reproduced on two devices with two different Apple IDs. A redeemed promo code also did not deliver it. Important: my IAP status is APPROVED (not "Waiting for Review"), so this differs from some recent threads — yet the product still isn't served in production. Verified per TN3188 (all pass): product ID matches App Store Connect exactly; status Approved; Availability = all 175 regions; priced (base USD); listed on the public App Store product page; Paid Apps Agreement, banking, and tax forms all Active; no local .storekit config in the build; the product returns correctly from our provider's (RevenueCat) servers, so the empty result is specifically the on-device production StoreKit fetch. This coincides with the recent App Store Connect incident affecting in-app-purchase submission, and there's a cluster of similar reports this week (threads 838171, 838435, 835770, and "In-App Subscriptions stuck in 'Waiting for Review' after App Store Connect maintenance"). It looks like a server-side issue where the product never propagated to production StoreKit despite showing Approved. Environment: Expo/EAS, React Native 0.81, StoreKit 2 via react-native-purchases 10.3.0. Devices: iPhone 15 Pro Max (iOS 27.0), iPhone 16 Pro Max (iOS 26.5). Open Developer Support case: 102936978821. Is there any developer-side step remaining, or does this require Apple to re-process / re-propagate the product server-side? Any guidance appreciated.

Hi everyone, I set up an auto-renewable subscription introductory offer in App Store Connect with a scheduled start date of September 7 for the Philippines storefront. According to the documentation App Store pricing and availability start times by country or region, scheduled pricing and offer updates are expected to go live based on local regional times. However, the offer did not show up in the Current Introductory Offers in app store connect portal at the documented start time (14:00 Sep 6th UTC). Instead, it stayed in the Upcoming Offers until 7:00 Sep 7th UTC which is 17 hours after the time in the doc. We met a similar situation a few days later when we launch another introductory offer in Thailand. I would appreciate clarification on the following points: What is the underlying reason for the discrepancy between the documented start time behavior and the actual start time observed in production? Can Apple update the App Store pricing and availability start times by country or region reference documentation so that it accurately reflects the practical start time and propagation window for each region? Any insights or shared experiences with offer scheduling in the APAC region would be greatly appreciated.

I'm seeing behavior similar to what was reported in this thread: https://developer.apple.com/forums/thread/816344 I read the discussion in the related thread (816320) as well, but I couldn't determine whether receiving the same transaction multiple times from Transaction.updates is considered expected behavior. In my case, I'm testing an auto-renewable subscription in the Sandbox environment. After successfully processing and calling finish() on a transaction, Transaction.updates sometimes provides another transaction with the same transactionId. I've also observed the same transactionId being delivered multiple times through Transaction.updates itself. I compared the JWS representations of these transactions. They are not byte-for-byte identical, but the transaction information appears to be the same. The only differences I've identified are: signedDate deviceVerificationNonce deviceVerification This looks as though the same transaction is being signed again at a different time. I'd like to clarify the intended way to handle this: Is it expected behavior for Transaction.updates to deliver the same transactionId multiple times in this way? If so, after an app has successfully processed and finished a transaction, is it safe to recognize subsequent transactions with the same transactionId as already processed, skip entitlement-related processing, and simply call finish() on them? In other words, can an app use transactionId to prevent duplicate processing of transactions that it has already successfully handled? I'm specifically interested in whether doing so could cause the app to miss any meaningful update that StoreKit might later deliver using the same transactionId.

大家好，我正在排查一个 TestFlight 沙盒环境中的 StoreKit 2 商品加载问题，希望获得建议。 一、现象 iOS App 通过 TestFlight 安装（Build 4）后，使用 Product.products(for:) 请求两个非消耗型内购项目。调用不会抛出错误，但始终返回空数组，因此购买页没有任何可购买商品。 products = try await Product.products(for: [ "com.shidan.qieting.plus.trial.7day", "com.shidan.qieting.plus.lifetime" ]).sorted { $0.id < $1.id } 两个 Product ID 分别为： Product ID 类型 价格 App Store Connect 状态 com.shidan.qieting.plus.trial.7day 非消耗型 Tier 0 / US$0.00 可供审核 com.shidan.qieting.plus.lifetime 非消耗型 US$5.99 可供审核 二、日志 在 TestFlight App 冷启动后，诊断日志记录： 2026-09-03T08:12:08Z [settings] plus products loaded: trialAvailable=false, lifetimeAvailable=false 打开购买页时再次调用，结果仍然为空。没有捕获到 StoreKit 异常，也没有购买流程报错。 三、系统级沙盒验证结果 为排除 App UI 和 StoreKit 商品加载代码的影响，我们还使用同一开发团队创建的 Sandbox Apple Account，在 iOS 的“设置 > 开发者 > Sandbox Apple Account > 管理 > Test Transactions”中直接测试： Bundle ID：com.shidan.qieting Product ID：com.shidan.qieting.plus.lifetime 系统提示：“提供的产品 ID 或套装 ID 无效”。该工具不经过 App 内的购买页或 Product.products(for:) 结果，仍无法识别这组 Bundle ID 与 Product ID。 四、已完成核验 代码中的 Product ID 与 App Store Connect 中的 Product ID 完全一致。 Release Bundle ID 与 App Store Connect App Record 一致，均为 com.shidan.qieting。 App ID 为显式 ID，不是 wildcard App ID。 Certificates, Identifiers & Profiles 中已启用 In-App Purchase capability；Xcode Target 也已启用，Xcode Cloud 使用自动签名。 TestFlight 使用 Archive 构建；共享 Scheme 的 ArchiveAction 没有 StoreKit Configuration 文件。本地 .storekit 文件只用于 Xcode Run/Test，本身不影响 Archive/TestFlight。 两个项目均已设置价格、175 个 App Store 地区可售，以及简体中文、繁体中文、英语本地化。 最后一次修改 IAP 元数据已经超过 48 小时。 Paid Apps Agreement、税务信息和银行信息均为有效/正在使用中。 尚未提交 App 或 IAP 审核；理解为 TestFlight 沙盒测试不应以提交审核为前提。 欧盟《数字服务法》（DSA）交易商合规信息仍在审核中；但该要求针对欧盟 App Store 产品页的交易商信息。Apple 官方说明中，单独通过 TestFlight 分发不属于在欧盟 App Store 以交易商身份分发，因此这不应影响 TestFlight 沙盒或 Test Transactions。 五、想请教 在上述条件已确认、Product.products(for:) 不报错却返回 [] 的情况下，是否还有容易遗漏的 App Store Connect、沙盒、签名或 TestFlight 配置？ 是否有人遇到过“所有 Product ID 均正确、商品完整且全球可售，但 TestFlight 沙盒始终返回空数组”的情况？如果这是 Apple 沙盒端的已知延迟或异常，有什么进一步的排查或反馈渠道？ 我可以按需要补充已打码的 App Store Connect 配置截图和完整诊断日志。谢谢。

Environment: Sandbox Bundle ID: com.fosssocial.app Key ID: L7DZYHGM62 Issuer ID: cf1f7bc7-452f-4bb8-a925-31ca29175fac Summary Our In-App Purchase key is accepted by the App Store Server API but rejected by the Advanced Commerce API, using the exact same bearer token. This appears to be an authorization grant that was never applied to the key, rather than a signing or request-format problem on our side. Reproduction — one token, two API families GET /inApps/v1/subscriptions/1 -> 404, errorCode 4040010 (token ACCEPTED, resource simply not found) POST /advancedCommerce/v1/subscription/changeMetadata/1 -> 401, errorCode 4010000 (token REJECTED) Same JWT, same key, issued seconds apart. A 401 on one family and a 404 on the other isolates this to key authorization. On-device symptom A signed SubscriptionCreateRequest passed to StoreKit as advancedCommerceData fails with StoreKitError.unknown / "Unable to Complete Request". No payment sheet appears and no InvalidRequestError is returned, so there is no field-level error to act on. What we have already verified JWS header: alg ES256, kid, typ JWT Claims: iss, iat, aud "advanced-commerce-api", bid, nonce, request No exp claim (per Apple's documentation) The request claim uses standard padded base64, not base64url Key ID and .p8 file confirmed to be a matching pair Key regenerated after receiving the Advanced Commerce access-granted email; the 401 is unchanged AdvancedCommerceProduct(id:) resolves successfully on device, which confirms the PRODUCT has Advanced Commerce access Question Does the In-App Purchase key require a separate authorization for the Advanced Commerce API beyond the product-level access we were granted? If so, how is that applied to an existing key?

Calling AppStore.requestReview(in:) with a valid, foreground-active UIWindowScene never presents the rating/review sheet on iOS 27 Simulator. The identical code works correctly on iOS 26 and earlier Simulator runtimes. Repro: if let windowScene = UIApplication.shared.connectedScenes .compactMap({ $0 as? UIWindowScene }) .first(where: { $0.activationState == .foregroundActive }) { AppStore.requestReview(in: windowScene) } Fresh Simulator install (Erase All Content and Settings first, to rule out the 3-per-365-day throttle). Run on iOS 27 Simulator → no sheet appears, no error, no console output. Run the identical build on iOS 26 Simulator → sheet appears as expected. Also tried: The SwiftUI @Environment(.requestReview) action (RequestReviewAction) instead of the UIKit windowScene call — same result, no prompt on iOS 27 Simulator. Ruled out an Xcode/Simulator-runtime version mismatch: reproduces both with an older Xcode + separately-downloaded iOS 27 runtime, AND with the matching Xcode 27 beta + its bundled iOS 27 Simulator. Checked the iOS 27 beta release notes — no mention of requestReview/StoreKit review prompt changes. Environment: Xcode [fill in version/beta] iOS 27 Simulator (beta [fill in]) Simulator device: [e.g. iPhone 16] Expected: Review prompt presents (subject to the documented frequency limit), matching iOS 26 behavior. Actual: No prompt, no error, on both the UIKit and SwiftUI review-request APIs.

Hi all — hoping someone has run into this. restorePurchases() (via Flutter's in_app_purchase/in_app_purchase_storekit plugin, which wraps StoreKit) consistently returns zero transactions for an Apple ID that has a confirmed, currently active auto-renewable subscription to my app. Evidence the subscription is genuinely active: Settings → [Apple ID] → Subscriptions shows the subscription as active for this Apple ID. Independently confirmed via the App Store Server API (GET /inApps/v1/subscriptions/{originalTransactionId}) that Apple's servers currently recognize this subscription. Details: originalTransactionId: 2000000099299646, original purchase mid-2022 The App Store Server API's "latest transaction" for this ID resolves to environment: Sandbox, even though this Apple ID has also made real Production purchases over time — wondering if mixed Sandbox/Production history on one Apple ID could be affecting restorePurchases()'s results Tested on a real device, iOS [version], with and without an explicit SKPaymentQueueDelegate set — no difference in behavior Would appreciate any insight — thanks!

Hi all I have an app I’m pretty much done with, and on the Xcode simulator it works perfectly and the IAP shows us when the purchase buttons are clicked but for some reason when it goes to testflight none of the buttons respond, is there any reason that would cause it to behave differently in testflight when its coded correctly and works in the simulator. thanks

Our app's auto-renewable subscription (Product ID: istanbul.membership.monthly, Bundle ID: com.mehmetozenen.ustaistanbulapp) has been returning zero products from Product.products(for:) since August 24, 2026, blocking 100% of new iOS subscriptions on our live production app. Verified correct on our side: Subscription status: Approved Paid Applications Agreement: Active (continuously since Feb 2026, no gaps) Territory pricing: set, including Turkey Product ID matches exactly, correct app No changes to Agreements/Tax/Banking around the failure date Steps to reproduce: Call Product.products(for:) (or via react-native-iap's fetchProducts) with SKU istanbul.membership.monthly, type auto-renewable subscription. Result: empty product array, no error thrown. Purchase sheet never appears since there is no product to purchase. Reproduced on: 4+ independent physical iOS devices Multiple different Apple IDs Both Sandbox and Production StoreKit environments (identical failure in both) Both Wi-Fi and cellular networks A historical app build (from before Aug 24) that was never modified and worked correctly as recently as Aug 23 — ruling out any client-side code cause This same product worked correctly as recently as 2026-08-23 (server-side purchase verification log confirms a real successful transaction that day). It broke starting 2026-08-24, with no corresponding change on our end. I've already opened a Developer Technical Support case (Case-ID 21790415) and submitted a full sysdiagnose with reproduction timestamps, but have not received a substantive update in over a week. Posting here in case others have hit the same regression, or in case anyone from Apple can help escalate. Has anyone else seen Product.products(for:) / fetchProducts silently returning empty for an otherwise valid, Approved auto-renewable subscription starting around late August 2026?

Am same facing Storekit issue 0 product returns in Product identifier Array. Even i test on device it returns invalid product identifier due to 0 product array. Issue Description Step 1 Create a new Auto-Renewable Subscription from the App Information page in App Store Connect. Step 2 Complete all the required fields for the Auto-Renewable Subscription and click the "Save" button. Expected Result After saving, the subscription status should change from "Prepare for Submission" to "Ready to Submit". Actual Result The subscription status remains "Prepare for Submission" and does not change to "Ready to Submit", even though all required information has been completed and the subscription has been saved. I am currently facing a critical issue while creating an Auto-Renewable Subscription in "App Store Connect". I have already completed all the required subscription details. However, whenever I click the "Save" button, the subscription status does not change from "Prepare for Submission" to "Ready to Submit", as expected. Because the subscription never reaches the "Ready to Submit" state, every purchase attempt in the Sandbox environment fails with the following error: SKErrorDomain Code = 3 "Invalid Product Identifier" To troubleshoot the issue, I have already: Created multiple new Product Identifiers, but every identifier is reported as "invalid" in the Sandbox environment. Verified that my "Banking, Tax, and Paid Applications Agreement" is complete and active. Confirmed that all required fields for the Auto-Renewable Subscription have been filled in before saving. Since I am unable to submit the subscription for review and all Product Identifiers remain invalid, I believe there may be an issue with my App Store Connect configuration or account. I would appreciate it if you could investigate this issue and help resolve it as soon as possible, as it is currently blocking the implementation and testing of in-app purchases.

Hi, I’m having an issue with an in-app purchase implementation using StoreKit and a WKWebView. The app uses a WKWebView with a WKScriptMessageHandler registered with the name "iap" to communicate between JavaScript and the native Swift code. The implementation works correctly when running the app through Xcode Simulator. The IAP buttons trigger the expected native code and the bridge functions correctly. However, when I install the same/latest build through TestFlight, the IAP functionality does not work as expected. The buttons/JavaScript-to-native communication do not appear to trigger the same way they do in the Simulator. The IAP products and configuration have been set up in App Store Connect. I have already checked the implementation and confirmed that the same code works when running from Xcode. Could there be any difference between Simulator and TestFlight regarding: StoreKit sandbox/TestFlight behaviour Entitlements or signing App Store Connect configuration WKWebView/WKScriptMessageHandler behaviour JavaScript-to-native communication in a TestFlight build Any required configuration for IAP testing through TestFlight I would appreciate any guidance on what I should check to determine why the "iap" WKScriptMessageHandler works in Simulator but not in TestFlight. Thanks.

We are testing two auto-renewable subscriptions for a new iOS app. In Apple Sandbox, StoreKit 2 Product.products(for:) always returns an empty array. Legacy SKProductsRequest independently reports both identifiers as invalid. Environment: Physical iPhone, iOS 26.5 Xcode development build with automatic signing Storefront.current = USA (143441) canMakePayments = true No StoreKit Configuration file in the Run scheme Direct native StoreKit 2 diagnostics, without a third-party purchase SDK TN3186 checks completed: Explicit Bundle ID matches the App Store Connect app, installed app, and provisioning profile In-App Purchase is enabled for the App ID Developer membership, Paid Apps Agreement, banking, and tax are active One subscription group with monthly and yearly subscriptions is visible Pricing, localizations, and availability are configured Neither subscription is Rejected or Developer Action Needed The scheme is using real Sandbox data, not local StoreKit testing Results: StoreKit 2 batch query: rawCount = 0 SKProductsRequest: valid = []; both identifiers are invalid StoreKit 2 individual monthly query: 0 StoreKit 2 individual yearly query: 0 No exception; failure occurs during product discovery Related reports: https://developer.apple.com/forums/thread/839313 — TN3186 verified and USA storefront valid, but still 0 products; no replies https://developer.apple.com/forums/thread/841722 — Apple Commerce mentioned Rejected or Developer Action Needed states; ours have neither https://developer.apple.com/forums/thread/820656 — Apple DTS confirmed first subscriptions do not require review before Sandbox testing Apple Developer Support referred us to TN3186, and we verified every applicable item. The individual subscription detail route in App Store Connect also intermittently remains on a loading indicator although the group and both records are visible. Could an App Store Commerce or StoreKit engineer check whether the app-to-IAP catalog association is populated correctly on Apple's side, or advise an official escalation path to have the Sandbox catalog reprocessed? Exact account, app, product, device, email, and support-case identifiers are omitted from this public post and can be supplied privately through Apple Support or Feedback Assistant.

We're testing In-App Purchases for our app distributed via TestFlight, using Sandbox Apple Accounts. We observe two device-dependent behaviors and have two questions. (App-specific details, including the bundle ID, are in our Feedback report FB24632077.) Observation 1 — Consumable second purchase fails with DuplicateTransaction on some devices The first purchase of a consumable succeeds and the transaction is finished. A second purchase of the same consumable then fails with PurchaseFailureReason.DuplicateTransaction ("This In-App Purchase has already been bought") on some devices. It correlates with sandbox session persistence: on devices where the purchase prompts for password only (e.g., iOS 26.x, iPadOS 18.4.1) the second purchase succeeds; on devices where it prompts for the account (email) + password every time (e.g., iOS 18.3.2, iPadAir2 15.6), the second purchase fails. The same Sandbox Apple Account behaves differently on different devices. An Ad Hoc (development-signed) build with the same account succeeds. Observation 2 — Product price sometimes returns USD instead of the storefront currency With the same Sandbox account (region: Japan), prices are shown in JPY on iOS 26.2 but in USD on iOS 18.3.2. The App Store app shows JPY, but SKProductsRequest / StoreKit 2 Product metadata returns USD. Question 1: Are these known Sandbox/TestFlight limitations? If so, what is the recommended way to reliably test repeat consumable purchases (and to get the correct storefront currency) in TestFlight across many devices and OS versions? Question 2: For TestFlight IAP testing, are there environmental differences between (A) using the device's real Apple ID (signed into Media & Purchases; automatic sandbox) and (B) signing out of Media & Purchases and using a Sandbox Apple Account — with respect to: reliability of repeat consumable purchases, authentication / session persistence (password-only vs account + password each purchase), storefront / currency resolution for product metadata, ability to clear purchase history? Which approach do you recommend for a consistent, reliable TestFlight IAP QA environment? Environment: TestFlight (App Store distribution), Sandbox tester region = Japan. (App-specific identifiers such as bundle ID are in our Feedback report FB24632077.) Repro: buy a consumable once (succeeds, finished) → buy the same product again → DuplicateTransaction on affected devices. Thanks!

Our first submission has now been rejected under Guideline 2.1(b), with the message: "the in-app purchases do not load successfully." Each review was performed on an iPad Air 11-inch (M3) running iPadOS 26.6. The app sells only auto-renewable subscriptions. We cannot reproduce the failure, and we have verified every part of the configuration we can think of. WHAT WE VERIFIED (via the App Store Connect API, not just the UI) Two subscriptions in one group, state READY_TO_SUBMIT Product IDs exactly match what the app requests Available in 175 territories, including the United States Prices set, en-US localizations present for both products and for the group App review screenshots attached to both, state COMPLETE Both subscriptions are included in the review submission (READY_FOR_REVIEW) Paid Apps Agreement: Active. Bank account: Active. Tax forms: Active. WHAT WORKS On our own devices, installed via TestFlight (sandbox environment), the products load correctly and a purchase completes and activates as expected. This works on both a real Apple ID and a Sandbox Tester account. WHAT WE OBSERVED FROM THE REVIEW SESSION We use RevenueCat. Their server-side API returns our offering with both packages and the correct product identifiers, so the offering metadata is fine. Our backend also shows that the reviewer's session reached our servers and signed in successfully at the review timestamp, so the device had working network connectivity. That leaves StoreKit itself returning no products on the reviewer's device, which is what empties the offering. QUESTIONS Are there known conditions under which StoreKit returns no products in the App Review sandbox for subscriptions that are in "Ready to Submit" and are attached to the same submission as the binary? For an app that has never been approved, is product loading during review handled differently from a normal sandbox session on a released app? Is there any way to obtain diagnostics from a review session, or to ask the reviewer for a screenshot of the failing screen? Replies in Resolution Center so far have only repeated the original rejection text. Is there anything specific to iPadOS 26.6 that could affect StoreKit 2 product lookups? For the next submission we have added a timeout and automatic retries around the product lookup, plus a visible retry control instead of a spinner, in case the failure is a transient cold-start timeout. But we would rather understand the actual cause than keep guessing. Any pointers appreciated.

I'm having the exact same issue. My app has 2 subscription groups, each with 2 auto-renewable subscriptions (monthly and yearly duration) — 4 products total, all in "Ready to Submit" status. The error I keep getting when trying to submit the first group together with the app version is: "New subscription groups must be submitted with an auto-renewable subscription of that same group" What I've already verified/tried: Full metadata on each subscription: reference name, pricing, localizations (display name + description) in two languages, review screenshot Added the individual subscription products (not the group) to the submission draft from each product's own page Draft correctly shows the app version + all subscriptions grouped together under "Suscripciones (4)" Set both durations (monthly/annual) to the same subscription level within each group, as suggested in another thread — no change Recreated the subscriptions from scratch with entirely new Product IDs — same error Tried different browsers, incognito mode, hard refresh Paid Applications Agreement is Active, no pending agreements The error persists regardless of what I try. Has anyone found what actually resolved this beyond the subscription level fix? Or is this something only Apple can unblock from their side?