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 see different storefronts in StoreKit product queries and Apple’s purchase sheet when testing through TestFlight. Xcode-installed builds work normally. iPhone — iOS 26.6 (23G71), US Media & Purchases account Both StoreKit 1 and StoreKit 2 return CHN/CNY. The app displays CNY 128 for a non-consumable, but Apple’s sandbox purchase sheet shows USD 29.99 for the same product. This reproduces in a standalone 177-line Swift sample using Product.displayPrice directly, with no third-party dependencies, currency conversion, or local .storekit configuration. Reloading products and signing out of the sandbox account did not resolve it. Mac Catalyst — macOS 26.3 (25D125), China purchase account The original TestFlight app returns USA/USD. Purchasing shows “Account Not In This Store” and asks to switch to China, although the purchase account is already set to China. The Mac symptom has not yet been verified in the standalone sample. Reproduction on the affected iPhone: install via TestFlight, load products and log Storefront.current plus the SK1 storefront, open the purchase sheet for the same product, then compare currencies. No completed purchase is needed. Built with Xcode 26.1 (17B55). Has anyone found a workaround for this TestFlight-only mismatch? Should the app handle storefront updates differently, and which additional diagnostics would help distinguish a device/account-session issue from a StoreKit service issue? Feedback: FB24873070. A focused sample and diagnostic evidence are prepared for Apple Developer Technical Support. Reproduction on other devices/accounts is not yet confirmed.

Hello, We are currently seeing errors when validating receipts for every auto-renewable subscription purchased through both StoreKit 1 and StoreKit 2. Details below. Case 1 — StoreKit 1 Calling https://buy.itunes.apple.com/verifyReceipt with the subscription receipt returns: "status": 21006, "expiration_intent": "5" Case 2 — StoreKit 2 Calling https://api.storekit.itunes.apple.com/inApps/v1/subscriptions and reading the most recent transaction (LastTransactionsItem) returns status 3. Within JWSRenewalInfoDecodedPayload: autoRenewStatus = 1, expirationIntent = 5 Timeline We believe renewals stopped processing for essentially all auto-renewing subscribers of our app as of 2026-09-18 09:30 KST (UTC+9). After resolving an agreement/licensing issue on our side, new purchases and some receipt validations recovered as of 2026-09-21 11:49 KST. However, most existing receipts still return expirationIntent = 5 when we query receipt validation or subscription status. Questions Is any action required on our side — a server-side change, a configuration change in App Store Connect, or a further review of our agreements? Now that the agreement issue is resolved, when are the renewals that were left pending during the outage expected to be processed? Any guidance would be appreciated. Thank you.

Hi, I'm trying to run our StoreKit unit tests with Xcode26.5 on an iOS26.5 simulator. Host computer has macOS26.5. All tests are failing and in the console I see logs such as [SKTestSession] Error saving configuration file: Error Domain=SKInternalErrorDomain Code=3 "(null)" [SKTestSession] Error deleting all transactions: Error Domain=SKInternalErrorDomain Code=3 "(null)" [SKTestSession] Error clearing overrides: Error Domain=SKInternalErrorDomain Code=3 "(null)" [SKTestSession] Error setting value to 1 for identifier 2 for jp.unext.mediaplayer: Error Domain=SKInternalErrorDomain Code=3 "(null)" And the simulator asks me to provide my AppleID. Tests have been broken since at least 26.4 The release notes claims that it has been fixed but not for me. https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-26_5-release-notes#StoreKit-Testing-in-Xcode Does anyone else have the same issue? Reported FB22774836 just in case.

Hi everyone, I'm planning an iOS app that provides a personalized invitation-card creation service, and I'm trying to determine the correct payment method before starting development. The flow would be: User selects an invitation template. User enters their event/invitation details. The app generates a watermarked preview. User proceeds to checkout. User pays for the creation of the final personalized PDF. After successful payment, our backend places the request into a processing queue. The PDF is generated asynchronously on our server. Once completed, the user receives a notification and can download the final PDF. The purchase does not unlock an app feature, subscription, membership, or ongoing access to digital content. The user is paying for a specific personalized invitation document to be generated based on their selected template and information. Each template can have a different price. My question is: Would this type of personalized document-generation service be required to use Apple's In-App Purchase, or could an external payment processor such as Razorpay be used? I have reviewed the App Store Review Guidelines, particularly the sections concerning In-App Purchase and physical goods/services, but I'm not certain how Apple classifies a personalized digital document-generation service like this. If anyone has implemented a similar business model or can point me to the relevant Apple guideline or an official Apple clarification, I would really appreciate it. I'm asking before development so that the payment architecture can be designed correctly from the beginning. Thanks!

