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.

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; 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.

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中使用该方法时，目前生产环境只有一个例出现无反应的情况，从日志看有调用该方法前的日志，但无该方法之后的日志，怀疑无返回阻塞在此处，看有什么办法尝试修复这种情况

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.

Since January 28, 2026, we’ve noticed an increase in StoreKit-related errors during purchase flows. Specifically, we’re seeing a spike in errors reported as “Unable to Complete Request”, categorized as unknown StoreKit errors. This correlates with a noticeable drop in the overall purchase success rate. A few observations: The issue is not limited to the latest app version, it also affects older versions. It appears to occur only on iOS 17+. The impact seems country-specific: some regions are affected more heavily, while others show no significant change compared to previous days. At the moment, there are no related incidents reported on Apple’s System Status page. Given these symptoms, this looks like a potential StoreKit / Apple API issue, but we haven’t found any official confirmation yet. Has anyone else observed similar StoreKit behavior recently on iOS 17+? Any insights or known issues would be greatly appreciated.

My app is live on the App Store and all three auto-renewable subscriptions are Approved, but StoreKit 2 never answers on device. Product.products(for:) does not settle — no products, no error, no throw. I let it run 30 seconds. Storefront.current behaves the same way, so this is not a product-id or catalogue problem. StoreKit is not reaching a store at all. Already ruled out: Product ids app.steady.pro.weekly / .monthly / .yearly, all Approved; subscription group Approved Bundle id app.steady.calm, matches App Store Connect exactly Paid Applications Agreement Active, bank and tax forms Active In-App Purchase capability enabled on the App ID and present on the App Store provisioning profile Two iPhones, two Apple Accounts, storefronts AZ and TR, three networks A clean build run directly from Xcode on a different Mac — identical silence Also reproduced through a third-party purchases SDK before reverting to plain StoreKit 2, so it is not my bridge layer This has never worked once, on any device or account, since launch. It is not intermittent. Open with Apple: Developer Support case 20000143122321, Feedback FB24488724 with sysdiagnose attached. Has anyone seen Storefront.current hang like this? Is there an account-level state that can stop StoreKit from resolving a storefront even when the app and products are approved?