Hi, Overview I have an app for which I have created a sandbox account. When I try to clear purchase history it doesn't work, it still shows the in-app purchase items (non-consumable in-app purchases) as purchased. I have tied tried the following ways, but none of them work. Any help on this would be much appreciated! Attempt 1: Go to https://appstoreconnect.apple.com/ Users and Access > Sandbox Check sandbox account > Tap Clear Purchase History button Attempt 2: Go to the iPhone > Settings > Developer > Sandbox Apple Account Tap on account > Manage > Clear Purchase History Attempt 3: Sign out of Sandbox account and sign back in Attempt 4: Delete app and re-run app from Xcode

Hello, I am investigating an intermittent In-App Purchase failure that occurred during App Review for the first release of my app. Environment Review device: iPad Air 11-inch (M3) OS: iPadOS 26.6 Environment: App Review sandbox Product type: Consumable StoreKit integration: RevenueCat through react-native-purchases 10.4.3 Observed behavior StoreKit successfully returned the products, localized names, and prices. The reviewer could see the credit packs and initiate the native purchase flow. My diagnostics show this sequence: Purchase initiated PURCHASE_CANCELLED; no transaction evidence Purchase initiated again RevenueCat code 2: STORE_PROBLEM elapsed: 9.4 seconds no transaction evidence Purchase initiated again RevenueCat code 5: PRODUCT_NOT_AVAILABLE_FOR_PURCHASE no transaction evidence Purchase initiated again RevenueCat code 5: PRODUCT_NOT_AVAILABLE_FOR_PURCHASE elapsed: 0.6 seconds no transaction evidence code-block The relevant sanitized logs are: { "occurredAt": "2026-08-25T12:52:59.733Z", "platform": "ios", "appVersion": "1.0.0", "build": "14", "productId": "HIDDEN_FOR_DISPLAY", "stage": "STORE_CHECKOUT", "providerCode": "2", "providerReadableCode": "STORE_PROBLEM", "transactionEvidence": false, "elapsedMs": 9417 } code-block { "occurredAt": "2026-08-25T12:55:42.752Z", "platform": "ios", "appVersion": "1.0.0", "build": "14", "productId": "HIDDEN_FOR_DISPLAY", "stage": "STORE_CHECKOUT", "providerCode": "5", "providerReadableCode": "PRODUCT_NOT_AVAILABLE_FOR_PURCHASE", "transactionEvidence": false, "elapsedMs": 637 } code-block No App Store transaction was created, and therefore RevenueCat received no transaction or webhook for these attempts. Configuration verified I confirmed that: The affected product and the other consumable products are attached to the App Review submission. Product IDs match between the app, App Store Connect, and RevenueCat. Prices and localizations are configured. The products are available in the relevant storefronts. The Paid Apps Agreement is active. Banking and tax information are active. The In-App Purchase capability is present. The distribution build does not use a local StoreKit configuration file. The same build and affected product completed successfully afterward on a physical device using Apple Sandbox. The native purchase sheet opened, the transaction completed, and the consumable content was delivered successfully in my reproduction. The product metadata clearly remained available because its localized name and price were displayed. However, after the initial STORE_PROBLEM, subsequent purchase requests were rejected almost immediately as PRODUCT_NOT_AVAILABLE_FOR_PURCHASE. I do not have the underlying Apple NSError, such as an ASDServerErrorDomain or AMSErrorDomain value, because it was not exposed in my remote diagnostic record. Questions Can a failed sandbox transaction leave the StoreKit account/session or commerce-catalog state temporarily inconsistent, causing subsequent requests for an otherwise loaded product to return storeProductNotAvailable? Does StoreKit use separate metadata and transaction-eligibility services, allowing product information to load while the same product is rejected during purchase()? Are there known sandbox or StoreKit issues on iPadOS 26.6 that could produce this sequence? Could a stale App Review sandbox account token or storefront session explain the transition from STORE_PROBLEM to PRODUCT_NOT_AVAILABLE_FOR_PURCHASE? Is there any developer-side configuration that could explain this when the same product and binary complete successfully using another sandbox session? What additional logging should I capture from RevenueCat’s React Native SDK to preserve the complete underlying Apple error chain?

