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.

We are testing version 1.0 Build 29 through TestFlight after a Guideline 2.1(b) rejection: Purchase did not respond on iPad Air 11-inch (M3). Paid Apps Agreement is Active, and subscription price, availability, localization and review screenshot are present. Restores worked, but a fresh purchase is not yet verified. On iPhone 13, Build 29 is installed, Developer Mode is on, and Media & Purchases was signed out. The tester reports signing into Developer > Sandbox Apple Account, then trying to sign into the app. During this sequence an email verification prompt was followed by: "iTunes account creation not allowed. This Apple account cannot be used with iTunes Store at this time. Please try again later." The app uses Sign in with Apple separately from StoreKit. We have not isolated which system authentication flow produced the error. What is the supported sequence for regular iCloud/Sign in with Apple alongside a Sandbox Apple Account for TestFlight purchases? Which diagnostics distinguish account setup failure from app authentication or StoreKit failure? Should we escalate through Feedback Assistant or Developer Support, and which logs should accompany the report? We want to verify a fresh purchase on an 11-inch iPad before resubmission.

I am troubleshooting a reproducible StoreKit product discovery issue in a TestFlight build of my iOS application. App: Bundle ID: com.aileguvende.app Version: 2.9.59 Build: 97 On a physical iPhone using the TestFlight build, opening the subscription/paywall screen reproduces the issue. StoreKit availability is true and canMakePayments is true, but Product.products(for:) requests six auto-renewable subscription identifiers and returns: Requested products: 6 Returned products: 0 Not found products: 6 The query reports product_query_error with the plugin error code storekit_no_response. No purchase or Restore operation is required to reproduce the issue. The applicable TN3186 checks completed successfully: the App ID is explicit, In-App Purchase capability is enabled, the bundle ID and signing profile match, all six product identifiers match App Store Connect, all six products are available in Türkiye, pricing is configured, Turkish and English localizations are present, and the Paid Apps Agreement, banking, and tax information are active. The Apple Account and storefront are Türkiye. During the same runtime window, storekitd and appstored activity was observed and AMSErrorDomain activity was present, but no reliable native numeric error code or native product counts were exposed. CLIENT_PLUGIN_DEFECT_PROVEN=NO OFFICIAL_APPLE_INCIDENT_CONFIRMED=NO Feedback Assistant report: FB24793792. Could Apple engineers please verify: Whether the six subscriptions are present in the TestFlight/Sandbox commerce catalog for com.aileguvende.app. Whether the app-to-subscription catalog association is healthy on Apple’s backend. Whether there is a current StoreKit/App Store Commerce product-discovery issue where Product.products(for:) returns an empty result despite TN3186 checks passing. Whether any additional diagnostic is needed for FB24793792. This issue is reproducible without a transaction. I am not requesting a source-code change or a new build.

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.

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.

Hello, We would appreciate some guidance regarding an unexpected StoreKit currency result in a TestFlight build. Our iPhone language and region are both set to France. The Sandbox tester is also configured for France, and our subscription products have French availability and pricing configured in App Store Connect. In the TestFlight build we diagnosed, StoreKit reports the current storefront as France with EUR: storefront=FRA/143442/EUR However, all 10 subscription products are returned with USD product metadata: products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE Example: formatCurrency=USD locale=fr_US_currency_USD localeCurrency=USD display=1,99 $US price=1.99 We first observed this through Flutter's in_app_purchase integration. To determine whether the Flutter plugin was involved, we added a native StoreKit 2 diagnostic to the same TestFlight build. The native result was identical: receipt=sandboxReceipt storefront before=FRA/143442/EUR storefront after=FRA/143442/EUR products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE The issue appears specific to the TestFlight distribution. When the application is installed directly from the development computer, prices are returned in euros on the same device. We also tested with the regular Media & Purchases account signed out and a French Sandbox tester connected. Once the products loaded successfully, StoreKit still returned USD metadata. In another configuration, the application displayed the USD price while Apple's purchase sheet displayed the price in euros. We are using the price and formatting information returned directly by StoreKit. We do not want to infer the currency from the device region or perform a client-side currency conversion, because StoreKit should remain the authoritative source. Could you please help us understand: Is it expected for Storefront.current to report FRA/EUR while Product.priceFormatStyle.currencyCode, its locale currency, and Product.displayPrice use USD? Could a TestFlight or App Store Connect configuration cause product metadata to use a different currency from the current storefront? Is there another account, availability, pricing or distribution setting that we should verify? Is there a recommended way to refresh or invalidate the product metadata used by a TestFlight installation? We have already filed Feedback Assistant report FB24723329, which is currently under investigation. Thank you very much for any clarification or additional diagnostic steps you can suggest.

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.

Hello, We are considering using the Advanced Commerce API for a native macOS app distributed through the Mac App Store. Our use case is a base auto-renewable subscription with optional subscription add-ons (e.g. Effects and Templates). The Advanced Commerce API eligibility page lists Mac Catalyst, but does not explicitly list native macOS. However, the macOS 15.4 release notes mention support for Advanced Commerce API purchases in StoreKit. Could someone please clarify: Is Advanced Commerce API supported for native macOS App Store apps (not Mac Catalyst), including subscriptions with optional add-ons? Does it support introductory free trials, e.g. a 3-day free trial for the base subscription? Can existing auto-renewable subscription subscribers be migrated to Advanced Commerce API and then purchase optional add-ons as part of the same subscription? Many thanks!

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.

