We're currently having an issue with our app where the review prompt is displaying for the user too often. I know the documentation says that: If the person hasn’t rated or reviewed your app on this device, StoreKit displays the ratings and review request a maximum of three times within a 365-day period. If the person has rated or reviewed your app on this device, StoreKit displays the ratings and review request if the app version is new, and if more than 365 days have passed since the person’s previous review. From this post I can see that there's an updated API that is recommended AppStore.requestReview(in:). Is there a currently known bug with the SKStoreReviewController version that would cause the review prompt to display outside of the limitations? Locally we're seeing a limit of 3 prompts in the same session but a few days later, we get the same 3 prompt limit when it's should have been limited for another year. Does using the AppStore version just fix our issue? Is it actually a different API?

Filed as FB24069273. Sandbox POST /inApps/v1/notifications/test consistently returns 404 {"errorCode":4040007} for our app (Apple ID 6765662617), although GET /v1/apps via the App Store Connect API confirms both subscriptionStatusUrl and subscriptionStatusUrlForSandbox are set (V2). With the same JWT, sandbox POST /inApps/v1/notifications/history returns 200 with an empty history — so the key and app resolve correctly. No organic sandbox notifications have ever been delivered, despite active TestFlight sandbox subscription activity. Exhausted remediations (4040007 persists after each, with 30-60+ minute waits): Re-saving the URLs in the App Store Connect UI (two locales) Deleting and re-adding the Sandbox URL PATCH /v1/apps setting the sandbox URL + version V2 twice, with two different valid endpoints (verified by GET each time) Removing the Sandbox URL entirely to rely on the documented Production fallback Deleting BOTH URLs, waiting a full hour, and re-creating them from scratch Testing with both an App Store Connect team key and a freshly generated In-App Purchase key — identical results Endpoints are publicly reachable (HTTPS, TLS 1.2+, port 443). Production App Store Server API returns 401, which we understand is expected for an app not yet released. This looks like a desync between App Store Connect metadata and the notification delivery registry consulted by the test-notification endpoint. Any help would be appreciated.

I have 2 iOS app products. One can fetch subscription product information normally, while the other fails with the error errorCode 4040004 'App not found' in Sandbox. The App Store Connect backend configuration should be fine, and the subscription code on the app side is the same codebase for both. I really can't find the root cause anymore — if anyone knows what's going on, please point me in the right direction. Also, I'm able to sync/download the StoreKit product configuration file from App Store Connect directly in Xcode, which should also confirm that my App Store Connect backend configuration is correct.

Hello Applet, I’m experiencing an issue with StoreKit on a TestFlight build. My app uses auto-renewable subscriptions through StoreKit and RevenueCat. Configuration already verified: App installed through TestFlight (not debug). Bundle Identifier: com.ciborgu.vytalai Paid Applications agreement is active. In-App Purchase capability is enabled. Three auto-renewable subscriptions exist in App Store Connect. Product IDs match exactly between App Store Connect, RevenueCat and the application. RevenueCat initializes successfully. A Sandbox test account has been created. Tested on a physical iPhone. Device restarted and app reinstalled from TestFlight. VPN and iCloud Private Relay disabled. When attempting to purchase a subscription, the Apple payment sheet never appears. Our diagnostics indicate that StoreKit does not return any available products for the configured Product IDs, preventing the purchase sheet from opening. Expected Product IDs: vytalai_premium_monthly vytalai_premium_yearly vytalai_premium_yearly_intro Could you please verify if there is any issue with the App Store Connect configuration, StoreKit availability, or the processing state of these subscriptions on Apple’s side? If additional logs or diagnostics are required, I can provide them. Thank you. I have already contacted Apple Developer Support regarding this same issue. Previously, I was advised to schedule a technical support meeting. However, when I requested the meeting, my request was declined because of the subject of my issue, so I was unable to speak with an Apple engineer. Since I have now completed all the recommended troubleshooting and the issue still persists, I would greatly appreciate it if this case could be reviewed by the appropriate technical team or a StoreKit engineer. Thank you for your assistance.