I'm testing iAP in a sandbox account (as configured in App Store Connect under 'Sandbox Testers'). So the in app purchase works. Cool. But I wanted to retry it. So I cleared the purchase history (both in App Store Connect and on my iPad in the 'Developer' section in Settings). But when I relaunch my app the purchase still validates and my app displays the item as 'unlocked'. Figure the receipt must still be cached so I nuke the app and completely reinstall it but it appears StoreKit is still getting the receipt and it isn't being cleared because my app is displaying it as 'purchased.' Also tried rebooting the iPad. But the sandbox purchase doesn't clear. I just did a sandbox test since it is closer to real life than StoreKit Configuration so I just wanted to do it a few times to make sure all is good but making a burner test account for every purchase is kind of tiresome. Anyone know of a workaround? I might just declare victory and go back to StoreKit Configuration.

We are implementing in-app purchases using StoreKit 2. The issue we need guidance on is how our app should correctly handle a StoreKit 2 transaction that becomes .unverified during Apple App Review. In our local development testing, purchases work correctly. When we test the same IAP products locally, the transaction returned from Product.purchase() is .verified, and the purchase flow completes successfully. However, during Apple App Review, the reviewer appears to encounter a failure where the StoreKit 2 transaction is returned as .unverified on the client side. The original localized error message shown is in Traditional Chinese: 「資訊對裝置無效」 Our English translation of this message is: “The information is not valid for this device.” Because the message is localized, we are not sure what the exact original English StoreKit error string would be. This failure happens in the client app before our backend receipt or server-side validation flow. We are not using verifyReceipt for this step. The failure occurs at the StoreKit 2 VerificationResult level when checking the transaction returned by StoreKit. Our current implementation only accepts .verified transactions. If StoreKit 2 returns .unverified, we treat the transaction as failed and do not unlock the purchased content. We believe this is the recommended secure behavior, but we would like to confirm the correct handling, especially because this issue is appearing during App Review while our local development purchases succeed. Additional context: • Distribution/review context: App Review / IAP review • API: StoreKit 2 • Failure point: VerificationResult returned as .unverified • Localized error message: 「資訊對裝置無效」 • Rough English translation: “The information is not valid for this device.” • Local development testing: purchases return .verified and succeed • The issue occurs before backend validation • Our app currently rejects .unverified transactions and does not unlock content Questions: What are the known causes of StoreKit 2 returning .unverified with the localized error message 「資訊對裝置無效」 during App Review? Is our current behavior correct: only unlock content for .verified transactions and reject .unverified transactions? If App Review receives .unverified, what should the app do from Apple’s recommended perspective? Should we show a retry/error message, ask the reviewer to retry, refresh entitlements, or take another action? Is there any App Review environment, device configuration, Apple ID configuration, or StoreKit account state that can cause this device-related verification error? Since local development purchases succeed but App Review fails, what diagnostics or logs should we collect and provide to identify the root cause? Should we ever bypass StoreKit 2 transaction verification in App Review/TestFlight, or should .unverified always be treated as a failed transaction? We would appreciate guidance on the correct code-level handling so that our app remains secure while also passing App Review reliably. Thank you.

