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 a developer based in Somalia and I have recently enrolled in the Apple Developer Program. I am planning to build an iOS app exclusively for users in Somalia. The app will offer premium digital features, and I would like to use WaafiPay, a local Somali payment provider that supports mobile-money payments such as EVC Plus, ZAAD and SAHAL. Somalia does not have an Apple App Store storefront or Apple In-App Purchase availability. Before I start development, I would like to confirm whether an app distributed to users in Somalia can use WaafiPay to process payments for premium digital features directly inside the app. If this is permitted, please let me know whether I need any special entitlement, approval, or implementation requirements. Thank you.

We have a multiplatform SaaS app (iOS, Desktop). Individual plans are sold via IAP on iOS. We also offer a B2B multi-seat plan that's only sold through our website (per-seat billing, admin provisioning, etc.). On our iOS pricing page, we want to show all plans — including the B2B one — so users can see the full picture. The B2B plan would just show features and a starting price with a label like "Managed through our desktop platform." No purchase button, no link, no redirect. Only the individual plans would have IAP subscribe buttons. Three questions: Does showing pricing/features for a plan that can't be purchased in-app count as "steering" under 3.1.3? Is a static label like "Managed through our desktop platform" considered a call to action if there's no link or button? Would a "Contact Sales" form (just collects an email, follow-up happens outside the app) be a safer approach? We did check with Apple Developer Support (Aug 2026) and were told this should be fine, but want to hear from anyone who's shipped something similar before we submit. Thanks.

I'm trying to submit my app's first-ever subscriptions for review, and I'm stuck in a loop between two different App Store Connect submission flows that seem to conflict with each other. Setup: App: HeyFlat (bundle au.com.heyflat) Subscription group "HeyFlat Casa" with 3 auto-renewable subscriptions (monthly/semiannual/annual), all status "Ready to Submit" App version 1.0 has been rejected multiple times (most recently for Guideline 2.1(b) — "In-App Purchase products have not been submitted for review") What I've tried: On the Subscriptions page, I click "Add for Review" on the subscription group → it opens a "Draft Submission" panel (breadcrumb "Submissions") listing the group as an item ready to submit. That panel shows: "Unable to submit for review — Add an app version for the selected platform." I uploaded a brand-new, never-before-submitted build (build 31, version 1.0) via CI and manually attached it to the App Store version page (Distribution → App Store Version 1.0 → Build). Went back to the Draft Submission — same error persists, plus a new one: "New subscription groups must be submitted with an auto-renewing subscription from that group." The item listed is just the subscription group itself, not the individual subscriptions. Separately, the legacy per-version thread (App Review → iOS Submission) now shows build 31 as "Ready for Review" — but that thread only lists 1 item (the app version itself), no subscriptions attached, even though they're marked "Added for Review." So I have: a subscription group with 3 ready subscriptions, and a fresh unreleased build attached to the app version — but no path in the UI actually lets me submit them together. This exact same "In-App Purchases not submitted" rejection has now happened twice, with the subscriptions in this same "ready" state both times. Has anyone run into this specific mismatch between the "Submissions" draft flow and the legacy per-version "App Review" thread? What's the correct way to get a first-time subscription group submitted alongside an app version right now?

My first app submission has been in "In Review" since August 19, 2026 at 08:56 (CEST) — 9 days now, with no status change and no message of any kind. Details: Apple ID: 6799895164 Version: 1.0 (build [1]) Submission ID: 412ca140-f582-42a5-9714-e50a254e260b Platform: iOS Submitted: August 18, 2026 In Review: August 19, 2026 at 08:56 (CEST) The submission contains 1 app version and 3 in-app purchases: 2 auto-renewable subscriptions and 1 non-consumable lifetime unlock. All items show as included in the submission. Everything on my side appears complete: review screenshots for each IAP, price schedules, localizations, privacy policy URL, EULA, age rating declaration. Restore Purchases is implemented and visible on the paywall. Account status: Paid Applications Agreement: [Active] Digital Services Act trader status: [Verified] MRDP compliance: [Active] Bank and tax details: [Active] There is no rejection, no request for additional information, and nothing in Resolution Center. A support case is open as well. I have seen several recent threads describing the same pattern — in some cases requiring someone at Apple to move the IAP status forward on the backend. Could someone from App Review please check whether this submission is progressing normally, or whether something on my side is blocking it? Happy to provide any further details. Thanks in advance.