Need to vent a bit before relaxing for Christmas... WatchOS IAP using Storekit 2 is such a mess...is nobody actually using this or does Apple just not care for the user experience here? Lots of users experience after the purchase confirmation double tap on the side button an instant return to the purchase screen with nothing actually happening. No error message whatsoever. There is just one remedy: users need to unpair and re-pair their watch, including restoring a backup and setting up their wallet again. Nobody really wants to do this, or doesn't believe me and think this is just typical support BS, because their watch is paired and most things just work as they expect. And it turns away a customer, often leaving a bad review. And I can't do anything about it. Other errors in the purchase process are reported, but like "process interrupted" in case the payment is not setup correctly (credit car no longer valid or sth.). How should the user know? There must be better ways of letting him know what exactly the problem is. You need to implement a "Restore Purchase" function, otherwise you're not passing the review. But it really asks every time for the AppStore password, and users with crazy passwords -- that they rightfully should have! -- have almost no chance of typing them successfully on the tiny AW keyboard. Why is it not also just a side button double tap like for purchase? At the very least you would need access to the keychain PWs or allow pasting of sth. copied on the paired iPhone. Promo Codes for IAP on AW-only apps just don't work. AW has no redemption at all, and on the iPhone the AppStore will try to talk to a companion app (which AW-only doesn't have) and the end up in a dead-end installation effort. This all feels like never really tested in the field, and people are of course blaming the 3rd party dev. for all these issues. And opening a ticket is just leading nowhere -- at best it's closed after months with the hint "duplicate" but w/o any chance for me to see that one that they then actually work on and track progress. It's all so frustratingly broken...

I'm testing an In-App Purchase for the Indonesian storefront. In App Store Connect, the price is configured as Rp 1,299,000, and it is displayed correctly there. However, in the Sandbox purchase sheet, the price is shown as "Rp 1,299 juta" instead. I understand that "juta" means million in Indonesian. However, I'm not sure whether displaying the price as "Rp 1,299 juta" is the expected localization for users. Any confirmation or experience would be appreciated. Thank you!

Hi, Feedback: FB23494579 Using StoreView / ProductView on iOS 27.0 simulator / device hub throws the following error: Error: Accessing State<ProductViewEventConfiguration>'s value without being installed on a View. This will create a new ProductViewEventConfiguration instance each time. Environment macOS 26.5.2 (25F84) Xcode 27.0 beta 2 (27A5209h) Simulator / Device Hub - iPhone 17 Pro (iOS 27.0) Screenshot

Could you help clarify the expected behavior in downgrade scenarios during a Free Trial period? Does Apple trigger billing immediately for the downgraded plan, or does the change take effect only after the Free Trial window completes?

I am experiencing an issue with a non-consumable in-app purchase in my iOS app. The product loads correctly from the App Store and is displayed in the app, but when attempting to complete the purchase, StoreKit returns the following error: Payment completed with error: Error Domain=ASDServerErrorDomain Code=3504 "This item cannot be found." UserInfo={ NSLocalizedFailureReason=This item cannot be found., AMSServerErrorCode=3504, client-environment-type=Sandbox, storefront-country-code=USA } The same issue was also encountered by the App Review tester when they attempted to purchase the non-consumable product during review. The product: Is correctly configured in App Store Connect Has active pricing Is available in the United States Was included in the app submission Loads successfully and displays the correct price Fails only when the purchase is initiated Since the product metadata can be retrieved successfully, but the transaction fails with “This item cannot be found,” this appears to be a possible inconsistency between the StoreKit product catalog and the purchase backend. Has anyone encountered ASDServerErrorDomain Code=3504 for a non-consumable product that loads correctly but cannot be purchased? Is there any known App Store sandbox or commerce backend issue that can cause this, or any additional App Store Connect configuration that should be checked?

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. :)

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!

Hello Apple Developer Support / StoreKit team, I am testing auto-renewable subscriptions on a real iPhone device using Settings > Developer > Sandbox Apple Account > Test Transactions. I found that subscriptions work correctly for one of my apps, but fail for another app under the same Apple Developer account. Working app Bundle ID: com.benbendou.pinyincharacter Product ID: xpyxhz.quarterly Result: The sandbox purchase sheet appears and the subscription flow can be completed successfully. Failing app Bundle ID: com.benbendou.chengyudaquan Product ID: cydq.quarterly Result: The Test Transactions flow fails. In my app, Product.products(for:) can load some subscription products successfully. However, when trying to purchase cydq.quarterly, the purchase fails with: errorCode = 4040004 errorMessage = "App not found. Please try again." Because the same issue also happens in iPhone Settings > Developer > Sandbox Apple Account > Test Transactions, using the exact Bundle ID and Product ID, this does not seem to be caused by my app’s StoreKit code. The strange part is that another app under the same developer account works correctly with Test Transactions, but this app does not. Could Apple please help check whether the Bundle ID / app record / subscription group / in-app purchase products for com.benbendou.chengyudaquan are correctly linked in the StoreKit Sandbox backend? It looks like the sandbox environment can load the product metadata, but cannot complete the purchase or find the app during transaction lookup. Thank you.