purchaseDate=1787743932000, originalPurchaseDate=1785065532000, expiresDate=1788348732000, quantity=1, type=<Type.AUTO_RENEWABLE_SUBSCRIPTION: 'Auto-Renewable Subscription'>, rawType='Auto-Renewable Subscription', inAppOwnershipType=<InAppOwnershipType.PURCHASED: 'PURCHASED'>, rawInAppOwnershipType='PURCHASED', signedDate=1787715151907, revocationReason=None, rawRevocationReason=None, revocationDate=None, isUpgraded=None, offerType=None, rawOfferType=None, offerIdentifier=None, environment=<Environment.PRODUCTION: 'Production'>, rawEnvironment='Production', storefront='USA', storefrontId='143441', transactionReason=<TransactionReason.RENEWAL: 'RENEWAL'>, rawTransactionReason='RENEWAL', currency='USD', price=7990, offerDiscountType=None, rawOfferDiscountType=None, offerPeriod=None) This is a piece of decode notification, you can see that the purchaseDate and signedDate ​​differ by approximately 8 hours. I can confirm that all the DID_RENEW notifications have this difference. purchaseDate=1787715089000, originalPurchaseDate=1787715089000, expiresDate=1787974289000, quantity=1, type=<Type.AUTO_RENEWABLE_SUBSCRIPTION: 'Auto-Renewable Subscription'>, rawType='Auto-Renewable Subscription', inAppOwnershipType=<InAppOwnershipType.PURCHASED: 'PURCHASED'>, rawInAppOwnershipType='PURCHASED', signedDate=1787715089920, revocationReason=None, rawRevocationReason=None, revocationDate=None, isUpgraded=None, offerType=<OfferType.INTRODUCTORY_OFFER: 1>, rawOfferType=1, offerIdentifier=None, environment=<Environment.PRODUCTION: 'Production'>, rawEnvironment='Production', storefront='IDN', storefrontId='143476', transactionReason=<TransactionReason.PURCHASE: 'PURCHASE'>, rawTransactionReason='PURCHASE', currency='IDR', price=0, offerDiscountType=<OfferDiscountType.FREE_TRIAL: 'FREE_TRIAL'>, rawOfferDiscountType='FREE_TRIAL', offerPeriod='P3D' and this is a SUBSCRIBED/INITIAL_BUY notification, it has right purchaseDate.

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?

I've been struggling to work with the Storekit framework and specifically to find the current Storefront used by the user of the app. Context : My app needs to behave differently depending on the country of the user. For me relying on Locale.current.region?.identifier does not seem very reliable, the user can change it really easily. I'm trying to use the Storekit framework like so : if let storefront = await StoreKit.Storefront.current{ return storefront.countryCode } As per Apple's Storekit documentation : Use current to determine a customer's current storefront region and offer in-app products suitable for that region. You maintain your own list of product identifiers and the storefronts in which you make them available. But I just can't find out what I need to change in my current configuration to get another country. The code keeps returning my original storefront (which is France) I've tried login in with a sandbox user defined on another country. Changed all settings on my device to another country. Changed my Apple's account region as described here. Also tried to logout from everything. The only thing that works is setting a local .storekit file as described here and changing the default storefront. Is Xcode overriding the default storefront when building on debug or TestFlight? does anyone know how can I test different storefronts with sandbox users without the local storekit file ? Thank you in advance.

I’m encountering an incorrect App Store storefront on one iOS device when testing an in-app purchase through TestFlight. Environment: App: ClawApp TestFlight build: 1.0.9 (08251556) Product ID: com.chagent.claw.credits.advanced StoreKit 2 Sandbox Apple Account country/region: Mainland China Device A: works correctly and returns CNY Device B: always returns USA/USD The same Sandbox Apple Account and the same TestFlight build are used on both devices On the affected device, StoreKit returns: storefrontCountryCode=USA storefrontCurrency=USD storeKitCurrency=USD storeKitDisplayPrice=US$9.99 The server catalog returns: serverSaleAmount=79.00 serverSaleCurrency=CNY I have already tried the following on the affected device: Signed out and signed back in to the Sandbox Apple Account Used another Mainland China Sandbox Apple Account Signed out of Media & Purchases Restarted the device Deleted and reinstalled the TestFlight app Cleared Sandbox purchase history However, Storefront.current still returns USA/USD. The same account and app return the expected China storefront on another device. This seems to be device- or iOS-version-specific. Could this be a known StoreKit/TestFlight storefront synchronization issue? What additional logs or sysdiagnose information should I provide?

