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?

Hello, We would appreciate some guidance regarding an unexpected StoreKit currency result in a TestFlight build. Our iPhone language and region are both set to France. The Sandbox tester is also configured for France, and our subscription products have French availability and pricing configured in App Store Connect. In the TestFlight build we diagnosed, StoreKit reports the current storefront as France with EUR: storefront=FRA/143442/EUR However, all 10 subscription products are returned with USD product metadata: products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE Example: formatCurrency=USD locale=fr_US_currency_USD localeCurrency=USD display=1,99 $US price=1.99 We first observed this through Flutter's in_app_purchase integration. To determine whether the Flutter plugin was involved, we added a native StoreKit 2 diagnostic to the same TestFlight build. The native result was identical: receipt=sandboxReceipt storefront before=FRA/143442/EUR storefront after=FRA/143442/EUR products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE The issue appears specific to the TestFlight distribution. When the application is installed directly from the development computer, prices are returned in euros on the same device. We also tested with the regular Media & Purchases account signed out and a French Sandbox tester connected. Once the products loaded successfully, StoreKit still returned USD metadata. In another configuration, the application displayed the USD price while Apple's purchase sheet displayed the price in euros. We are using the price and formatting information returned directly by StoreKit. We do not want to infer the currency from the device region or perform a client-side currency conversion, because StoreKit should remain the authoritative source. Could you please help us understand: Is it expected for Storefront.current to report FRA/EUR while Product.priceFormatStyle.currencyCode, its locale currency, and Product.displayPrice use USD? Could a TestFlight or App Store Connect configuration cause product metadata to use a different currency from the current storefront? Is there another account, availability, pricing or distribution setting that we should verify? Is there a recommended way to refresh or invalidate the product metadata used by a TestFlight installation? We have already filed Feedback Assistant report FB24723329, which is currently under investigation. Thank you very much for any clarification or additional diagnostic steps you can suggest.

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

I'm investigating a Restore Purchases failure in my app, PW Paycheck, which uses StoreKit 2. TestFlight purchases of consumable checks and an annual subscription have succeeded, but restoring purchases repeatedly fails. The failing call is: try await AppStore.sync() Apple displays an account password prompt. I enter my password and tap OK, after which the call throws. Our typed error classifier and NSError conversion report: StoreKitError.unknown StoreKit.StoreKitError: 2 This is the StoreKit.StoreKitError domain, not SKErrorDomain. We have not established whether authentication succeeded internally or what causes the failure. Environment: Physical iPhone 16 Pro; installed through TestFlight. App version 1.0 (20), bundle com.ggeller.pwpaycheck. In-app OS report: Version 26.6.2 (Build 23G90). Reported StoreKit price storefront: USA / 143491. Annual subscription: com.ggeller.pwpaycheck.pro.annual. Developed and uploaded using Swift Playgrounds on iPad. I have a Windows laptop and no Mac access. Steps: Open the TestFlight app with an existing unexpired annual test subscription. Open Payment Options and tap Restore Purchases. Enter the password in Apple's prompt and tap OK. AppStore.sync() throws the error above. The app then refreshes entitlements and displays a restore failure message. Observed results: Verified active subscription access is recognized before and after the failed operation. We do not count this as successful restoration. The subscription was canceled but still unexpired during the captured attempt. Build 19 produced the same NSError domain/code on Wi-Fi and cellular. Build 20 captured the typed .unknown classification on Wi-Fi. Our logger captured no additional underlying error. The latest attempt started at 2026-10-14T13:59:09Z and completed at 13:59:25Z, including the post-failure entitlement refresh. We are not treating this as evidence of a timeout. The restore action is user initiated, guarded against duplicate operations, and waits for an earlier entitlement refresh to finish before calling AppStore.sync(). What supported diagnostic or configuration check would help distinguish possible causes of this error, particularly without access to Xcode's device console? Also, how should we isolate a TestFlight-specific restore failure in a focused sample while preserving the relevant app/account context? A separate sample has been prepared, but compilation and reproduction are still pending.