We have a new iOS app in App Store Connect with six consumable in-app purchases. Environment: Bundle ID: live.mymi.ios TestFlight version: 1.0.4 (70) Storefront: KOR Environment: Sandbox Example product ID: ios_spark_5000 StoreKit product queries return all six products with localized KRW prices. For example, ios_spark_10000 is returned as ₩12,000. However, requesting a purchase fails with Product.PurchaseError.productUnavailable / “This item is not available.” The issue can also be reproduced independently of the app: Settings > Developer > Sandbox Apple Account > Test Transactions Entering bundle ID live.mymi.ios and product ID ios_spark_5000 is rejected with a message stating that the product ID or bundle ID is invalid. The previous app/product pair live.mymi.app + spark_5000 still works on the same device and with the same Sandbox tester. We verified the following: Paid Apps Agreement, banking, and tax information are active The explicit App ID has the In-App Purchase capability enabled The TestFlight build uses the correct bundle ID Product pricing, localization, and availability in all 175 storefronts are configured All six IAPs are attached to the first app version review submission No local StoreKit configuration is involved This has persisted for multiple days. It appears that the product-query catalog contains the products, while the Sandbox transaction service does not recognize the product-to-bundle association. Has anyone seen this with a newly created App Store app/IAP catalog? Did Apple need to re-index the products?We have a new iOS app in App Store Connect with six consumable in-app purchases. Environment: Bundle ID: live.mymi.ios TestFlight version: 1.0.4 (70) Storefront: KOR Environment: Sandbox Example product ID: ios_spark_5000 StoreKit product queries return all six products with localized KRW prices. For example, ios_spark_10000 is returned as ₩12,000. However, requesting a purchase fails with Product.PurchaseError.productUnavailable / “This item is not available.” The issue can also be reproduced independently of the app: Settings > Developer > Sandbox Apple Account > Test Transactions Entering bundle ID live.mymi.ios and product ID ios_spark_5000 is rejected with a message stating that the product ID or bundle ID is invalid. The previous app/product pair live.mymi.app + spark_5000 still works on the same device and with the same Sandbox tester. We verified the following: Paid Apps Agreement, banking, and tax information are active The explicit App ID has the In-App Purchase capability enabled The TestFlight build uses the correct bundle ID Product pricing, localization, and availability in all 175 storefronts are configured All six IAPs are attached to the first app version review submission No local StoreKit configuration is involved This has persisted for multiple days. It appears that the product-query catalog contains the products, while the Sandbox transaction service does not recognize the product-to-bundle association. Has anyone seen this with a newly created App Store app/IAP catalog? Did Apple need to re-index the products?

Hey All, My company has submitted no less than four requests over the last couple months trying to get approved to use the advanced commerce API. We have an approved app version, provided the product ID for what we want to use it for, just have never heard back. Anytime we call apple support, they take the submission ID and escalate it, then its radio silence from there. Wanted to see if anyone ran into this issue and how they got around it. We have been waiting around 2 months to be approved. Have not received a rejection, update, or anything that could shed some light into whats going on. Any pointers/help on this would be greatly appreciated!

We have 1 renewable subscription and 1 nonrenewable subscription which, as of yesterday, are in the approved state. I'm not even sure how they were approved because the Product.products(for: Self.productIDs) call is returning an empty array in production. We have the paid agreement signed, a valid bank account added, and everything else that is required. The product IDs being passed are correct. But the API is still returning an empty array. Is there some sort of system issue happening right now?

