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.

My app has been rejected twice under Guideline 2.1(b) because its In-App Purchases did not load during review. Both reviews used an iPad Air 11-inch (M3); the latest was on iPadOS 27.0.1. The reviewer's screenshots show the app's fallback state, which appears when StoreKit 2's Product.products(for:) returns none of the products. I can't reproduce it The same build loads all four products with their prices in every test I've run: TestFlight on iPhone and iPad (iPadOS 27.0), with a US account Run from Xcode with StoreKit Testing disabled, using a brand-new US sandbox account and a fresh install Starting offline and then reconnecting Signed out of the sandbox With In-App Purchases restricted in Screen Time Setup Four non-consumables, $0.49 USD, available in all countries, with localizations and review screenshots Submitted together with the app version (status: Waiting for Review) Paid Apps Agreement, banking and tax all active I've worked through Technote TN3186 (Troubleshooting In-App Purchases availability in the sandbox) Code Loading is a single call, retried a few times, and the user can tap Try Again: let products = try await Product.products(for: productIDs)Questions Is there anything that can stop products from being returned in the App Review environment but not in the sandbox? Is there a way to check what the review environment sees? Any help is appreciated.

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

Our universal-purchase app (iOS + macOS, StoreKit 2) offers a 14-day trial as a non-consumable priced ¥0/free in all storefronts (approved, available everywhere), plus a paid non-consumable unlock. Since late September we have 3 separate Apple Accounts (Japan storefront) where the iPhone purchase flow fails: Product.products(for:) returns the product, the App Store purchase sheet appears with the correct product and account. After confirming, the sheet shows "支払いを完了できませんでした" (Payment could not be completed). No .success result. Redeeming a FREE one-time offer code for the paid non-consumable (via the apps.apple.com/redeem URL) fails the same way on the same iPhones. The very same Apple Account, same day, on the Mac app: both the ¥0 purchase and the offer code succeed immediately, and the entitlement then shows up on the iPhone through Transaction.currentEntitlements. OS correlation so far: iOS 27.0.1: fails (2 accounts) iOS 26.7.1: fails (1 account) iOS 26.6.2: succeeds Sales and Trends shows 9 iPhone + 1 iPad successful trial purchases between Sep 26 and Oct 12, so this is not account- or product-specific. The accounts have valid payment methods (paid purchases in other apps work), no Screen Time restrictions, not Ask to Buy. Filed as FB25186860 with a sysdiagnose. Has anyone else seen free purchases failing on 27.0.1 / 26.7.1? Any known workaround besides directing users to the Mac app?

Hello, I have 2 subscription group. Each group have different plans and promotional offer. I was set 1 month free promotional offer in all plans. While I subscribe any plan IAP sheet is not showing 1 month free promotional offer. I already used with new sandbox account. How can I get promotional offer in IAP sheet?

We use Apple's official App Store Server Library for Node.js, version 3.1.0. Our latest Production Get Notification History check, on 24 October 2026 at 15:21 UTC, returned HTTP 401 with an empty response body. The request ran from our deployed backend. We verified the ES256 signature, JWT claims, 300-second token lifetime, Authorization header and system clock alignment. On 23 October, notification-history requests using the same JWT and server environment returned: Sandbox: HTTP 200 Production: HTTP 401 A separate Production Request a Test Notification also returned 401; no test notification token was issued. The latest check was only a history query, not another TEST request. The account owner confirmed that the existing In-App Purchase key is Active. Our first app version remains PREPARE_FOR_SUBMISSION and has never been publicly released. Separate Production and Sandbox notification URLs are saved with Version 2 selected. An Apple App Store Commerce Engineer described a first-production-release prerequisite in this discussion: https://developer.apple.com/forums/thread/806452 Does that prerequisite apply specifically to both Get Notification History and Request a Test Notification? Neither request uses a transaction ID. If these endpoints should authenticate before the first release, which additional app-specific authorization prerequisite or non-sensitive diagnostics should we check? Apple request IDs can be provided privately through an appropriate Apple support channel if requested.