Hello Apple Developer Community, I need technical assistance with a recurring StoreKit subscription issue affecting my iOS application, DRIVER BRAIN. Application details: App: DRIVER BRAIN Bundle ID: com.oney.driverbrain Subscription Product ID: com.oney.driverbrain.premium.monthly Subscription price: $9.99 USD per month Introductory offer: 3-day free trial Development framework: Flutter (iOS) Problem: During Apple's App Review, the subscription product is not being returned by StoreKit. The purchase screen displays the message: "Apple has not returned the subscription yet." As a result, App Review cannot complete the subscription purchase flow, and the application has been rejected under Guideline 2.1 – App Completeness. Checks already completed: Subscription Product ID verified. Bundle ID verified. In-App Purchase capability enabled. Three-day introductory trial configured in App Store Connect. Paid Apps Agreement active. Banking and tax information active. Subscription availability reviewed. Sandbox account configuration and physical iPhone testing performed. Despite these checks, Apple's reviewers continue to encounter the subscription loading problem. I would appreciate assistance from Apple's StoreKit engineers or experienced developers with the following questions: Why might an auto-renewable subscription product not be returned during App Review? How can I identify whether the issue originates in StoreKit product retrieval, App Store Connect configuration, or the review environment? Which StoreKit diagnostic logs or code excerpts would help identify the root cause? What is the recommended technical solution to ensure the subscription product loads reliably during App Review? I am looking for a definitive diagnosis rather than repeating configuration checks that have already been completed. Thank you for your assistance.

I'm investigating a price/currency mismatch in a TestFlight app. Environment: iPhone 15, iOS 26.6.2 App version 0.4.2 (Build 47), distributed through TestFlight Consumable product ID: line_stamp_8pack_1980 Diagnostic comparison: October 5, 2026, at 11:22:47 JST (UTC+09:00) For the same product, all three product lookup paths returned price 11.99, currency USD, and display price $11.99: StoreKit 1: SKProductsRequest / SKProduct StoreKit 2: Product.products(for:) expo-iap: fetchProducts The direct StoreKit calls were made through native Swift diagnostics in the app. All three lookups succeeded without errors. StoreKit 2 reported storefront country USA and ID 143462 before and after its lookup. expo-iap also reported USA before and after its lookup. StoreKit 1's storefront was unavailable before its request. Afterward, it reported USA, with storefront identifier "143462-9,29". Our diagnostic initially labeled this as a storefront change, but an unavailable-to-available result does not establish an actual country change. During the same testing session, Apple's purchase confirmation sheet for this product displayed ¥1,980 and stated that the purchase was for testing only. I canceled the sheet without completing the purchase. The Media & Purchases account's country/region is Japan. App Store Connect pricing for this product is ¥1,980 in Japan and $11.99 in the United States. What could cause the product lookup APIs to return the US storefront price while the purchase confirmation sheet displays the Japanese price? What additional diagnostics should I collect to identify the cause and obtain a product price consistent with the purchase sheet? Thank you.

Does changing the price of an already-approved In-App Purchase trigger a new App Review, or does the new price take effect without review? App Store Connect Help states that changes to localized information require review and that 'New pricing will go into effect immediately', but never says explicitly whether a price change alone is exempt from review. We need this for a non-renewing subscription sold in the Saudi Arabia storefront.