Hello, I’m experiencing what appears to be an app-specific Sandbox catalog propagation issue. Environment: Bundle ID: com.auroradrama.app App Store Connect App ID: 6786937298 StoreKit 2 Testing with a Sandbox Apple Account on a physical device An older product can still be fetched successfully: com.heroon.aurora.vip.year However, all newly created products return an empty result from Product.products(for:). Examples: com.auroradrama.pay.en.a.vip.week com.auroradrama.pay.en.a.coin.t1 com.auroradrama.test.coin001 The last product was created manually in the App Store Connect web interface, while the others were created through the App Store Connect API. Therefore, this does not appear to be specific to API-created products. Example result: Bundle ID: com.auroradrama.app Requested products: com.auroradrama.pay.en.a.vip.week com.auroradrama.pay.en.a.coin.t1 Returned product count: 0 Missing product IDs: com.auroradrama.pay.en.a.vip.week com.auroradrama.pay.en.a.coin.t1 I also tested the new product IDs using: Settings → Developer → Sandbox Apple Account → Manage → Initiate Purchase The system reports that the new product IDs are invalid. Therefore, the issue can be reproduced outside of my application code. I have verified through the App Store Connect API that the new products have: READY_TO_SUBMIT state Product versions in PREPARE_FOR_SUBMISSION Localization metadata A price configured for the United States Availability in 175 territories availableInNewTerritories enabled Valid subscription groups and subscription periods where applicable The Paid Applications Agreement, banking information, and tax information are all active. The app has the In-App Purchase capability enabled. Since an older product still works with the same app, Bundle ID, signing configuration, device, Sandbox account, and StoreKit code, these settings appear to be correct. The new products have remained unavailable for more than eight hours, which is well beyond the documented Sandbox metadata propagation period. Has anyone experienced a situation where old products remain available but every newly created product fails to enter the Sandbox StoreKit catalog? Could an Apple engineer please check whether the device-facing Sandbox catalog/index for App ID 6786937298 needs to be reprocessed or re-propagated? I can provide the App Store Connect resource IDs, timestamps, StoreKit logs, and a sysdiagnose privately if needed. Thank you.

Hi, Overview I am trying to write a unit test case to buy a storekit product. SKTestSession.buyProduct(identifier: options:) throws the error StoreKit.StoreKitError.notEntitled Testcase Code @Test func example() async throws { let session = try SKTestSession(configurationFileNamed: "VehicleStore") session.disableDialogs = true session.clearTransactions() do { let transaction = try await session.buyProduct(identifier: "nonconsumable.car", options: []) print(transaction) } catch { // Throws StoreKit.StoreKitError.notEntitled print("Error: \(error)") } } Storekit configuration file Note In-App purchases capability is added StoreKit configuration file is used in testcase Environment: macOS 26.5.2 (25F84) Xcode 26.6 (17F113)

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.

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!

I’m seeing an App Store Connect / StoreKit product-availability issue for a universal iOS + macOS app. Product ID: com.vincentchu.VideoAtlas.pro.lifetime The product is a one-time, non-consumable lifetime purchase. Current state: Both iOS and macOS apps are approved. The IAP status is Approved. I waited more than 24 hours after IAP approval before retesting. The IAP is configured for the universal app, is available in 175 storefronts, and has an effective price. Paid Applications agreement, tax, and banking are active; this account already has other paid apps. In-App Purchase capability is enabled for both targets. The product ID exactly matches the App Store Connect product ID. Production schemes have StoreKit Configuration: None. iOS is tested from TestFlight, so it uses StoreKit sandbox. macOS is tested from a development-signed build against sandbox, also with no local StoreKit configuration. The app uses StoreKit 2: let products = try await Product.products( for: ["com.vincentchu.VideoAtlas.pro.lifetime"] ) The call does not throw an error, but returns an empty array on both platforms: StoreKit product request completed productIDs=com.vincentchu.VideoAtlas.pro.lifetime returnedCount=0 returnedProducts= StoreKit returned no products for requested productIDs= com.vincentchu.VideoAtlas.pro.lifetime As a result, the app cannot retrieve Product.displayPrice or offer the purchase. I have already followed "TN3186: Troubleshooting In-App Purchases availability in the sandbox", including checks for product identifier, bundle identifier, IAP capability, provisioning/signing, StoreKit configuration, sandbox testing, paid-app agreements, IAP approval, pricing, and storefront availability. Since this is an empty result rather than an error, and it persists more than 24 hours after approval on both TestFlight and macOS sandbox, is there an additional App Store Connect-side configuration or Apple-side issue that could cause an approved non-consumable IAP not to be returned by Product.products(for:)? Thanks.