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

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

App Store Server Notification returns successful purchase while customer's payment remains Pending We have encountered an edge case with a Non-Renewing Subscription and would appreciate clarification on the expected developer behavior. Steps to reproduce User initiates an in-app purchase using a credit card. The purchase succeeds in the app. Our backend receives an App Store Server Notification V2 (ONE_TIME_CHARGE). We successfully verify the signed JWS transaction. The same transaction is also returned by the App Store Server API. Based on the verified transaction, we grant the user's entitlement. However, on the customer's Apple account: The purchase is shown as Pending in Purchase History / Report a Problem. The customer reports that their credit card has not yet been charged. Question From a developer's perspective, should entitlement be granted immediately after receiving a valid App Store Server Notification and successfully verifying the transaction, even if the customer's purchase is still shown as Pending? Is there any App Store Server API or transaction field that indicates the payment has not yet been settled, allowing developers to delay granting entitlement until the payment is finalized? Or is the expected implementation to grant entitlement upon successful transaction verification and revoke it only if Apple later sends a refund notification? Any clarification on the expected workflow would be greatly appreciated. Thanks in advance. :)

Team ID: 3HH6VYS8CR App ID: br.com.manipro.app (Apple ID 6806726054) Xcode 26.6, iOS SDK 26.5. Individual membership based in Brazil. The app is available on the Brazil storefront only. We want to offer an alternative payment option in Brazil, following "Payment options on the App Store in Brazil". What we have done: The Account Holder accepted the latest Apple Developer Program License Agreement (issued August 18, 2026, accepted August 30, 2026). The Paid Apps Agreement is active. The "StoreKit External Purchases or Offers" capability is enabled on the App ID. We also disabled and re-enabled it on the developer website as the Account Holder. The app's entitlements file contains com.apple.developer.storekit.custom-purchase-link.allowed-regions = ["br"]. What happens: The Xcode-managed development profile ("iOS Team Provisioning Profile: br.com.manipro.app") includes the entitlement with jp, br and the 27 EU country codes. The Xcode-managed App Store profile ("iOS Team Store Provisioning Profile: br.com.manipro.app") includes the entitlement with the 27 EU country codes only. "br" and "jp" are missing. We regenerated it three times on October 10, 2026, with the same result. xcodebuild -exportArchive (automatic signing, App Store Connect method) therefore fails with: Provisioning profile "iOS Team Store Provisioning Profile: br.com.manipro.app" doesn't match the entitlements file's value for the com.apple.developer.storekit.custom-purchase-link.allowed-regions entitlement. During export, Xcode also enables the "StoreKit External Purchases or Offers (EU)" capability on the App ID by itself. Expected: the App Store profile includes "br", as the development profile does, so the app can be distributed with the entitlement for Brazil. Question: what else does this account or App ID need so that App Store distribution profiles include "br" for this entitlement? Feedback Assistant: FB25141486

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

Hey there! Is it possible to offer a licensing model instead of a subscription model to the users. My goal is that a user can forward a license, for example when he doesn't need it anymore. As far as I know this isn't possible with StoreKit, since then the purchase is always assigned to the specific Apple ID, right? Is a licensing model allowed to be offered through the AppStore?

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.

Hello. I have setup a StoreKit testing in the app that was and still is perfectly working on iOS 18. Unfortunately when run on iOS 26 the following error gets printed in the console after calling Transaction.currentEntitlement(for:) method: Failed to verify certificate chain due to client recoverable failure: Error Domain=NSOSStatusErrorDomain Code=-67843 "“StoreKit Testing in Xcode” certificate is not trusted" UserInfo={NSLocalizedDescription=“StoreKit Testing in Xcode” certificate is not trusted, NSUnderlyingError=0x109de7e10 {Error Domain=NSOSStatusErrorDomain Code=-67843 "Certificate 0 “StoreKit Testing in Xcode” has errors: Root is not trusted;" UserInfo={NSLocalizedDescription=Certificate 0 “StoreKit Testing in Xcode” has errors: Root is not trusted;}}} I'm not seeting any StoreKit Testing certificates in phone's certificate trust settings. This test was performed on iOS 26.0 (23A341) with app built in Xcode 16.4. FB20339145