Hello Apple Developer Community, We are developing an iOS application using StoreKit 2 with four consumable in-app purchase products. All four products have been successfully purchased using real Apple Sandbox transactions on a physical iPhone. The transactions were verified using the App Store Server API, and our backend credited the corresponding virtual points exactly once. However, we are encountering an issue when attempting to request a refund using StoreKit 2. Environment Xcode 27.0 Physical iPhone Apple Sandbox tester account StoreKit 2 Consumable in-app purchases App Store Server Notifications V2 Steps to reproduce Complete a consumable in-app purchase using an Apple Sandbox tester. Confirm that the transaction is verified and not revoked. Invoke the StoreKit 2 refund request sheet using beginRefundRequest. The Apple-provided interface displays a connection-related error. The API returns cancelled. Expected result The Sandbox tester should be able to submit a refund request through the supported Apple refund flow. Actual result The refund sheet displays a connection-related error and returns cancelled. No refund is confirmed, and the transaction remains non-revoked. We have successfully received a TEST notification through App Store Server Notifications V2, but this does not validate an actual REFUND notification. Questions Is beginRefundRequest supported for consumable in-app purchases in Apple Sandbox? Is this connection-related error a known Sandbox limitation? Is there an alternative supported way to generate a real Sandbox refund event? What is the recommended approach to validating the complete refund lifecycle, including App Store Server Notifications V2, for consumable products? Any guidance from Apple engineers would be greatly appreciated. Thank you!

We're getting user reports that the App Store rating prompt appears repeatedly — one user says they're prompted roughly every day, and that they still get the prompt after they've already left a rating. This contradicts the documented behavior, so I want to check whether others are seeing the same thing or whether there's a known regression. What the docs say should happen The system limits display to 3 occurrences per app within a 365-day period. For a user who has already rated/reviewed, StoreKit should only display again if the app version is new and more than 365 days have passed since their previous review. Has anyone else experience it?

Our approved app is held at Pending Developer Release because the production App Store Server API cannot find our notification URL, even though the Production Server URL is saved in App Store Connect. The failure has been constant since August. On October 20 we ran two tests that isolate it, and we would appreciate someone from App Store Server engineering checking the request UUIDs below. What works Sandbox Request a Test Notification, same In-App Purchase key, same bundle ID, same URL string as Production: HTTP 200, token issued, Get Test Notification Status reports sendAttemptResult SUCCESS 280 ms later. 2026-10-20 16:31:13 UTC · request UUID ad1708d2-8536-4204-9a7b-32ded5800d48 · correlation key VULQRUUFGZBAJGT3GLPNLAANJA Production Get Notification History, same key: HTTP 200 (0 records, app not yet released). 2026-10-20 16:40:08 UTC · request UUID 7aedd431-fcf1-b104-42cd-17cc599425e4 · correlation key PLW5IMP46GYQIQWNC7GFTFBF4Q What fails Production Request a Test Notification (both api.storekit.itunes.apple.com and api.storekit.apple.com): HTTP 404, errorCode 4040007, "No App Store Server Notification URL found for provided app." No testNotificationToken is issued, so Apple never contacts our endpoint. Most recent: 2026-09-30 11:25 UTC · request UUID 22a1e218-4cdc-3577-9e18-3e25caf64052 · correlation key EKQ6EGCM3Q2XPHQYHYS4V5SAKI Earlier: f0cf352f-828e-fd40-8c14-2000fb8181e3 (Sept 23), 74a8bbbd-cd43-a18b-c4ac-bba619232d1d (Sept 14), 412d6c9f-511c-4402-ba18-d33fcda1b916 and 4f88fc30-3a4c-b7da-5d67c2f88570 (Sept 4, two different keys) Already done Production Server URL verified as saved in App Store Connect; removed, saved, re-added, waited, retested. No change. Reproduced with Apple's App Store Server Library (Swift) and with a minimal client. Feedback filed: FB24641446. Developer Support escalated the case to engineering on September 18; no engineering response yet. The question In thread 806452 an App Store Commerce Engineer wrote that production API access is unlocked once an app has a release in production. Our production history call succeeds for an unreleased app, so we cannot tell from outside whether the notification URL lookup behind /inApps/v1/notifications/test is gated on first release. If it is, we will release today and retest; a one-line confirmation would end a seven-week hold. If it is not, the production notification URL record for this app appears to be missing or unreadable, and we would ask that it be inspected and rebuilt. Happy to run a fresh reproduction in any time window and post the UUID. App Apple ID 6793806173, bundle com.haullynx.app.