DTS recommended that we post this question in the Developer Forums. We would like clarification on the supported production behavior of originalTransactionId in the App Store Server API, particularly after a subscription expires and the customer resubscribes. Our main backend design question is: Can we continue using a stored originalTransactionId to identify and retrieve subsequent subscription activity within the same subscription group, or must we support discovering and associating new identifiers? Integration context Our backend uses: GET /inApps/v1/subscriptions/{transactionId} GET /inApps/v2/history/{transactionId} App and subscription details: Bundle ID: com.lgeha.nuts Subscription group identifier: 22350255 Product A: thinq_g_unlimitedpro Product B: thinq_g_single We use originalTransactionId as a key for subscription records and associate those records with user accounts in our service. We do not use it as an identifier for the Apple Account itself. Please assume the same Apple Account and app, with both products in the same subscription group, using ordinary auto-renewable subscriptions without a special subscription migration. This question concerns the identifiers and lookup behavior exposed to our backend by the App Store Server API. Sandbox observation and scope During sandbox testing, purchase history was cleared, and a new originalTransactionId was subsequently observed. We understand that this observation involved a sandbox history reset and does not establish production behavior. Our questions below concern production behavior without any purchase-history reset. Preservation across subscription lifecycle events For each scenario below, is originalTransactionId guaranteed to remain unchanged for subsequent transactions, or can Apple assign a different value? Automatic renewal of the same product. An upgrade, downgrade, or crossgrade between products A and B while the subscription is active. Turning off automatic renewal, then re-enabling it before expiration. Turning off automatic renewal, allowing the subscription to expire, and later resubscribing to the same product. Turning off automatic renewal for product A, allowing it to expire, and later subscribing to product B within the same subscription group. Scenarios 4 and 5 are our primary concern. We would like to distinguish commonly observed behavior from supported guarantees that a backend can rely on. Conditions for a new identifier after expiration For scenarios 4 and 5, can a new purchase legitimately receive a different originalTransactionId in production despite the Apple Account, app, and subscription group remaining unchanged? If so, what conditions determine this? Does it depend on: Time elapsed since expiration. Billing retry or billing grace-period status or history. Whether the purchase uses StoreKit 1 or StoreKit 2. Whether the customer resubscribes inside the app or through App Store subscription management. Our concern is whether these factors affect the identifiers subsequently returned by the App Store Server API. Stability of an existing transaction Separately from a new purchase receiving a new identifier, if the same transactionId is retrieved at two different times, is its associated originalTransactionId guaranteed to remain unchanged? Can an Apple-supported correction process change that association, or should such a result be treated as an inconsistency and reported through Feedback Assistant? This question concerns the same returned transactionId, rather than a different latest transaction returned by a subsequent status query. We have not confirmed such a change in production. Lookup behavior using a previously stored identifier If resubscription can create a new originalTransactionId, how does that affect each endpoint? For GET /inApps/v1/subscriptions/{transactionId}: Can a request using the previous originalTransactionId return the current status of a later resubscription with a different originalTransactionId, assuming the same Apple Account, app, and subscription group? Or must the backend obtain the new identifier separately? For GET /inApps/v2/history/{transactionId}: Can a request using the previous originalTransactionId return transactions from that later resubscription, assuming all applicable pages are retrieved and no filters exclude those transactions? Please clarify any endpoint-specific guarantees or limitations on using an older identifier to discover subsequent subscription activity. Backend account association If resubscription can create a new identifier, should our backend support multiple originalTransactionId values for one service user within the same subscription group? Is there a documented server-side relationship that links subscriptions with different originalTransactionId values? Alternatively, should that association rely on an application-managed identifier such as appAccountToken, where available? Please clarify any limitations, especially for resubscriptions initiated outside the app. Related discussions We reviewed these discussions as background: Transaction ID Misassociation in IAP Subscription API (https://developer.apple.com/forums/thread/777433) original_transaction_id associated to web_order_line_item_id of auto-renewable subscription changed (https://developer.apple.com/forums/thread/778301) We do not assume that these reports establish supported behavior or share the cause of our sandbox observation. Could Apple clarify the supported preservation or replacement rules, particularly after expiration and resubscription, and point us to documentation describing the behavior a backend can rely on? If investigating a specific inconsistency requires a separate Feedback Assistant report, please indicate which server-side request and response details should be included. Thank you.