Hello, I’m investigating subscription product discovery in my iOS app, BiteTempo. StoreKit 2 completes the product request successfully but returns an empty array for both auto-renewable subscriptions. The issue occurs on a physical iPhone running through Xcode and also in TestFlight. App and products Bundle ID: shehan.NouriJournal App version: 1.0 (4) Monthly: shehan.NouriJournal.plus.monthly Annual: shehan.NouriJournal.plus.annual Reported storefront: USA Device system version reported in diagnostics: 26.6.1 (23G83) Reproduction Run the app on a physical iPhone through Xcode with StoreKit Configuration set to None. Open the subscription paywall. Request both products using Product.products(for:). Inspect the returned array immediately after the awaited call, before filtering. At that breakpoint, returnedProducts contains 0 values. The empty result is not created by application filtering or by converting a caught error into an empty array. Errors are reported separately. Diagnostic output from the Xcode device run Date: 2026-09-26T10:06:24Z App: shehan.NouriJournal 1.0 (4) Storefront: USA Requested: shehan.NouriJournal.plus.monthly, shehan.NouriJournal.plus.annual Returned: 0 Products: Lookup: completed I also see unavailable plans in TestFlight, although the diagnostic output above is specifically from the Xcode device run. Configuration checked Product IDs match App Store Connect exactly. Both subscriptions have pricing and all-country availability. Both products and their subscription group have English (U.S.) localization. Paid Apps Agreement is Active. Other apps under my developer account have working live subscriptions. Debug and Release use the same bundle identifier and signing team. No local StoreKit configuration file is selected. A Sandbox Apple Account is signed in on the test device. These are the first subscriptions for this app and have not yet been submitted for review. I have retried after completing the missing localization, but the result remains empty. The failure occurs during product discovery, before any purchase or server-side transaction verification. What additional checks or diagnostics would help distinguish an app/signing configuration issue from a sandbox product-catalog availability issue? Is there any additional product state or configuration required for these subscriptions to appear in sandbox? I have also submitted a support request to Apple and can provide a minimal reproduction project through the appropriate support channel. Thank you.

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

Is there any way to activate Storekit External Purchase Entitlements in Russian region currently? External Purchase documentation's form link for this specific region is not working. Is there a workaround to register for it?

Our iPad application uses authenticated accounts in our own service. Before enabling access for a member receiving an assigned subscription, we need to establish that the actual assigned Apple member authorized enrollment into the intended account in our service. The unresolved case is another authenticated application account presenting forwarded, genuinely Apple-signed member transaction or app transaction evidence. We need to understand the supported verification boundary that prevents possession of that evidence from being sufficient to acquire another member's access. Personal purchase ownership will remain separate from assigned-member access. Proposed flow for review: The app obtains AppTransaction and the assigned Transaction directly from StoreKit and checks both against the current device using the documented device-verification procedure. It then proposes an App Attest assertion over the exact evidence and a server-issued challenge associated with the authenticated application account. The proposed client method accepts no forwarded JWS input. Our server would separately authenticate the service session and verify the attestation, assertion, Apple-signed evidence, current assignment and subscription lifecycle before granting access. Is this composition supported for authenticating assigned-member enrollment? Specifically, may the server rely on the direct StoreKit capture and local device checks within the attested app to establish that the same Apple member authorized the intended application-account association? What connects the StoreKit member/device verification, the App Attest key and the intended account, so that a valid assertion over forwarded authentic evidence would not be sufficient? Please identify the required server validation and trust assumptions, or an additional supported API/protocol if the proposal is insufficient. We also need to understand recovery after reinstall or an application-account switch, and the applicable Sandbox, TestFlight and Production support. Matching identifiers or a first successful claim must not transfer another member's access. What we have checked: The StoreKit deviceVerification documentation describes checking whether a transaction belongs to the device. The App Attest server-validation guide describes attestation, assertions, one-time challenges and per-user/device key association. We have not found an explicit assigned-member enrollment contract covering their composition. The closest existing discussions are "Scoping App Attest keys to an appTransactionID" and "Is keying off Storekit's AppTransactionID a valid pattern for storing keys?" They discuss key organization for anonymous users; they do not resolve this assigned-member enrollment question. This is an API and trust-contract clarification. A focused, newly authored sample was supplied privately to DTS. It contains no customer records, credentials, captured transaction evidence or production source. The sample was prepared using Xcode 27.0 on macOS 27.0.1 and targets iOS/iPadOS with the iOS 27 SDK. Swift syntax and project-file parsing passed, but it has not been compiled, signed, installed or device-tested. The default app displays the question; it invokes no StoreKit, App Attest, purchase, enrollment or network calls. We have not enabled assigned-member grants or claimed a reproduced Apple defect. References: https://developer.apple.com/documentation/storekit/transaction/deviceverification https://developer.apple.com/documentation/devicecheck/validating-apps-that-connect-to-your-server https://developer.apple.com/videos/play/wwdc2026/391/ https://developer.apple.com/documentation/appstoreserverapi/get-customer-groups https://developer.apple.com/forums/thread/833174 https://developer.apple.com/forums/thread/831468

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

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