I have filed Feedback Assistant report FB24182480 for this issue. On an Apple Watch Series 6 running watchOS 26.6 (23U67), a TestFlight watchOS app can successfully load a non-consumable StoreKit 2 product from Sandbox and display its localized price. However, a subsequent single call to product.purchase() can fail before, or while, the system confirmation sheet is displayed. The app itself remains alive. It receives StoreKit.StoreKitError.systemError (code 1), with an underlying NSCocoaErrorDomain error 4097, consistent with losing the XPC connection to storekitd. The affected run’s private co-sysdiagnose shows this sequence: storekitd starts processing the payment. The Sandbox purchase request returns HTTP 200. AMSPaymentSheetTask begins. The kernel reports that storekitd exceeded its ActiveSoft 5 MB limit and terminates it as the high-water process. The app receives Cocoa error 4097. A later user-initiated retry was handled by a restarted storekitd process and ended with the same result. There are no overlapping product, entitlement, or purchase operations, and the app does not automatically retry purchase(). The issue is intermittent: in other runs on the same Watch, the Sandbox purchase sheet has appeared successfully. This makes it appear to be a system purchase-service lifecycle or memory-management issue rather than a product-configuration or product-loading issue. Environment: Apple Watch Series 6 (Watch6,4) watchOS 26.6 (23U67) TestFlight build StoreKit 2 Sandbox non-consumable IAP One explicit Buy tap per attempt Has anyone seen storekitd being terminated with a high-water reason during a watchOS purchase flow, or found a supported app-side mitigation for the resulting StoreKit error 1 / Cocoa 4097? I have kept the sysdiagnose and recordings private in Feedback Assistant because they contain account, device, and network information.

Does anyone have info about the Retention Messaging API. We've requested access to it, but there's no answer.

StoreKit 2 returns zero subscription products in Sandbox/TestFlight — FB24199369 I’m experiencing an issue where StoreKit 2 returns zero subscription products in both Sandbox and TestFlight for my iOS app. App: Bundle ID: com.sleeplessnight.naengbiseo Subscription group: Naengbiseo Premium Product IDs: naengbiseo_premium_monthly naengbiseo_premium_yearly Although the production app uses RevenueCat, I reproduced the same issue in a separate minimal native SwiftUI app using StoreKit 2 directly, with no RevenueCat, Expo, React Native, or other third-party SDK involved. Native StoreKit 2 call: let products = try await Product.products(for: [ "naengbiseo_premium_monthly", "naengbiseo_premium_yearly" ]) Current native test result: STOREKIT_COUNTRY_CODE: KOR STOREKIT_STOREFRONT_ID: 143466 DIRECT_STOREKIT_COUNT: 0 Returned products: None Test environment: Physical iPhone StoreKit Configuration: None Sandbox Apple Account signed in Storefront: KOR In-App Purchase capability enabled Correct Bundle ID and Product IDs I have rechecked the following configuration: The subscriptions are available in the test storefront Subscription pricing is configured Subscription localization is configured Paid Apps Agreement, banking, and tax information are active App ID has In-App Purchase enabled The App Store/TestFlight build has the expected Bundle ID, provisioning, and signing configuration I also created a StoreKit Configuration file using “Sync this file with an app in App Store Connect”. The sync completed, but the resulting configuration contained: products: [] subscriptionGroups: [] The same subscriptions also fail to load in TestFlight. The subscription products currently show Rejected in App Store Connect because the associated app version was rejected. App Store Connect states that the subscriptions were returned because the associated app was rejected and will remain Rejected until resubmitted for review. However, App Review also stated: “In-App Purchase products do not need prior approval to function in review.” I have reviewed TN3186 and have not found a remaining developer-side configuration issue that explains why Product.products(for:) returns zero products. Since the issue reproduces in a minimal native StoreKit 2 app, this does not appear to be caused by RevenueCat or another third-party SDK. Feedback Assistant: FB24199369 Could an App Store Commerce / StoreKit engineer advise whether there is any remaining developer-side configuration that could cause this, or whether the subscription catalog / app association may need to be reprocessed on Apple’s side? Thank you.