We use StoreKit 2 for auto-renewable subscriptions in one group. Each explicit purchase attempt is durably recorded before calling Product.purchase(options: [.appAccountToken(attemptUUID)]). The app never retries a possibly invoked attempt automatically. Access is based on verified Apple transactions plus current server subscription status and ownership checks. A purchase invocation was interrupted or returned an uncertain result. A later user-initiated AppStore.sync completes, and Transaction.all yields verified transactions for an earlier subscription. Server API v2 history queried using the signed appTransactionId also returns no transaction/renewal containing the later attemptUUID. We preserve the attempt as unknown: an old same-product receipt or an empty lookup does not prove its outcome. Does Apple provide a definitive, supported way to determine whether this exact invocation committed, using the supplied appAccountToken when no transaction ID was received? For an already subscribed customer, can a successful Product.purchase return an existing transaction whose appAccountToken differs from the newly supplied token? What documented correlation should recovery use? If no definitive per-attempt lookup exists, what recovery pattern do you recommend without treating absence as cancellation or permitting duplicate subscriptions across different Apple Accounts? The authentication problem encountered earlier was resolved by following Apple's TestFlight Media & Purchases/Sandbox account-selection instructions. The remaining question is exact purchase-outcome correlation. We are not asking to bypass verification or overwrite Apple account tokens. No app name, bundle ID, customer details, transaction identifiers, tokens, receipts, credentials or screenshots are included in this question.

Is there a supported way in StoreKit 2 or the App Store Server API to tell whether a user purchased a paid app or downloaded it through Family Sharing? Transaction.ownershipType covers in-app purchases. Is there an equivalent for the paid app itself in AppTransaction?

Hello Apple Developer Community, I'm developing an iOS app called Rozděluj – společné výdaje (Bundle ID: cz.rozdeluj.rozdelujapp). StoreKit returns no products for any of our four In-App Purchases in TestFlight. Environment iPhone running iOS 27.0.1 Flutter 3.47.5 in_app_purchase 3.3.1 in_app_purchase_storekit 0.4.13 TestFlight builds 57, 58 and diagnostic build 59 Products cz.rozdeluj.plus.yearly — auto-renewable subscription cz.rozdeluj.unlimited.yearly — auto-renewable subscription cz.rozdeluj.plus.lifetime — non-consumable cz.rozdeluj.unlimited.lifetime — non-consumable Diagnostic results Flutter IAP: isAvailable: true Products returned: 0 Not found IDs: all four Error: storekit_no_response Message: StoreKit: Failed to get response from platform. We also added an independent native Swift StoreKit 2 diagnostic using Product.products(for:) with the same four identifiers. Native result: status: ok count: 0 foundIDs: [] missingIDs: all four The native query completed without throwing an error, but returned an empty product array. Configuration verified Bundle ID matches App Store Connect. In-App Purchase capability is enabled. Paid Apps Agreement, bank account and tax forms are Active. Product IDs match exactly. Pricing and worldwide availability are configured. Czech localization is configured for the inspected product. Automatic App Store distribution signing is enabled in Codemagic. All four IAPs currently have Rejected status following an App Review Guideline 3.1.2 rejection related to missing Terms of Use links. The app has since been updated to address that issue. Questions Could the Rejected status prevent these products from being returned by StoreKit 2 in TestFlight Sandbox? Is there another App Store Connect or Sandbox configuration that could cause Product.products(for:) to return an empty array without throwing an error? What additional diagnostics would help identify the cause? I would appreciate guidance before recreating any products or modifying the purchase implementation. Thank you!

Many of my purchases are encountering an issue when using a promotional offer (with a promo offer signature included). On the client side, everything works properly, and the purchase triggers the .success() callback. However, there are no updates in either the transaction/renewal info or via webhooks. According to the documentation, at least one of these server notifications should be triggered: OFFER_REDEEMED or SUBSCRIBED/RESUBSCRIBED. My server did not receive any signals. Furthermore, when I fetched the subscription status using the App Store Server API, the offer identifier did not appear in either the renewal info or the transaction info.

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.

