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.

Hello, I am trying to submit my In-App Purchase subscriptions for review, but App Store Connect is preventing the submission. I have already created: A subscription group ("Piscineiros Pro") Two auto-renewable subscriptions All required metadata and review screenshots When I open the draft submission, I receive the following message: "Unable to Submit for Review. To submit your items for review, add an app version for the selected platform." However, my app version (iOS 4.8.3) already exists in App Store Connect and was previously submitted for review. I would like to understand: Do I need to create a new app version and upload a new binary before I can submit these subscriptions for review? Is it possible to associate the existing subscriptions with the currently rejected app version? What specific steps are required to submit these In-App Purchase products together with my app review? Thank you for your assistance. Best regards, Luiz Maueski

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.

Our app BandPro (Apple ID 6793207475) has been rejected three times under Guideline 2.1(b) because the In-App Purchase products were "not submitted for review". Everything is ready on our side, but App Store Connect will not let us put the app version and the IAPs into the SAME review submission: New binary uploaded: iOS 1.0 (build 22), attached to the version. 7 IAPs in "Ready to Submit": 4 auto-renewable subscriptions in the group "BandPro Pro" + 3 consumables. All have prices, availability in 175 storefronts, review screenshots and review notes. The app version is locked inside the REJECTED submission ("Unresolved Issues"). The only action available there is "Resubmit to App Review", which sends the version ALONE - exactly what caused the 2nd and 3rd rejections. Adding the IAPs for review creates a SEPARATE draft submission. That draft cannot be sent: it shows "To submit your items for review, add an app version for the selected platform" - but the version cannot be added because it is held by the rejected submission. We replied to App Review in the Resolution Center on Aug 1 explaining this. No response yet. We also saw the recent reply from an App Store Commerce Engineer saying the In-App Purchase submission experience was recently updated and an issue affected some submitted IAPs - our timeline matches that window. Could someone from Apple help us either: (a) attach the 7 ready IAPs to the existing submission so everything is reviewed together, or (b) release the app version from the rejected submission so we can create ONE new submission containing the version + all IAPs? We would like to avoid deleting and recreating the subscription group, since the product IDs are already live in our billing stack and on Google Play. Thank you!

Hi everyone, I'm investigating an issue related to StoreKit 1 receipt validation and would appreciate any insight from Apple engineers or developers who have encountered this before. Environment StoreKit 1 Consumable In-App Purchase iOS 16 / iOS 17 / iOS 18 (observed on multiple versions) Receipt validation performed on our server Receipt is read from the app bundle after the transaction completes Issue Occasionally, after a purchase succeeds and the transaction reaches the SKPaymentTransactionStatePurchased state, the App Receipt exists and can be decoded successfully, but the receipt contains: { "receipt": { ... "in_app": [] } } The in_app array is completely empty. As a result, our server cannot find the purchased product in the receipt and cannot complete receipt validation. Questions I'd like to understand under what circumstances Apple may return an App Receipt where receipt.in_app is empty. Specifically: Is it expected behavior that receipt.in_app can be empty after a successful consumable purchase? Could this happen if the app reads the receipt before the receipt has been updated? Is there any possibility that calling finishTransaction: before reading the receipt could cause the purchase record not to appear in receipt.in_app? If receipt synchronization is delayed, what is Apple's recommended approach? Wait and retry? Issue an SKReceiptRefreshRequest? Or validate using another mechanism? Are there any documented scenarios where Apple intentionally returns an empty in_app array? Additional Information The transaction state is Purchased. The purchase callback is received successfully. We have confirmed that the receipt file exists. The issue occurs only occasionally and cannot be reproduced consistently. Most purchases contain the expected in_app entry. Any clarification about the expected behavior of the App Receipt or recommended best practices would be greatly appreciated. Thank you!

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.