Hello, I am currently implementing External Purchase Link and External Purchase Custom Link and am encountering an issue where both ExternalPurchaseLink.canOpen and ExternalPurchaseCustomLink.isEligible always return false under all test conditions. I would like to confirm whether my setup is missing any required steps or whether this behavior is expected. Below are the details of my current environment and configuration: 🔧 1. Development Environment Xcode: 16.3, 16.4, 26.0 beta 4 Devices: iPhone running iOS 26.2 beta iPhone running iOS 16.7.12 macOS 15.5 (real device testing) Simulator iOS 18.0 Build Type: Local development build using a Developer Provisioning Profile Sandbox account signed in during testing 🔑 2. Entitlements (Developer site & Xcode) In Certificates → Identifiers → App ID, both capabilities are enabled: StoreKit External Purchase StoreKit External Purchase Link The .entitlements file in Xcode includes: com.apple.developer.storekit.external-purchase = YES com.apple.developer.storekit.external-purchase-link = YES The Provisioning Profile also contains both entitlements (confirmed via codesign -d --entitlements :-). 📄 3. Info.plist Configuration Both keys are configured with correct region codes according to documentation: SKExternalPurchase SKExternalPurchaseCustomLinkRegions 🌍 4. Test Storefront Device storefront verified as United States (US) or Portugal (PT) (US = target region for External Purchase Link, PT = EU region) But despite all the above configuration, both API calls consistently return false: ExternalPurchaseLink.canOpen // false ExternalPurchaseCustomLink.isEligible // false So I cannot proceed to testing the remaining flow (token retrieval, link opening, etc.) ------ Questions ------ ❓ Q1) Local Development Build Limitation Is it expected behavior that Developer-signed local builds always return canOpen = false / isEligible = false for External Purchase Link & Custom Link? Is there a technical or policy restriction that prevents eligibility in local dev builds? ❓ Q2) App Store Connect Configuration Requirement Are there mandatory App Store Connect settings (such as external purchase URLs, support URL, disclosures, or country configuration) that must be enabled before eligibility becomes true? Currently, no External Purchase Link or Custom Link menu is visible in my App Store Connect app settings. Is this menu only available after certain approvals or under specific conditions? ❓ Q3) TestFlight Requirement Do External Purchase Link and Custom Link only return eligibility = true on: TestFlight builds, or Distribution-signed builds? Or should eligibility also work on developer builds? Formal confirmation would be helpful. ❓ Q4) Developer Account Type Limitation We are using an Individual Developer Account (not Organization). Can Individual accounts fully request, test, and ship apps using: External Purchase Link External Purchase Custom Link Or are there limitations on account type? 🙏 Request We have completed all documented setup steps (Entitlements → Provisioning → Info.plist), but eligibility remains false, blocking feature validation. Please clarify which of the following is the cause: Local development builds do not support eligibility Missing App Store Connect configuration (not visible to us) Account type restriction Region rollout or entitlement approval requirement Any additional setup not documented publicly Thank you for your assistance.

App: com.playatrium.mobile Issue: StoreKit 2's Product.products(for:) returns USD pricing regardless of account region on TestFlight builds. Account/device confirmed UK at every layer I can check: App Store Connect developer account region: UK Personal Apple ID Media & Purchases country/region: UK Device region: UK No .storekit configuration file present in the project In-App Purchase capability confirmed enabled on the App ID The native purchase sheet, for the SAME product in the SAME app session, correctly resolves and displays GBP, and purchases complete successfully with correct entitlement grants on our server. So the purchase flow itself resolves the storefront correctly — only the catalog/pricing query does not. Console.app shows the account object with storefront = (null) at the moment of the catalog query: account = <ACAccount: ... storefront = (null)> and the resulting request falls back to /catalog/us/ with locale es-MX, rather than the correct territory. I've seen a few threads here with similar symptoms (products returning empty or wrong-region data on TestFlight specifically, working fine via local StoreKit config in the simulator) but haven't found a clear explanation or fix. Anyone know why Storefront.current / the catalog query would fail to resolve correctly on TestFlight while Product.purchase() resolves fine in the same session?