We have a multiplatform SaaS app (iOS, Desktop). Individual plans are sold via IAP on iOS. We also offer a B2B multi-seat plan that's only sold through our website (per-seat billing, admin provisioning, etc.). On our iOS pricing page, we want to show all plans — including the B2B one — so users can see the full picture. The B2B plan would just show features and a starting price with a label like "Managed through our desktop platform." No purchase button, no link, no redirect. Only the individual plans would have IAP subscribe buttons. Three questions: Does showing pricing/features for a plan that can't be purchased in-app count as "steering" under 3.1.3? Is a static label like "Managed through our desktop platform" considered a call to action if there's no link or button? Would a "Contact Sales" form (just collects an email, follow-up happens outside the app) be a safer approach? We did check with Apple Developer Support (Aug 2026) and were told this should be fine, but want to hear from anyone who's shipped something similar before we submit. Thanks.

I’m trying to determine the supported submission path for the first non-consumable IAP in a watchOS-only app. Configuration The app uses a standard watch-only container: Container: com.seanfu.safe Watch app: com.seanfu.safe.watchkitapp ITSWatchOnlyContainer = true WKWatchOnly = true WKApplication = true It offers one non-consumable “Full Version” unlock and uses StoreKit 2: Product.products(for:) Product.purchase(options:) Transaction.currentEntitlements Transaction.updates The product ID in the Release binary exactly matches App Store Connect. Paid Apps agreements, banking, tax, pricing, and territory availability are active. The Release archive contains no local .storekit configuration or test bundle. TestFlight works, but App Review receives no product In TestFlight, using the real App Store sandbox and App Store Connect product configuration, Product.products(for:) returns the correct product, localized price, and title. The purchase sheet can be presented. During App Review, the same request repeatedly returns an empty array without throwing an error. The reviewer sees this application-defined diagnostic: IAP-L-01(empty x5) This is not an Apple or StoreKit error code. It means: Five separate Product.products(for:) calls completed without throwing. Every call returned an empty product array. The diagnostic appears only after the initial request and limited retries are exhausted. Thrown StoreKit errors use different diagnostics. The app does not locally filter a successfully returned product. Therefore, the screenshot means StoreKit returned no matching product in five consecutive requests. This has happened in multiple review attempts, while the same Release code path works in TestFlight. An App Review representative contacted us and explicitly stated that a watchOS-only app can be reviewed and tested with IAP. They suggested investigating our StoreKit integration, but our audit found no code path that could transform a non-empty response into this diagnostic. Submission behavior changed Earlier watchOS-only builds could be submitted with both: The app version The “Full Version” IAP Those submissions reached App Review, where the product was empty: Submission accepted → Review starts → Product array is empty For build 23, we explicitly added the In-App Purchase capability to the Watch target in Xcode. The project now records the IAP capability and explicitly links StoreKit.framework. This did not add an IAP entitlement to the signed app. The bundle IDs, watch-only packaging, product ID, StoreKit code, pricing, availability, agreements, banking, and tax status remained unchanged. After uploading build 23, App Store Connect no longer allows the app version and IAP to be submitted together. The draft contains: iOS App 1.0, build 23 The “Full Version” non-consumable IAP App Store Connect blocks the submission and says IAPs and subscriptions are not supported on Apple Watch and must be removed from the submission. The behavior is now: App version + IAP selected → Submission blocked before review This timing does not prove that adding the Xcode capability caused the change. App Store Connect may have changed its validation, or the new build may have caused its watch-only classification to be reevaluated. However, the transition is notable: earlier submissions were accepted but the product was unavailable during review; the current submission is blocked entirely. Contradictory documentation StoreKit documentation says the Swift IAP API is available on watchOS 8+: https://developer.apple.com/documentation/storekit/choosing-a-storekit-api-for-in-app-purchases The documentation for purchase(options:) specifically says to use it for apps running on watchOS: https://developer.apple.com/documentation/storekit/product/purchase(options:) However, App Store Connect documentation says IAPs are not supported on Apple Watch and must be removed before submitting an Apple Watch app version: https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-in-app-purchase/ The same page says the first non-consumable IAP must be submitted with a new app version. This creates a circular requirement: The first non-consumable IAP must accompany an app version. An Apple Watch app version cannot include an IAP. A watchOS-only app therefore appears unable to submit its first IAP. Questions What is the supported path for submitting the first non-consumable IAP of a watchOS-only app? Can Apple review the first IAP separately, or apply a backend override, despite the requirement to include it with an app version? Is an iPhone companion app required, with watchOS IAP support intended only for Watch apps associated with a regular iOS app? Could the unsupported submission association explain why TestFlight sandbox returns the product while App Review receives an empty array? Why were earlier watchOS-only submissions accepted with the IAP attached, while build 23 is blocked despite unchanged bundle IDs and watch-only packaging? Does App Store Connect use the Xcode IAP capability or explicit StoreKit linkage when validating the submission? Clarification from a StoreKit or App Store Connect engineer would be greatly appreciated. The StoreKit documentation, App Store Connect validation, and guidance from App Review currently describe different behaviors.