Hey We are implementing EU external purchases for both our iOS and native macOS apps as it's written here: https://developer.apple.com/br/support/payment-options-on-the-app-store-in-the-eu For our App ID, we enabled StoreKit External Purchases or Offers, whose entitlement key is: com.apple.developer.storekit.custom-purchase-link.allowed-regions The capability works for iOS, but newly generated macOS provisioning profiles do not contain this entitlement. In Certificates, Identifiers & Profiles, the capability itself shows Platform Support: iOS, tvOS, watchOS, visionOS - macOS is not listed. However, the StoreKit documentation for ExternalPurchaseCustomLink and the EU alternative-payment documentation appear to describe external-purchase support more generally. Could you please clarify: Is com.apple.developer.storekit.custom-purchase-link.allowed-regions currently supported for native macOS apps distributed through the Mac App Store? If not, what entitlement and API should a native macOS app use for EU external purchases and external-purchase token reporting? Is macOS support for the StoreKit External Purchases or Offers entitlement planned or available through a separate entitlement request? At the moment, our macOS provisioning profiles cannot contain this entitlement because macOS is not listed as a supported platform for this capability. Thank you!

One user of my app reached out reporting an interesting in-app purchase issue. Has anyone encountered this or have an idea what's going on here? Proceed to purchase the non-consumable IAP in the app downloaded from the App Store iOS shows the price sheet as expected Confirm with the side button iOS shows an alert "You've already purchased this. Would you like to get it again for free?" Tap OK iOS shows an alert "You're all set. Your purchase was successful." Tap OK The app's content remains locked Tap Restore Purchases iOS shows an alert to sign (with the same account shown in step 2) Input the password and tap OK iOS shows an alert "Unable to Complete Request" (which is the error.localizedDescription thrown from AppStore.sync())

Following the guidance in the locked thread "Reporting your App Store Server Notifications issue" (https://developer.apple.com/forums/thread/774053) and a DTS support request on the same topic, I am posting this issue with the Feedback Assistant ID requested there: FB24820430. Summary: This is a content anomaly in Apple-signed App Store Server payloads, not a notification delivery problem — our server receives and verifies every notification; the defect is in the field values themselves. For a stable subset of subscription families, purchaseDate in JWSTransactionDecodedPayload is consistently ~8 hours later than the signedDate of the very same JWS — a purchase recorded as happening after the signed document reporting it existed. Reproducible field comparison inside one and the same Apple-signed JWS: Field relation Affected transactions Unaffected (control) transactions purchaseDate − signedDate +7h54m … +7h59m (never ≤ 0) ≈ 0 (seconds) Webhook arrival at our server ≈ signedDate (seconds to minutes), never ≈ purchaseDate ≈ signedDate originalPurchaseDate carries the same ~8h shift (renewals inherit it) no shift expiresDate − purchaseDate exactly one subscription period exactly one subscription period expiresDate − signedDate period + ~8h period All fields are documented as "UNIX time, in milliseconds". Our iOS client passes StoreKit 2 Transaction.purchaseDate through unmodified; our backend stores the epoch-millisecond values verbatim as UTC with no timezone conversion. These payloads are generated and signed by Apple infrastructure. Scale (production, as of 2026-09-14): ≈710 subscription families (distinct originalTransactionId lineages), ≈2,700 transactions — roughly three quarters of all families with renewals. Affected purchases span early March 2026 to present, ~30–45 new affected transactions per day. Observed across US, PH, ID and GB storefronts and across app build versions. Sandbox is unaffected. Our interpretation (inference, not confirmed): the offset varies between 7h54m and 7h59m rather than being exactly 8h, consistent with a local wall-clock time in a UTC+8 environment having been encoded as if it were UTC when the original transaction record was created, then inherited by all renewals of that family. Questions for Apple engineers: Is this a known issue in App Store Server data, and is there a reference we can track? What conditions cause a family's purchaseDate to be recorded this way (storefronts/regions, purchase channels, offer types, original-receipt formats)? When purchaseDate and signedDate disagree, which field is authoritative for "when the customer was charged"? The public documentation defines each field only as "UNIX time, in milliseconds" and does not define its relationship. Is remediation planned on Apple's side, or what is the recommended way to obtain the true charge time? Evidence: A focused sample project (a ~85-line Swift tool plus four unmodified signedTransactionInfo JWS samples — three affected families and one unaffected control, each carrying Apple's x5c certificate chain) is included in Feedback Assistant report FB24820430, together with the raw HTTP notification bodies for an affected and a control notification, exactly as delivered to our endpoint. Thank you.

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

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?

I am testing a StoreKit 2 non-consumable IAP through TestFlight. Product ID: com.metabolla.plus.lifetime Type: Non-Consumable Environment: TestFlight / Sandbox Transaction.currentEntitlements keeps returning an active entitlement for this product even after: configuring a Sandbox Apple Account clearing Sandbox Purchase History reinstalling the app rebooting the device Important detail: the first TestFlight purchase was completed before configuring the Sandbox Apple Account on the device. If I temporarily change the Product ID in code, the entitlement disappears, so the issue seems tied to the original Product ID/account/receipt. Question: Can a non-consumable TestFlight purchase made before Sandbox Apple Account configuration remain associated with the original TestFlight/Apple ID identity? Is there any supported way to clear this entitlement for testing?

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