I am experiencing a StoreKit issue on iOS 27 Beta with eFootball™ 11.0.0 (jp.konami.pesactionmobile). After an in-app purchase, the app becomes stuck on an infinite loading screen during login. If I manage to log in, the in-game Shop also remains stuck loading. I investigated the issue using macOS Console and found that StoreKit repeatedly attempts to finish the same production transaction every approximately 2–3 seconds. The relevant logs are: Starting request FinishTransactionRequest(...) Failed to encode request parameters NSCocoaErrorDomain Code=3840 Error finishing transaction: StoreKitServiceError StoreKitInternalError.requestEncodeFailed The same transaction is repeatedly passed to FinishTransactionRequest, but the finish operation never succeeds. What I have confirmed The purchase itself was confirmed by Apple Support as successfully completed. The transaction is a Production transaction with the JPN storefront. Reinstalling eFootball does not resolve the issue. Restarting the iPhone does not resolve the issue. Signing out and back into "Media & Purchases" with the affected Apple Account does not resolve the issue. Network requests from the app itself are succeeding with HTTP 200 responses. The issue occurs when StoreKit attempts to finish the transaction. Most importantly, if I sign out of the affected Apple Account under Media & Purchases and sign in with a different Apple Account on the same iPhone, eFootball immediately works normally again — both login and the Shop load successfully. If I switch back to the original Apple Account, the issue returns. Steps to reproduce Use the affected Apple Account for Media & Purchases. Launch eFootball. Attempt to log in. The app remains stuck loading. Observe Console logs from storekitd. The same transaction repeatedly triggers FinishTransactionRequest. Each attempt fails with StoreKitInternalError.requestEncodeFailed. Expected behavior StoreKit should successfully finish the completed transaction, remove it from the unfinished transaction queue, and allow the app to continue normally. Actual behavior FinishTransactionRequest repeatedly fails with requestEncodeFailed, causing the same transaction to be processed indefinitely and preventing normal use of the app. Has anyone encountered the same behavior on iOS 27 Beta? Is this a known StoreKit issue, or is there any way to safely clear/finish the affected production transaction without restoring the device to the current public iOS release?

We have an auto-renewable subscription in our app that we want to stop offering. However, we want to make sure that people who have already purchased the subscription remain subscribed until the end of their current subscription period (and are subsequently unsubscribed and not charged further). What is the right way to do this?We tried submitting the app with the subscription still enabled in App Store Connect but hidden in the app, and our update was rejected because the reviewer couldn't find a way to subscribe.Thanks,Frank

Transaction.finish() doesn't clear a transaction on iOS 27 beta 5 — worked correctly through beta 4 — every repeat purchase after the first replays the same transaction with no confirmation sheet and no charge. StoreKit.Transaction.finish() does not clear a transaction on iOS 27 beta 5. The transaction remains in Transaction.unfinished indefinitely, and every subsequent Product.purchase() call for that product returns the same stale transaction instead of starting a new purchase — with no confirmation sheet, no charge, and no way for the app to tell it apart from a genuine purchase. Because the replayed result is .success carrying a VerificationResult that verifies normally, an app has no supported signal that nothing was bought. The only distinguishing traits are that the id and purchaseDate are unchanged and the call returns in ~10ms instead of making a server round-trip. Consequence: a consumable product can be purchased exactly once per device. Every later attempt silently no-ops while appearing to succeed. Steps to Reproduce On a device running iOS 27 beta 5, sign in to a newly created Sandbox Apple Account (Settings → Apps → App Store → Sandbox Account) with no prior purchase history. Install and launch a development build of an app offering a consumable IAP. Confirm Transaction.unfinished is empty. Purchase the consumable. The confirmation sheet appears and the purchase completes normally. await transaction.finish() on the returned transaction. Enumerate Transaction.unfinished again. Purchase the same consumable a second time. Expected Results Step 6: Transaction.unfinished is empty — the transaction was finished. Step 7: a confirmation sheet appears and a new transaction is created, with a new id and a current purchaseDate. Actual Results Step 6: the just-finished transaction is still listed in Transaction.unfinished. Step 7: no confirmation sheet appears. purchase() returns .success in ~0.01s carrying the same transaction — identical id and identical purchaseDate — and nothing is charged. This repeats indefinitely. Re-fetching the transaction from Transaction.unfinished and calling finish() on that instance does not clear it either, so there is no app-side way to drain the queue. Diagnostic Log Virgin sandbox account, empty queue, three consecutive taps on one product: unfinished before tip.small: [] purchase() returned after 18.10s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 --- await transaction.finish() --- unfinished after finishing 2000001221113013: [small#2000001221113013] unfinished before tip.small: [small#2000001221113013] purchase() returned after 0.01s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 unfinished before tip.small: [small#2000001221113013] purchase() returned after 0.01s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 The first call is a genuine purchase (18s round-trip, sheet shown). The transaction survives its own finish(). Calls two and three are replays of it. Notes Not reproducible against a local .storekit configuration in the Simulator, which always presents the confirmation sheet. Requires Apple's sandbox. Also reproduces on a TestFlight build billed to a real Apple ID, where it is worse: TestFlight purchase history cannot be reset, so the affected products stay permanently stuck for that account. It survives deleting and reinstalling the app, and a device reboot. Possibly the same underlying issue as the unanswered report at https://developer.apple.com/forums/thread/808648 (iOS 26/18, Nov 2025). Configuration Device: iPhone 16 Pro Max OS: iOS 27 beta 5 Products: consumable in-app purchases API: StoreKit 2 (Product.purchase(), Transaction.finish(), Transaction.unfinished)