Summary: The "In-App Purchases or Subscriptions" selection section does not appear on my app version page, so I cannot attach my first In-App Purchase to my build. This has caused four consecutive Guideline 2.1(b) rejections. Setup: App: Qmetra IQ (Apple ID 6791254506, Bundle ID com.vibecode.qmetraiq.londa9) First app release, never published App version 1.0, current build 1.0.1 (2) Non-consumable IAP: com.vibecode.qmetraiq.londa9.results (Apple ID 6792799431) IAP status: Ready to Submit App Review screenshot for the IAP: uploaded (1242×2688) Paid Apps Agreement signed, banking and tax complete, no open items under Business What I see: On the version page, the "In-App Purchases or Subscriptions" heading exists, but contains only an informational message ("...add an app version to your submission so the items are reviewed together..."). There is no button, link, checkbox, or "+" to select the IAP. The submission draft panel contains only the app version, with no way to add the IAP. Opening the draft from the IAP page shows only the IAP, with the warning "Cannot be submitted for review — add an app version for the selected platform", and the "Submit for Review" button greyed out. What I have tried: Removed the previous rejected submission from review, then rechecked the version page — section still absent Assigned a fresh build (1.0.1 build 2) and saved Re-saved the IAP metadata Resubmitted the app version alone — rejected again under 2.1(b) Replied in the review thread twice — no resolution Rejection reason each time: "one or more of the In-App Purchase products have not been submitted for review." Could an Apple staff member please forward this to App Store Connect Support or engineering so the In-App Purchase can be moved to In Review manually? Several older threads describing this exact bug were only resolved that way. Happy to share more details privately if needed. Thank you.

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.

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.

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?

Hi everyone, Not sure if this is a known App Store Connect bug but hoping either someone here has a workaround, or an Apple engineer can help push this along. Background: this is my first In-App Purchase submission for my app. My original binary was submitted without the IAP attached (my mistake, first time doing this), so the app was rejected under Guideline 2.1(b) for referencing a paid feature whose IAP wasn't submitted for review. Since then: The IAP (non-consumable, one-time purchase) is fully configured with a review screenshot and notes, and shows status "Ready for Review" after submitting via "Add for Review" My app version is in a rejected state with an "Update Review" button available The problem: I can't get these two linked together anywhere in the UI. Clicking "Update Review" on the version page resubmits it, but never shows any option to attach the IAP Clicking "Add for Review" from the IAP page opens a Draft Submission, but that draft says "Unable to Submit for Review: To submit your items for review, add an app version for the selected platform," with no version selector anywhere in that panel Tried hard refresh, incognito, different browsers, starting a fresh draft submission. Same result every time. Result: resubmitted the app, got the exact same 2.1(b) rejection again, confirming the IAP genuinely never made it into the review package despite showing as correctly configured on my end. I've seen a few other threads describing what sounds like the exact same issue, where the "In-App Purchases and Subscriptions" section disappears from the version page after a first rejection, and the fix ended up requiring an Apple support agent to manually push the IAP status forward on the backend, without needing another binary. Has anyone found a way to trigger this from the developer side, or is direct support/engineering intervention really the only path? Already have a case open with Apple Developer Support as well, happy to share the Case ID via DM if that helps someone from Apple locate it faster. Thanks in advance for any pointers.

Dear Apple Support, I am writing to report a payment issue with my App Store Connect developer account. The latest payment is marked as "Paid" in the Payments and Financial Reports section, but as of today, more than 3 business days have passed and the funds have not yet arrived in my bank account. I have double-checked that my banking information is accurate and up to date. I would appreciate it if you could investigate this issue and provide further clarification on the current status of the payment. Thank you in advance for your support.