Hello everyone, I am designing an in-app subscription and pass extension/upgrade system for an iOS app and want to ensure full compliance with App Store Review Guideline 3.1.1. Because pricing in our system depends on the user's historical purchase price rather than static store catalog prices, direct fixed-SKU purchases aren't sufficient on their own. Business Logic Overview Extensions: An extension costs 50% of the price the user originally paid for their plan. Example: If a user bought Plan A at $200, their extension cost is $100 (even if Plan A currently retails at $150). Upgrades: An upgrade charges the delta between the target plan's current price and the user's original purchase price. Example: A user bought Plan A for $200, and Plan B currently costs $250. The upgrade cost is $\max(0, 250 - 200) = 50$. Proposed Technical Solution User requests an extension or upgrade from the iOS client. The backend server calculates the exact delta amount based on user purchase history. The backend maps this calculated amount to a pre-defined Tiered StoreKit Product ID (e.g., com.app.tier_50). The iOS app receives the Product ID and executes the transaction via StoreKit 2 (Product.purchase()). The backend validates the transaction JWS signature with Apple and updates the user's access duration. Questions for the Community & Apple Engineers Has anyone implemented backend-resolved dynamic Tiered SKUs for top-ups or price deltas? Did this pass App Review without issues under Guideline 3.1.1? Are there recommended patterns when configuring price-point tier SKUs (Consumable vs Non-Renewing Subscription) in App Store Connect for variable delta payments? For auto-renewing subscriptions, is it preferred to handle extensions strictly via StoreKit 2 Promotional Offers rather than delta SKUs? Any feedback or real-world experience with similar pricing structures would be greatly appreciated!

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

Hello, I am the Account Holder of an Individual Apple Developer Program membership based in the Russian Federation. I am trying to request the StoreKit External Purchase Link Entitlement (RU) for my iOS app. The app itself is free to download. It does not use and is not intended to use Apple In-App Purchase. Premium digital content is provided through a subscription purchased on our external website. Apple currently documents StoreKit External Purchase Link support for Russia. However, when I open the official StoreKit External Purchase Link Entitlement (RU) request form, I cannot submit the request unless I have accepted the latest Paid Applications Agreement. The problem is that the Paid Applications Agreement is not available in my App Store Connect account. Apple Developer Support informed me that, because my Apple Developer Program membership is located in the Russian Federation, I am currently unable to distribute paid applications or applications using In-App Purchases due to applicable sanctions. This creates a circular situation: StoreKit External Purchase Link (RU) is officially available for Russia. The entitlement request form requires the Paid Applications Agreement. My Russian developer account cannot accept the Paid Applications Agreement. Therefore, I cannot submit the entitlement request. My intended purchase flow is: Free iOS app → user account → StoreKit External Purchase Link → external website → digital subscription → access activated in the app. Has anyone with a Russian Apple Developer account successfully obtained the StoreKit External Purchase Link Entitlement recently? Is there an official manual process for Russian developers who cannot accept the Paid Applications Agreement? Can this entitlement request be processed manually by Apple Developer Support or another Apple team? I would especially appreciate guidance from an Apple engineer regarding the officially supported path for this situation. Thank you.