M y app was approved and is now live on the App Store, but all four auto-renewable subscriptions are still Waiting for Review in App Store Connect. Because of this, the production app's StoreKit 2 call to Product.products(for:) returns 0 products, and users see: "No subscription products were returned by the App Store." There are no metadata errors or warnings—only Waiting for Review. My questions are: Is it normal for an app to be released before its subscriptions are approved? While subscriptions are in Waiting for Review, is it expected that Product.products(for:) returns an empty array? Has anyone experienced this, and how long did it take for the subscriptions to be approved after the app was already live? I've attached: App Store Connect screenshot showing all four subscriptions in Waiting for Review. App screenshot showing the "No subscription products were returned by the App Store." message. Any insight would be greatly appreciated. Thanks!

Hi everyone, I'm developing a digital retail application which acts as a digital storefront/marketplace where users can purchase standard prepaid gift cards and entertainment store credits (such as PlayStation, Xbox, and Steam gift cards). To give you a clearer picture of how our app and payment system work: The app allows users to browse a catalog of prepaid gift cards and vouchers. When a user decides to purchase an item, they complete the transaction within the app using localized/third-party payment gateways (such as regional digital wallets and online payment providers). Upon successful payment, the app securely fulfills the order by displaying the purchased prepaid code or voucher, which is meant to be redeemed externally on the respective platform's website or app. However, Apple's App Review team keeps rejecting the app under Guideline 3.1.1 (In-App Purchase), stating: "The app allows users to purchase or sell digital items, codes, or currencies to be used in other apps or third-party platforms." We are not selling software licenses or unlocking features inside iOS apps; we are simply selling standard prepaid gift cards through external/local payment methods, similar to traditional physical retail cards. Has anyone faced a similar rejection while using external/regional payment gateways for a gift card or e-commerce app? How did you structure your app metadata, app description, or appeal to satisfy Guideline 3.1.1 without entirely removing the checkout flow? Any insights or advice would be greatly appreciated. Thanks!

I'm seeing IAPError(code: storekit_no_response, source: app_store, message: "StoreKit: Failed to get response from platform.") when calling queryProductDetails() (via Flutter's in_app_purchase/in_app_purchase_storekit plugin) for all 6 of my app's In-App Purchase products. This happens consistently on a real device (iOS 18.7.9), including after a full device restart. I've followed the entire TN3186 checklist: Paid Apps Agreement: Active Banking: Active Tax Forms: Active Bundle ID matches App Store Connect and Certificates/Identifiers/Profiles In-App Purchase capability is enabled on the App ID All 6 product identifiers match exactly and are attached to the app version under review Pricing is set for all territories on all products None of this resolves the error. This also caused an App Store review rejection citing "In-app purchase products... could not be found in the submitted binary" for the same reason. Bundle ID: com.playadda.playadda Product IDs affected: gems_pack_100, gems_pack_500, gems_pack_1200, premium_monthly, battle_pass_s1, starter_pack Has anyone found a resolution to this specific error beyond the standard TN3186 checklist?

Hi, I have deployed my app on Test Flight, I have two subscriptions, monthly and yearly. User can have one of them at a time and upgrade, downgrade to the other. Upgrade, downgrade, cancel from the Apple Settings worked fine in the sandbox environment when testing locally. Now when I have deployed the app on TestFlight, I was able to purchase the subscription successfully from my app. Now when I want to cancel my subscription from the Apple Settings it gives me the following error after confirming cancellation, 'Your request is temporarily unable to be processed. Please try again later.' Also the other subscription offer (yearly) is also not shown to which I could upgrade, even though in the sandbox I was able to upgrade downgrade from the settings. Another thing I have noticed is that the app Icon or name is not shown anywhere in settings with the subscription. Instead of app icon only empty square is shown. Even though app icon shows fine everywhere else. Can someone please help me figure out this issue?