Hi everyone, Running into not really sure if it's App Store Connect bug but hoping either someone here has a workaround, or an Apple engineer can help push this along. Background: this is my first In-App Purchase submission for my app. My original binary was submitted without the IAP attached (my mistake, first time doing this), so the app was rejected under Guideline 2.1(b) for referencing a paid feature whose IAP wasn't submitted for review. Since then: The IAP (non-consumable, one-time purchase) is fully configured with a review screenshot and notes, and shows status "Ready for Review" after submitting via "Add for Review" My app version is in a rejected state with an "Update Review" button available The problem: I can't get these two linked together anywhere in the UI. Clicking "Update Review" on the version page resubmits it, but never shows any option to attach the IAP Clicking "Add for Review" from the IAP page opens a Draft Submission, but that draft says "Unable to Submit for Review: To submit your items for review, add an app version for the selected platform," with no version selector anywhere in that panel Tried hard refresh, incognito, different browsers, starting a fresh draft submission. Same result every time. Result: resubmitted the app, got the exact same 2.1(b) rejection again, confirming the IAP genuinely never made it into the review package despite showing as correctly configured on my end. I've seen a few other threads describing what sounds like the exact same issue, where the "In-App Purchases and Subscriptions" section disappears from the version page after a first rejection, and the fix ended up requiring an Apple support agent to manually push the IAP status forward on the backend, without needing another binary. Has anyone found a way to trigger this from the developer side, or is direct support/engineering intervention really the only path? Already have a case open with Apple Developer Support as well, happy to share the Case ID via DM if that helps someone from Apple locate it faster. Thanks in advance for any pointers.

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

Our app is live on the App Store, but its two auto-renewable subscriptions have been stuck in "In Review" for over a month. Users can download the app but cannot subscribe — in production, StoreKit only returns approved products, so our paywall shows nothing and monetization has been completely blocked since launch day. APP / PRODUCT DETAILS App: 流动 (Flow) — Apple ID: 6772474397 App status: v1.0.0 (build 625), approved and live since July 23, 2026 Subscription group: "Flow Premium" (ID 22108903) — the group itself shows "Approved" Products stuck in "In Review": com.echo.flow.premium.monthly (1 month) com.echo.flow.premium.yearly (1 year) Paid Apps Agreement is active; banking and tax are complete TIMELINE Jul 12: First contacted Developer Support (Case ID 102939768542). At that time the subscriptions were stuck in "Waiting for Review" and could not be attached to any version submission. Jul 23–24: Followed up; was told the issue had been "escalated to the appropriate internal team". Shortly after, both subscriptions moved from "Waiting for Review" to "In Review" — the only progress in this entire period. Jul 31 → Aug 3 reply, and Aug 7 → same-day reply: two more follow-ups on the same case. Both replies were the identical "escalated to the internal team" template. No one has contacted me since, and the status has never changed. Aug 18 (today): Both subscriptions are still "In Review" — roughly 4 weeks in this state, 5+ weeks since my first support contact. Normal IAP review is said to be 24–48 hours. NO ACTION IS AVAILABLE ON MY SIDE Both subscription pages are locked: I cannot edit metadata, delete the products, or remove them from review. "Add for Review" is greyed out. They cannot be selected on a new app version page (they are not in "Ready to Submit"). So this appears to be stuck inside the review pipeline itself, and nothing in App Store Connect lets me unblock it. REQUEST Could someone from the App Store Commerce / App Review team please either: Complete the review of these two subscriptions, or Reset them to "Ready to Submit" so I can immediately resubmit them — with a new app version if required (build 626 is ready to go). I've seen a very similar case in this forum (thread 818811) resolved after an App Store Commerce Engineer looked into it — I'd be grateful for the same kind of help. Thank you!

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)

I’m stuck in a loop where my in-app purchase (IAP) product cannot be reviewed because my app version is in “Rejected” status. In order to submit the IAP for review, I need to submit a new app version and select the IAP product. But since the current version is rejected, I can't select the IAP during submission. As a result, RevenueCat can't fetch the IAP products, and the app appears to not use in-app purchases, which leads to another rejection. I’d like to know the correct steps to break this cycle and properly submit both the app and the IAP for review. Any guidance is appreciated!

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!