Feedback: FB25016556 (includes sysdiagnose and device log archives) Since our Apple Developer Program membership lapsed on Sep 26, 2026 (renewed Sep 27), Product.products(for:) returns an empty array for every In-App Purchase of our app, in both production and sandbox. No error is thrown. Customers can't subscribe. App: bundle ID com.thefuntasty.gastromapa, live version 2.2.1 (worked fine until Sep 26, no code changes since). Products (both Approved, available in all countries, priced, localized): com.thefuntasty.gastromapa.subscription.premium (auto-renewable) com.thefuntasty.gastromapa.donation (non-consumable) Verified against TN3186 / TN3188: Membership active, latest Program License Agreement accepted (Account Holder checked) Paid Apps Agreement Active (effective Sep 29, 2026), nothing left to sign Bank account and tax forms Active Product IDs and bundle ID match the app record, In-App Purchase capability enabled on the explicit App ID Sandbox test build signed with a freshly regenerated development profile Apple Developer Support (phone) confirmed account, agreements and products look correct and referred us here storekitd log, identical in production and sandbox: Requesting Media API product batch ["com.thefuntasty.gastromapa.subscription.premium"] ... response_status=200 Media request MediaAPIProductRequest correlation key: KKP646ABIQJTWR5GGC3UBLBJDU Ignoring empty product response Correlation keys: Oct 1, 2026, 14:15 CEST, production, iOS 27.0.1 (24A446): KKP646ABIQJTWR5GGC3UBLBJDU Sep 30, 2026, 15:30 CEST, production, iOS 27.0: 3VRU2QHLFRRMP2UBTYG4ZSIBPQ Sep 30, 2026, 15:45 and 15:51 CEST, sandbox: VF6Y3XNFTZXPBRKX6VCKSJNB3U, V7Q3K5JTJ46PB6D2HGKCY5RINU This looks similar to https://developer.apple.com/forums/thread/845526. Could someone from Apple check whether our In-App Purchases were deactivated in the store catalogue when the agreement expired, and reactivate them? It's blocking all revenue for the app.

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

In one observed Restore Purchases attempt from a Release build distributed through TestFlight on a physical iPhone, try await AppStore.sync() threw an error that our Swift classifier matched to StoreKitError.unknown. Our Restore handler did not reach its subsequent entitlement-enumeration or backend-verification steps. Environment: iPhone 17 Pro Max. The device was independently checked afterward and was running iOS 26.7 (23H24); the OS version was not independently recorded at the exact failure time. Intended handler flow The user explicitly taps Restore Purchases. Call try await AppStore.sync(). Enumerate Transaction.currentEntitlements and accept only verified, eligible transactions for the expected subscription. Send the eligible signed transactions to our backend for verification. Observed attempt Narrow native Console events and a memory-only, sanitized in-app report matched the same attempt. The sync failure was recorded roughly 16 seconds after sync started. We are not treating that duration as evidence of a timeout. The owner reports completing Apple's authentication prompt during this specific attempt. The app displayed: “Purchases could not be restored. Please try again.” Existing Premium access remained displayed before and afterward. We do not count that as successful restoration. We have not retried since this captured attempt. The error matched StoreKitError.unknown. Our sanitized report did not capture an underlying error or numeric error code; this does not establish that no additional diagnostic information exists elsewhere. Current App Store Connect checks show the expected app/subscription-group association, subscription status Ready for Review, all countries or regions selected, and an active Paid Apps Agreement. These status checks do not establish that the configuration is the cause or that every configuration detail is correct. Question What supported, privacy-safe diagnostic should we collect to distinguish causes when AppStore.sync() throws StoreKitError.unknown, without exposing account details, transaction identifiers, receipts, or tokens? If a focused reproducer is needed, is there a recommended way to isolate this TestFlight StoreKit context without weakening transaction verification or changing account/purchase history? We are not asserting an Apple defect or an account/configuration problem. No raw logs or account/transaction data are attached.

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.