Hello, I am investigating a subscription price mismatch in U&ME, TestFlight version 1.1.0 (20). I submitted Feedback Assistant report FB25210596 on October 16, 2026. The iPhone tester reports iOS 26.5. The exact device model and full OS build still need to be collected. Our latest device diagnostic at 2026-10-16T08:16:52Z shows the same Storefront.current values before and after Product.products(for:): id: 143465 countryCode: CHN currency.identifier: CNY However, the returned products have priceFormatStyle.currencyCode == "USD": com.ume.dailyphoto.duo.monthly: displayPrice US$3.99; introductory offer US$1.99. com.ume.dailyphoto.trio.monthly: displayPrice US$4.99; introductory offer US$3.99. A read-only App Store Connect check confirmed China availability and these configured China prices: duo CNY 25 monthly / CNY 15 for the first month; trio CNY 35 monthly / CNY 25 for the first month. The returned USD prices match our configured US prices. Both subscriptions currently have READY_TO_SUBMIT status. The tester followed the dedicated China-mainland Sandbox Apple Account setup and a subsequent requested device restart. New diagnostics still show CHN/CNY with USD product metadata. These manual account/restart actions are not independently attested by the app logs. The native Swift module reads Apple's displayPrice, price, and priceFormatStyle.currencyCode directly, without currency conversion or a USD fallback. We read Storefront.current before and after the product query, observe Storefront.updates, and invalidate saved quotes when the storefront changes. There is no local StoreKit configuration in the scoped app source we reviewed. Before we added a mismatch guard, the Apple confirmation sheet showed China prices while the app displayed USD. The guard now blocks purchase when currencies disagree; we have not completed a purchase test. I found a similar report at https://developer.apple.com/forums/thread/845478, but I do not know whether our case has the same cause. We have diagnostic screenshots, native-source excerpts and a sanitized regional-price audit. We also prepared a small SwiftUI Xcode sample that reads storefront and product metadata only. It has NOT been compiled or run: our current workspace is Windows and we do not have a Mac available. We have NOT reproduced this in a development-signed build. The code-level support form directed us here because we do not yet have a verified focused reproducer. Could Apple advise: Is there a supported way to obtain product metadata consistent with the CHN/CNY storefront in this TestFlight situation, or a recommended workaround/test configuration? Which logging profile and device diagnostics would help investigate FB25210596? Can the existing TestFlight diagnostics and unverified sample source help, or is a development-signed reproduction required before further technical support? We want to show prices consistent with Apple's confirmation sheet and complete a valid China-region sandbox test. We are not assuming a production release will fix this. Thank you.

Hi everyone, We have already migrated our app to StoreKit 2 for the latest release. However, we are currently planning our long-term strategy (such as implementing forced app updates) for when StoreKit 1 eventually stops working on legacy app versions. I’ve already checked several discussions here regarding the deprecation of the server-side /verifyReceipt endpoint and its potential impacts. Aside from backend validation, I’m particularly curious about the overall client-side StoreKit 1 framework timeline. While I understand that there is no official sunset date announced yet, it would cause significant issues and delays in handling our legacy apps if it were shut down without warning. I was wondering: Has anyone heard or seen any official guidance on how Apple typically handles full deprecations for core frameworks like this? Can we reasonably expect Apple to issue an official announcement (via Developer News, etc.) with a sufficient grace period before StoreKit 1 is fully retired? I'd love to hear your thoughts or if anyone has received any insights from Apple Developer Support regarding this. Thanks in advance!

I’m unable to retrieve a newly configured auto-renewable subscription from the Apple Sandbox environment. Product information Bundle ID: com.reynaga.Imoox Product ID: com.reynaga.Imoox.subscription.monthly Subscription status: Prepare for Submission Price: USD 1.99 per month Introductory offer: one-week free trial Result The app requests the product using StoreKit 2: let products = try await Product.products( for: ["com.reynaga.Imoox.subscription.monthly"] ) The request doesn’t throw an error, but the returned products array is empty. I also tested with SKProductsRequest. The Sandbox response is: Valid products: [] Invalid product identifiers: ["com.reynaga.Imoox.subscription.monthly"] Configuration already verified The Bundle ID and Product ID match App Store Connect exactly. The app uses an explicit App ID, not a wildcard. In-App Purchase is enabled for the App ID. The development certificate and provisioning profile are valid. There is no StoreKit Configuration file active in the Run scheme. The Apple Developer Program membership is active. The Paid Applications Agreement is active. Banking and all required tax forms show an Active status. The subscription has a price, localizations, tax category, and availability. Mexico and the United States are included in its availability. The Sandbox Apple Account belongs to the same developer team. The app is development-signed and installed from Xcode 26.2 on a physical iPhone. I signed out and back into the Sandbox account, deleted and reinstalled the app, restarted the device, and cleaned the Xcode build. The issue has persisted well beyond the documented metadata propagation period. Apple Developer Support reviewed the administrative configuration and referred me to the Developer Forums. According to Apple’s documentation, an In-App Purchase doesn’t require prior App Review approval to work in Sandbox. Could an Apple StoreKit or App Store Connect Commerce engineer verify whether the app-to-subscription catalog association is correctly provisioned in Sandbox and refresh or reprocess it if necessary?

StoreKit 2 Product.products(for:) returns an empty array (no error) for all 6 in-app purchases of my app in TestFlight. Setup: App: Apple ID 6816296214, bundle ID com.nh2s.eggmage-dungeon (first version 1.0, not released yet) IAPs: egg_gems_80, egg_gems_500, egg_gems_1200, egg_gems_2500, egg_starter_pack (consumable), egg_no_ads (non-consumable) Each IAP: status Ready for Review, price set (175 regions, base KRW), English and Korean localizations Business: Paid Apps Agreement Active, Free Apps Agreement Active, bank account Active, W-8BEN, U.S. Certificate of Foreign Status and Korea tax form all Active. The latest Program License Agreement and Paid Applications Schedule are accepted. Explicit App ID with In-App Purchase capability enabled TestFlight build 1.0 (2610141319), canMakePayments = true, storefront USA (143441) The agreements and tax forms became Active yesterday, and the products still don't load after many full app restarts. The app uses Unity IAP 5.4.3, which calls Product.products(for:) with the six IDs above. Is there anything else on the account or app side that could make the sandbox return no products? This looks like the same issue as https://developer.apple.com/forums/thread/849426 (first app, consumables, tax forms activated recently, empty product response). Thank you.

