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?

Hi, Overview In my project I am using a .storekit StoreKit configuration file that is synced. I have only non-consumable products Problem When I loop through Transaction.currentEntitlements after verification the properties such as transaction.productType are all NULL. Note I have called .finish on the transaction after the following: Processing Transaction.updates Processing purchasing a new product Environment: Xcode 27 Beta 5 iOS 26.6 Questions How can I resolve this? Am I missing something? Should I be using Transaction.latest(for:) instead of Transaction.currentEntitlements?

FB: https://feedbackassistant.apple.com/feedback/22556883 We're seeing a small number of production users where both Transaction.currentEntitlements and Transaction.all return zero transactions for a valid, active, non-refunded non-consumable IAP. This makes it impossible to restore the purchase via any StoreKit 2 API. Environment: Xcode 26.4 (Build 17E192) iOS 26.4.1 Direct call to SK2 Transactions.all & Flutter in_app_purchase package v3.2.3 (uses SK2 on iOS 15+) Non-consumable IAP (one-time purchase) What we observe: AppStore.sync() triggers but the purchase stream returns 0 transactions Transaction.all returns empty Transaction.currentEntitlements also returns empty User is confirmed on the correct Apple ID Issue reproduces on both iPhone and Mac for the same Apple ID Issue appears to have started recently for users who previously had no problems Debug log from affected production user: [2026-04-20T08:50:10.744115Z] init: iapAvailable=true [2026-04-20T08:50:10.744566Z] init: isPremium=false [2026-04-20T08:50:10.744567Z] init: triggering silent restorePurchases [2026-04-20T08:50:45.974566Z] restore: started [2026-04-20T08:50:45.986848Z] restore: sk2Transactions count=0 [2026-04-20T08:50:45.993004Z] restore: sk2Direct isVerified=false active=null [2026-04-20T08:50:45.993011Z] restore: sk2Direct inconclusive — falling back to standard restore [2026-04-20T08:51:16.000851Z] restore: timed out after 30s — fallback isPremium=false [2026-04-20T08:51:16.000910Z] restore: completed — succeeded=false foundPurchase=false Unable to reproduce in sandbox — Transaction.all works correctly there. Appears specific to production for a small subset of users. Has anyone else seen this?