I've read several topics on cancelling subscriptions in sandbox environment, but it seems to me that it could not be applied to TestFlight. I can cancel sandbox subscriptions through Settings > App Store > Sandbox account But since TestFlight does not use sandbox account I cannot cancel a sub from there. Also, TF purchase does not appear in the list of regular subscriptions (Settings > Profile > Media & Purchases). So my question is: is there any way to manually cancel auto-renewable subscription bought in TestFlight build of the app?

Title: Sandbox allows free trial again on resubscribe to the same subscription Hi everyone, I'm testing an auto-renewable subscription using App Store Connect with a Sandbox tester (not a local StoreKit configuration file). My subscription has an introductory free trial configured. Scenario: Purchase the subscription for the first time using a Sandbox Apple ID. The user receives the introductory free trial as expected. Let the subscription expire. Purchase the same subscription product again using the same Sandbox Apple ID. I receive an App Store Server Notification with Notification Type = RESUBSCRIBE, and the transaction appears to have a price of 0, making it look like the user received another free trial. From Apple's documentation, my understanding is that an introductory offer can only be redeemed once per subscription group per Apple ID. Based on that, I expected the second purchase to be charged immediately rather than receive another free trial. My questions are: Is this expected behavior in the Sandbox environment? Does Sandbox sometimes allow introductory offers to be redeemed multiple times for testing? Or am I misinterpreting the RESUBSCRIBE notification and the $0 transaction? I did not intentionally reset the Sandbox tester's introductory offer eligibility, and I'm purchasing the same product in the same subscription group with the same Sandbox Apple ID. Has anyone observed this behavior or can clarify whether this is expected in Sandbox versus production? Thanks!

大家好，我正在排查一个 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?

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

We have a monthly subscription and an annual subscription with a 3-day free trial. The monthly converts fine. On the annual, trials tend to enter billing retry rather than convert — users don't cancel, the charge just fails. We've audited our implementation and found nothing on our side that participates in the renewal charge. What can a developer actually do about this? Does trial length, price point, or using a paid introductory offer instead of a free trial make a difference?

We have 5 consumable in-app purchase products (Product IDs: localshadows_support_099, _499, _999, _2499, _4999) currently in "Prepare for Submission" status. Our app's first version (1.0) has also not yet been submitted for App Review. Question: Does sandbox testing of these consumable IAPs require the app to be fully approved through App Review first, or is it sufficient for the products to be attached to a version that has been submitted (even if still pending review)? What we've tried: We're using react-native-iap v16.4.1 for a real native StoreKit 2 purchase flow (not RevenueCat, which was masking this issue via its Test Store simulation mode). Calling fetchProducts() for these SKUs returns an empty array, and calling requestPurchase() for them results in an indefinite hang with no error. We want to complete sandbox testing before deciding on our actual App Review submission timeline.

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.

I’m trying to diagnose a StoreKit issue with an auto-renewable subscription in my iOS app. The subscription is called “Lighthouse Plus” and is $9.99/month. The app is currently being tested through TestFlight. When the user taps the Lighthouse Plus subscription button, the app begins the purchase process/loading state, but the Apple purchase sheet never appears. The UI then remains stuck loading indefinitely. This has continued across multiple TestFlight builds, including our current Build 11. What happens: Install/open the app through TestFlight. Sign into the app. Navigate to Lighthouse Plus. Tap the subscription/purchase button. The app enters a loading state. No Apple purchase confirmation sheet appears. The loading state never resolves. We have also been investigating Restore Purchases and Manage Subscription behavior as part of the same StoreKit implementation. The subscription product has been configured in App Store Connect and associated with the app. We have repeatedly tested new builds while trying to determine whether the failure is in our StoreKit implementation, product configuration, TestFlight sandbox environment, or communication with the App Store. The particularly difficult part is that we are not receiving a visible StoreKit error on the device — the purchase attempt appears to wait indefinitely rather than returning a clear success, cancellation, or failure. I do not currently have access to a Mac for direct Xcode/StoreKit Console debugging, so I am trying to determine the best way to diagnose exactly where this transaction is stopping from a TestFlight device. Questions: What would cause a StoreKit subscription purchase request to remain pending/loading without ever presenting Apple's purchase sheet? Is there a way to retrieve useful StoreKit/TestFlight transaction diagnostics without access to Xcode on a Mac? Are there specific App Store Connect subscription states/configuration issues that can cause this behavior without StoreKit returning an obvious error? What StoreKit transaction/product logging should we add to the app itself so the next TestFlight build can identify exactly where the request is failing? Should the purchase call have an explicit timeout/error path if StoreKit never returns? I can provide the product identifier, relevant StoreKit implementation/code, App Store Connect configuration screenshots, and additional diagnostics if needed. Any guidance on isolating whether this is an App Store configuration issue versus an implementation issue would be greatly appreciated.

product?.subscription?.isEligibleForIntroOffer 在swift中使用该方法时，目前生产环境只有一个例出现无反应的情况，从日志看有调用该方法前的日志，但无该方法之后的日志，怀疑无返回阻塞在此处，看有什么办法尝试修复这种情况