We've been approved for the Advanced Commerce API. After receiving the approval, we completed the initial setup requirements (submitted a generic product ID and shared our subscriptions page deep link). When testing the Migrate Subscription to Advanced Commerce endpoint in the sandbox, we receive a 5000000 error. What could be the reason/s for it? There is no information, and the API call we make includes all required parameters. Could it be related to the fact that our new generic product ID status is "Missing Metadata"? Is there a way to understand what the issue is on Apple's side?

Hello, We are contacting you regarding an issue we are currently experiencing during the App Review process related to In-App Purchases and StoreKit product retrieval. After extensive internal testing and investigation, we believe the behavior we are seeing is identical to the issue discussed in the following Apple Developer Forum thread: https://developer.apple.com/forums/thread/827016 Our application was rejected under Guideline 2.1 - Performance because the subscription plans reportedly failed to load during review. According to the review notes, the In-App Purchase product list appeared empty in the review environment, which prevented the paywall from loading correctly. We would like to provide additional technical context because, despite significant testing efforts on our side, we have been unable to reproduce this behavior outside of the App Review environment. The exact same binary that was reviewed by App Review has been thoroughly tested by us through TestFlight on multiple physical devices, including iPhone and iPad devices, using multiple Sandbox tester accounts and different network conditions. In all of our tests, the subscription system functions correctly and consistently. Specifically, we verified that: StoreKit successfully retrieves all configured subscription products RevenueCat offerings load correctly without timeout or empty states Localized pricing information is displayed properly Subscription packages appear correctly in the paywall UI Purchase flows complete successfully Restore purchases functionality works correctly Products are returned both on cold launch and repeated application launches The issue does not occur intermittently in TestFlight or Sandbox testing on our side We also carefully reviewed our App Store Connect configuration and verified the following items multiple times: All In-App Purchase subscriptions are attached to the submitted app version Product identifiers used in the application code exactly match the identifiers configured in App Store Connect All products are marked as “Cleared for Sale” Paid Applications Agreement has been accepted and remains active Tax and banking information are complete and active Subscription localization settings are configured properly Pricing information is active and visible The products are available in the storefronts being tested The submitted binary is identical to the binary tested successfully through TestFlight Additionally, we implemented defensive handling in the application to minimize the impact of temporary StoreKit failures. The application now includes: Retry logic for offerings retrieval Graceful fallback handling for empty offerings Protection against infinite loading states Additional RevenueCat and StoreKit logging UI fallbacks when products temporarily fail to load Despite these safeguards, the review feedback still indicates that the products are not being returned in the App Review environment. At this point, because the issue cannot be reproduced externally and only appears during App Review, we suspect there may be an intermittent or environment-specific issue affecting StoreKit product retrieval in the review sandbox environment. One important detail is that the exact same build consistently works in TestFlight immediately before and after submission. This makes the behavior particularly difficult for us to diagnose because there appears to be no configuration difference between our successful tests and the App Review scenario. We also understand from Apple documentation and previous App Review communication that In-App Purchases are tested within an Apple-provided sandbox environment. Based on the evidence currently available to us, the failure appears to occur specifically within that review sandbox process rather than within the application logic itself. If possible, we would greatly appreciate assistance with the following: Verifying whether StoreKit product retrieval is functioning correctly in the App Review sandbox environment Confirming whether the review device successfully established communication with App Store sandbox services Providing any available diagnostic logs related to the failed product request Confirming whether the product identifiers were visible to StoreKit during review Sharing any guidance on how we may reproduce the App Review behavior locally Clarifying whether there are known intermittent issues affecting StoreKit product loading during App Review We are fully committed to resolving the issue and ensuring complete compliance with App Store requirements. However, because the issue currently appears environment-specific and non-reproducible from our side, we are struggling to determine what additional changes are necessary. If there are any additional diagnostics, logging methods, StoreKit verification steps, or App Review recommendations you would like us to implement, we would be happy to do so immediately. Thank you very much for your assistance, support, and time. We sincerely appreciate your help in investigating this issue. Best regards, Mert Akgün