Product: Auto-renewable annual subscription Environment: Production iOS version: 26.6 StoreKit version: StoreKit 2 I have an active subscription that shows correctly in the App Store app, but neither Transaction.currentEntitlements nor Product.SubscriptionInfo.Status (via subscription.status) return any record of it — both come back empty. What I've checked: Transaction.currentEntitlements — iterated fully, zero transactions found for this product ID Product.SubscriptionInfo.Status — checked independently as a second signal, also returns no active status for this product AppStore.sync() — called before checking entitlements, completes successfully, does not resolve the issue Settings → [Apple ID] → Subscriptions on-device — does not show this subscription "Restore Purchases" in-app — consistently reports nothing found Impact: Since my app gates access behind an active entitlement check, this means the user is stuck on the paywall screen indefinitely, despite having a valid, active, paid subscription. There's no client-side workaround, since every available StoreKit 2 API reports no entitlement exists. Code pattern (simplified): swift for await result in Transaction.currentEntitlements { if case .verified(let transaction) = result, transaction.productID == productID { // never reached for this product } } if let subscription = product.subscription { let statuses = try await subscription.status // statuses is empty / doesn't reflect the active subscription } This looks consistent with the pattern reported in thread 823454, where currentEntitlements and Transaction.all return empty for valid, non-refunded purchases in production for a small number of users. In my case, this is affecting a currently active subscription — not a refunded or expired one — and is reproducible on this account across multiple app builds. Has anyone found a reliable workaround, or is this being tracked by Apple as an active known issue beyond the fix already applied for the non-Gregorian calendar case (which doesn't apply here)?

Hi, I'm hoping someone from App Review can help, as email support has not resolved this. We publish digital magazine apps where each new issue is sold as a separate in-app purchase. Two of our IAPs have now been stuck in "Waiting for Review" / "In Review" for 3-4 weeks, well beyond the normal 24-48 hour turnaround we've seen on previous submissions. Because of this, we are currently unable to sell our product to paying customers. Readers cannot purchase the current issues at all. This is actively affecting live revenue, not just a delayed update. We've already sent two emails to Developer Support with no meaningful response beyond being asked to keep waiting, and a Contact Us request through App Store Connect has not moved things forward either. Could someone from App Review please look into why these specific IAP submissions have been stuck for so long, and help move them forward? I'm happy to provide the App ID / bundle ID and IAP product IDs privately to a verified Apple team member. Thank you for any help you can offer.

Title: In-App Purchases Stuck on “Ready for Review” After App Submission I’m running into an issue in App Store Connect with several consumable In-App Purchases. I have four IAPs that currently show Ready for Review: MetaOp 250k Burst (Free Tier) MetaOp 250k Burst (Paid Tier) MetaOp 500k Burst (Free Tier) MetaOp 500k Burst (Paid Tier) I previously added these IAPs to a submission and later removed them. I have now submitted the app version again, and the app itself is showing Waiting for Review, but these four IAPs are still listed under Drafts as Ready for Review. The issue is that I cannot select them from the In-App Purchases list or attach them to the current submission. They also did not move into the submitted review package when I submitted the app. Has anyone seen this behavior before? Is there a way to reset these IAPs back to Prepare for Submission, or otherwise attach/submit them separately without withdrawing the app version that is already Waiting for Review?

TL;DR: Does iOS automatically receive App Store transaction updates in the background when internet connection is available so the backing storage state of Transaction.currentEntitlements gets synced even when my app is not running? Or does iOS update Transaction.currentEntitlements only when my app is running? The long version: Imagine the following situation: A user has purchased a non-consumable IAP in my app and is granted the locked premium content. The IAP transaction is now present in Transaction.currentEntitlements (it's also cached locally). The user blocks internet access every time before my app gets opened (either enables the Airplane mode and/or disconnects from the Wi-Fi before launching my app). So from this point on, my app never gets a chance to connect to the internet. The user gets refunded for the IAP. The user uses their iPhone to browse the internet via Safari, checks emails, etc. Then, before launching my app, the user blocks internet access. My app gets is launched (without internet access) and reads entitlements from Transaction.currentEntitlements. The question is: does the StoreKit service know that the IAP has been refunded? Did iOS update the local cached storage of Transaction.currentEntitlements while the user was connected to the internet in step 4? Or will Transaction.currentEntitlements contain the old state from step 1 so the app won't know about the refund and the user will be able to use my app's premium content which has been refunded by now? Is the behavior the same for auto-renewable subscriptions as it is for non-consumable IAPs?

We have a non-reader iOS app that sells a subscription unlocking digital features within the app. For users on the United States App Store storefront, we are considering adding a button that opens an external browser and directs the user to a web-based subscription checkout. The completed web purchase would unlock the same digital subscription entitlement in the iOS app. We understand that, following the May 2025 changes to App Review Guidelines 3.1.1 and 3.1.1(a), US storefront apps may include buttons, external links, or calls to action directing users to alternative purchasing methods without requiring the StoreKit External Purchase Link Entitlement. Could someone clarify the following? For a non-reader app on the US storefront, must Apple In-App Purchase remain available alongside the external web checkout? Can the app show only the web-based checkout to US storefront users while continuing to use Apple IAP in other storefronts? Does Guideline 3.1.1 still require every digital subscription available through web checkout to also be available through Apple IAP? If both methods are required, must they be displayed on the same screen, or is it sufficient for both to be reasonably accessible within the app? Is the applicable eligibility determined by the user’s App Store storefront rather than their physical location or IP address? Are there any additional disclosures, entitlements, reporting requirements, or App Review notes required for this US-only flow? We would appreciate references to the applicable current guidelines or official Apple documentation. This question concerns only the United States storefront. We understand that external-purchase programs in the EU and other regions have separate requirements. If you can also share about EU rules for web-based payment, that would be great.

I have two subscription in the same group and the same level 1. One is a monthly one and the other a yearly one. I also have an IAP for Lifetime Unlock. When my app requests for these it only loads Monthly. Debugging reveals that the ASC doesn't return the yearly subscription and the lifetime IAP. When I added a StoreKit config to the app, it correctly show the Yearly subscription as well and the view loads it appropriately. But the storekit config doesn't load IAP. I have checked things several tiles in ASC and in code. What can I do to fix this?

Hello, We are experiencing an issue with App Store Connect and would like to know if anyone has encountered the same problem. Current status: Our app is already approved and live on the App Store. We created three new auto-renewable subscriptions. All three subscriptions have been stuck in "Waiting for Review" for several days. The subscriptions can no longer be edited (localization and review information are locked). The app review has already been completed, so there is no active app review in progress. During this period, Apple System Status reported an App Store Connect incident affecting submission of In-App Purchases and subscriptions. Since that incident was resolved, the subscriptions are still stuck in Waiting for Review. We have already contacted Apple Support and App Review multiple times but have not yet received any response. Has anyone experienced subscriptions remaining permanently in "Waiting for Review" after the App Store Connect maintenance? Is there anything that can be done from the developer side, or does this require Apple to manually reset the review state? Thank you.

I have created some products for in app purchase. But they cant be submitted. Somehow it stays in draft submission. It says: Unable to Submit for Review To submit your items for review, add an app version for the selected platform. But I didnt see where I should add an app version. My app has not launched yet anyway. Should I pass the submitted review first? the app bundle.

I am unable to link my new non-consumable In-App Purchase (idea_think_pro) to my draft update page (iOS 2.0.0).The product is fully configured with required screenshots and metadata, and displays the blue "Add for Review" button. However, clicking it shows the hard validation block: "Your first non-consumable in-app purchase must be submitted with a new app version."Simultaneously, the "In-App Purchases and Subscriptions" section is completely missing from my iOS 2.0.0 version page, even when no app build is attached. I have cleared all active submissions and browser caches. Please manually link Product ID idea_think_pro to App Version 2.0.0 on your database or reset my version layout cache.

We are implementing StoreKit External Purchase Link for an iOS app distributed in the European Union and are trying to determine whether we are missing a configuration step or encountering a StoreKit server-side eligibility issue. The failure is reproducible in a focused native Swift Xcode project that directly calls StoreKit: let eligible = await ExternalPurchaseCustomLink.isEligible The sample contains no Flutter code, PayPal SDK, networking, or application business logic. Configuration we have verified: The Account Holder accepted the StoreKit External Purchase Link Entitlement Addendum for EU Apps. StoreKit External Purchase Link is enabled and shown as Assigned for the App ID. The regenerated Development provisioning profile contains com.apple.developer.storekit.external-purchase-link = true. The installed app's signed entitlements contain the same value. The application-identifier and team-identifier match the intended App ID and team. The compiled Info.plist contains SKExternalPurchaseCustomLinkRegions with all 27 lowercase EU region codes, including "de". Germany is available for the app in App Store Connect. No local StoreKit Configuration file is enabled. Test environment: Physical iPhone running iOS 26.5.2 (23F84) Xcode 26.6 (17F113) Real German Media & Purchases Apple Account German Sandbox Apple Account StoreKit 2 storefront ID 143443, country code DEU StoreKit 1 also reports country code DEU AppStore.canMakePayments = true AppTransaction verifies in the Sandbox environment Clean build and reinstall using the regenerated Development profile Observed result: ExternalPurchaseCustomLink.isEligible = false For diagnostic purposes only, after observing false eligibility, we also requested both token types: ACQUISITION: StoreKitError.notAvailableInStorefront SERVICES: StoreKitError.notAvailableInStorefront A delayed recheck still reports storefront DEU and isEligible=false. Our production flow does not request tokens unless eligibility is true. We found the similar thread "Unable to enable eligibility for External Purchase Link APIs" (https://developer.apple.com/forums/thread/808349). In that case, the production Media & Purchases account had an unsupported storefront. In our case, both the real Media & Purchases account and the Sandbox account are German, and StoreKit itself reports DEU. We also found "External Purchase in Japan" (https://developer.apple.com/forums/thread/822618), where an Apple App Store Commerce Engineer requested a Feedback Assistant report with a sysdiagnose and screen recording for isEligible=false. Questions: Should ExternalPurchaseCustomLink.isEligible return true in a developer-signed Sandbox build when the entitlement, compiled Info.plist, German storefront, and account conditions are all satisfied, or is TestFlight/App Store approval required? Is there any additional App Store Connect storefront election, entitlement approval, or server-side activation step required beyond the EU addendum, Assigned capability, signed entitlement, and SKExternalPurchaseCustomLinkRegions? If this configuration is complete, could Apple verify whether eligibility has not propagated correctly for the German Development/StoreKit Sandbox environment, and which diagnostics should be included in a Feedback Assistant report? We have also opened a code-level support request and prepared a minimal native Swift reproduction project. Any guidance from StoreKit engineering would be appreciated.

Summary: In Sandbox, Product.products(for:) returns all 3 of my IAPs with correct JPY prices and Japanese localizations, but product.purchase() fails immediately — the payment sheet is never presented — with ASDServerErrorDomain Code=3504 (Product.PurchaseError.productUnavailable). All 3 products fail identically. Reproduction captured in the sysdiagnose attached to FB24067333: 2026-07-30 18:43:58 JST — in-app purchase() on app.negaiboshi.placement; 18:44:40 JST — OS-level test (Settings > Developer > Sandbox Apple Account > Manage > Start Transaction), same product ID. Server correlation keys from the device log: inAppBuy → AMSServerCorrelationKey HNB5UGLE72AXSMY5KY7G4NAXQY (failureType 3504); Start Transaction → FQN4Y4JOEHYBW2GIR7KPTYTB2A (AMSServerErrorCode 3766, "provided product ID or bundle ID is invalid"). Environment App: Negaiboshi — Apple ID 6794682125, Bundle ID app.negaiboshi, Team 778QPP83C4 App status: first submission in preparation (never reviewed); build 1.0 (1) on TestFlight IAPs (all "Ready to Submit" since 2026-07-27 JST, attached to the 1.0 submission): app.negaiboshi.pro.monthly (auto-renewable, ¥480, group 22264517), app.negaiboshi.placement (non-consumable, ¥720), app.negaiboshi.nightsky (non-consumable, ¥1,200) IAP base country: Japan (JPY); availability 145/175 countries Device: iPhone, iOS 26.5.2; development build from Xcode; StoreKit Configuration = None Sandbox Apple Account: (address in FB24067333), region Japan, no purchase history; signed in under Settings > Developer Storefront.current = JPN. No Screen Time restrictions. Actual error (verbatim): Error Domain=ASDServerErrorDomain Code=3504 "このアイテムは見つかりませんでした。" UserInfo={AMSServerErrorCode=3504, client-environment-type=Sandbox, storefront-country-code=JPN} TN3186 checklist fully verified, none apply (Paid Apps Agreement, banking, tax all active; bundle ID + IAP capability; signing; membership). Also tried: Sandbox sign-out/sign-in, device restart — no change. Consistent across all 3 products and relaunches. Reproduced with zero app code involved (decisive): Settings > Developer > Start Transaction with product ID app.negaiboshi.placement and bundle ID app.negaiboshi fails: "The provided product ID or bundle ID is invalid. [Environment: Sandbox]" — Apple's own OS-level tool, no third-party code. Calibration: a deliberately nonexistent ID (app.negaiboshi.zzz) yields the identical error — the backend treats my real product like a nonexistent one. A price change (¥720→¥700, "now", 2026-07-29) propagated to the sandbox metadata catalog within minutes (products(for:) returned "¥700") — purchase() still 3504. Reverted. A full base-country change (2026-07-30): Japan (¥720) → United States ($4.99) at 15:52 JST — this deletes and recreates the price schedule and is the exact operation that resolved the identical symptom in thread 839557. It propagated to the metadata catalog (auto-converted ¥800 shown in ~20 min), yet purchase() and Start Transaction still failed at 16:10 and 16:55 JST. Reverted to ¥720 at 16:59 JST. Every lever that rewrites the price schedule reaches the metadata catalog but never the commerce/purchase catalog. Timeline: the products reached Ready to Submit hours after the 2026-07-26 15:22–17:58 PDT In-App Purchases outage (Message ID 1000005803), and the failure still reproduces after the 2026-07-29 16:20–19:30 PDT emergency maintenance on In-App Purchases + Advanced Commerce API (messageId 1000005805). Peer reports with the same metadata-vs-commerce-catalog split in the same window: threads 839220, 839441, 839437, 839645, 839557. Questions: Why does purchase() fail server-side with 3504 ("item not found") while products(for:) succeeds for the same IDs in the same JPN storefront? Can someone check the sandbox commerce-catalog state of the 3 product IDs above (Apple ID 6794682125)? This looks like a server-side provisioning failure that no developer-side action can repair. Is any additional App Store Connect state required before sandbox purchases can complete for a never-yet-reviewed app?

Summary Sandbox purchases of our first auto-renewable subscription fail with "This item cannot be found". Product metadata loads correctly, so this looks specific to commerce. Our App Store Connect configuration is complete and has been verified exhaustively, and four other apps on the same team sell in-app purchases in production without issue. The affected app has never been submitted or released, and the subscription sits in "Ready to Submit". Symptoms On device (TestFlight build, purchasing with the tester's real Apple Account - no sandbox Apple Account is configured, per the documented TestFlight flow), a purchase attempt returns storeProductNotAvailable and the system alert "Item Unavailable". Device logs (idevicesyslog) show: mzstorekit-sb.itunes.apple.com/inApps/v2/history -> HTTP 404, (4040004) App not found sandbox.itunes.apple.com/.../inAppBuy -> AMSErrorDomain 305, AMSServerErrorCode=3504, "This item cannot be found" Product.products(for:) returns the product and the paywall renders product.displayPrice, so product metadata resolves. Only the purchase fails. Server-side observation Using the App Store Server API in the sandbox environment with our team key, requesting a deliberately non-existent transaction ID: GET https://api.storekit-sandbox.itunes.apple.com/inApps/v1/history/1234567890 App Products Released? Result The affected app 1 subscription, Ready to Submit never HTTP 401, empty body Another app, same team non-consumable, Approved yes 404 4040010 Transaction id not found Another app, same team 2 non-consumables, Approved yes 404 4040010 Transaction id not found Another app, same team 2 non-consumables, Approved yes 404 4040010 Transaction id not found Another app, same team non-consumable, Approved yes 404 4040010 Transaction id not found Same key, same issuer, same team, same request shape - only the bid claim differs. We note openly that this is not a clean experiment: all four comparison apps differ from the affected app in two ways at once (they are released, and they have approved products), so the 401 may simply reflect an app with no approved commerce products rather than a missing app record. We include it because the difference is stark and reproducible, not because we think it is conclusive. What makes this app different Being unreleased does not by itself appear to be the barrier: we were able to test the in-app purchases of the four apps above in the sandbox before those apps were released. The difference we cannot account for is product type and approval state - those were one-time non-consumables, whereas this is our first auto-renewable subscription, which App Store Connect tells us "must be submitted with a new app version" and which has therefore never been approved. Timeline 2026-07-30 ~00:30 CEST - Pricing and Availability set for the app (it had been unset; that was the cause of an earlier, separate failure). 2026-07-30 09:26 CEST - captured the device logs above. 2026-07-31 00:50 CEST - toggled a territory's availability off and back on to force a re-propagation of the availability record. No change. 2026-07-31 - still failing 24+ hours on. Automated probes every 30 minutes throughout have returned the same result without exception. This is well beyond the "up to 1 hour" propagation window documented in TN3186. Already verified Account level - four other apps on this same team currently sell in-app purchases in production: Paid Apps agreement: Active Banking and tax information: complete and active App Store Connect configuration for the affected app: App availability: 175 of 175 territories, none excluded Subscription availability: 175 of 175 territories Subscription priced in all 175 territories Four localizations and the review screenshot present; group localized; subscription state Ready to Submit App price: Free Every territory reads CANNOT_SELL / AVAILABLE_FOR_SALE_UNRELEASED_APP, consistent with an app that has not yet been released Client / build: Product ID in code matches App Store Connect exactly Explicit App ID (no wildcard), In-App Purchase capability enabled Build signed with Apple Distribution, delivered via Transporter, tested from TestFlight (not a development build) No StoreKit configuration file active in the scheme Bundle ID matches the App Store Connect record Questions Is the subscription provisioned for commerce in the sandbox environment? The (4040004) App not found response suggests the app or its commerce record is not present there. TN3186 states that sandbox testing does not require submitting in-app purchases for review. Does that hold for an app's first auto-renewable subscription, given that such a subscription must be submitted alongside an app version and so cannot reach an approved state beforehand? If submitting the app version together with the subscription is in fact the prerequisite, please confirm - we are currently holding our submission specifically so we can complete one successful sandbox purchase first, since App Review purchases through this same environment. If that ordering is not possible, we would rather submit and have App Review encounter the working production path than keep waiting on a sandbox purchase that cannot succeed. Happy to provide the app's Apple ID and product identifier privately if that helps.

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

Well, here we go again. The subscription items are rejected because I have not submitted a binary. (Except I have, of course.) The binary is rejected because I have not submitted the IAP subscription items. (Except I have, of course.) Neither lets me submit the other again alongside it. Brilliant system.

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

Hello, I'm developing a consumer iOS app (Capacitor + RevenueCat SDK) and I've been blocked for several weeks on a StoreKit issue: subscription products are never returned to the device, so the Apple payment sheet cannot open. I previously contacted Apple Support. I was told to request a phone call, but my call request was declined because of the topic (StoreKit / in-app purchases). I'm posting here hoping someone from Apple or the community can help. App details App name: Vytal AI Bundle ID: com.ciborgu.vytalai App Store Connect App ID: 6767160542 Team ID: JZF7CR3W8Z Distribution: TestFlight (physical iPhone, France) iOS deployment target: 15+ Subscription product IDs (auto-renewable) vytalai_premium_monthly vytalai_premium_yearly vytalai_premium_yearly_intro All three are in subscription group "Vytal AI" on the correct ASC app (not a typo bundle). Cleared for Sale is ON. Paid Apps Agreement is active. In-App Purchase capability is enabled on the App ID (checkbox is grayed out / locked, which I understand is normal). Problem On a real device via TestFlight: RevenueCat SDK configures successfully (public iOS API key present in build). Purchases.getProducts({ productIdentifiers: [...] }) returns { products: [] } — zero products. Because StoreKit returns an empty array, the Sandbox payment sheet never appears when the user taps Subscribe. This is NOT a UI issue — the native SDK call to Apple returns no products. What I've already verified Bundle ID in signed IPA matches ASC app: com.ciborgu.vytalai Subscriptions exist only on the correct app (not on an old typo bundle com.ciborgue.vytalai) Removed duplicate ASC app; old App ID cannot be deleted ("in use by App Store") but has no IAPs Regenerated EAS provisioning profile for com.ciborgu.vytalai Sandbox tester account configured on device (Settings → App Store → Sandbox Account) Tested without VPN / iCloud Private Relay Reinstalled app from TestFlight after ASC changes Waited for propagation after metadata / availability updates Associated Domains enabled (for deep links) — separate from IAP SDK / integration @revenuecat/purchases-capacitor 13.x Direct StoreKit fetch via Purchases.getProducts() (not only RevenueCat offerings) Same result: 0 products from Apple Expected vs actual Expected: StoreKit returns 3 subscription products in Sandbox; payment sheet opens on purchase. Actual: products array is always empty; no payment sheet. Questions Why would StoreKit return 0 products for valid auto-renewable subscriptions on TestFlight when metadata is "Waiting for Review" / in review — shouldn't Sandbox still return products per TN3186? Is there an ASC configuration state (availability, subscription group localization, missing review screenshot on yearly products, etc.) that causes StoreKit to return zero products even in Sandbox? Is there an internal flag or propagation delay on Apple's side I should ask to be reset for this app/bundle? I'm happy to provide additional logs, a sysdiagnose, or a short screen recording from TestFlight showing the empty product response. Thank you for any guidance — this is blocking App Review (Guideline 2.1) and I cannot test IAP at all. Nathan

Hi, I’m testing an iOS app with auto-renewable subscriptions in the Apple sandbox environment. The app has its own account system. A user can create/log in with different accounts inside the app. The issue I’m seeing is this: I subscribe to the Pro plan using one sandbox Apple ID. Then I log out of the app. I create or log in with a different account inside the app, but still on the same iPhone / same sandbox Apple ID. Inside the app, this new app account is not marked as subscribed. When I try to subscribe again, StoreKit returns: “Item already owned” So Apple recognizes that the Apple ID already owns the subscription, but our app account does not have Pro access yet. The only way to resolve this is to provide a “Restore Purchase” option, so the current app account can restore the subscription already owned by the Apple ID. My questions are: Is this expected behavior for auto-renewable subscriptions? Can this happen in production too, or is it mainly a sandbox behavior? If a user has multiple accounts inside the app but uses the same Apple ID, is the subscription considered owned by the Apple ID and restorable across those app accounts? Is it acceptable/recommended to keep a small “Already subscribed? Restore purchase” option visible on the paywall at all times? If the app wants to prevent the same Apple subscription from being used across multiple internal app accounts, what is the recommended approach? For brand new Apple IDs that have never subscribed before, the normal purchase flow works correctly. Thank you.