App Store Connect displays the In-App Purchases and Subscriptions section on your app's version page when your app has an In-App Purchase or subscription with a Ready to Submit status. To locate the In-App Purchases and Subscriptions section: In Apps, select the app you want to view. In the sidebar, select the app version. On the version page, scroll down to the In-App Purchases and Subscriptions section. For more information, see Submit an In-App Purchase.

General: Forums topic: StoreKit Forums tag: In-App Purchase App Store Pathway Simple and safe In-App Purchases Auto-renewable subscriptions In-App Purchase documentation Getting started with In-App Purchase using StoreKit views documentation Supporting business model changes by using the app transaction documentation Testing at all stages of development with Xcode and the sandbox documentation App Store Server Notifications documentation App Store Server API documentation Simplifying your implementation by using the App Store Server Library documentation TN3185: Troubleshooting In-App Purchases availability in Xcode technote TN3186: Troubleshooting In-App Purchases availability in the sandbox technote TN3188: Troubleshooting In-App Purchases availability in the App Store technote Understanding StoreKit workflows sample code Implementing a store in your app using the StoreKit API sample code What’s new in StoreKit and In-App Purchase video

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.

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.

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?

Hey, I am trying to submit but I keep getting these 2 errors :-) Unable to Submit for Review Your auto-renewable subscription must be submitted with its subscription group. To submit your items for review, add an app version for the selected platform. Problem is I cannot find where to do this. The UI is appaling.

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.

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...