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

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

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

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?

Summary: We gate premium access on the renewal status returned by Product.SubscriptionInfo.Status.all, following the pattern in your Implementing a store in your app using the StoreKit API sample (CustomerEntitlements.checkCurrentStatuses()). In production we are seeing a subset of users whose Status.all yields zero statuses, even though they hold an active subscription with a future expiration date (according to our own persisted state). This causes us to incorrectly treat them as unsubscribed. How we read status: func currentSubscriptionStatuses() async -> [SubscriptionStatusInfo] { await Product.SubscriptionInfo.Status.all .collect() .flatMap(.1) .compactMap(SubscriptionStatusInfo.init(skStatus:)) } The compactMap only drops entries failing case .verified. In the affected cases Status.all itself emits no (groupID, statuses) pairs at all - the sequence is empty, not filtered. Affected population: Previously had an active paid subscription (our own persisted state shows pro with an expiry date in the future). Not new installs. Questions: Under what conditions can Product.SubscriptionInfo.Status.all return an empty sequence for an Apple Account that currently holds an active auto-renewable subscription (e.g. not signed into the App Store, StoreKit not yet initialized at launch, offline, renewal in flight, Family Sharing)? Is an empty result from Status.all ever authoritative ("no subscription"), or must it always be treated as inconclusive and never used to revoke access? Is there a recommended way to distinguish "no subscription for this account" from "status temporarily unavailable" (e.g. a signal for no signed-in App Store account, or a readiness/error path)? Does Status.all guarantee it reflects a signed-in account context, and what is the expected behavior when the device has no active App Store account at call time?

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)?

iOS 26.4系统上，我们发现三个问题： 1.调用了finishTransaction接口，但是在App重新启动后，[SKPaymentQueue defaultQueue].transactions仍然会有这笔订单。 2.支付完成后，[[NSBundle mainBundle] appStoreReceiptURL]]，拿到的票据解析出来里面的商品是空的，需要延迟2秒钟左右在调用[[NSBundle mainBundle] appStoreReceiptURL]]才能获取有效票据。 3.支付完成后，如果用户没有点击最后弹出的确认弹框，等待5秒钟，系统会自己回调 - (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions; 代理方法。正常应该是用户点击了最后弹出的确认弹框，在回调- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions;方法。 我们在苹果开发者论坛上面找到其他开发者反馈的类似问题，链接如下： https://developer.apple.com/forums/thread/817700 https://developer.apple.com/forums/thread/792437?answerId=849557022#849557022 https://developer.apple.com/forums/thread/817834 https://developer.apple.com/forums/thread/817706 https://developer.apple.com/forums/thread/818586 我们有大量用户升级到了26.4系统，这对于我们造成了巨大的困扰，我们需要你们的帮助，感谢！

We are investigating SKAdNetwork attribution for a production iOS app distributed through the App Store. Bundle ID: com.stencilstudio.app App Store ID: 6760613806 We receive real winning SKAdNetwork postbacks directly from the App Store at our attribution endpoint. The raw Apple payloads consistently contain: version: "3.0" campaign-id: 25 did-win: true Some postbacks also include a valid fine conversion value, for example: conversion-value: 1 However, we have not received postbacks containing: version: "4.0" source-identifier postback-sequence-index coarse-conversion-value The advertising network is Meta. The advertised app is App Store distributed and has an iOS deployment target of 16.1. We are trying to understand one specific technical point: What determines whether the resulting production attribution postback is SKAdNetwork 3.0 or 4.0? In particular: Is the postback version determined by the SKAdNetwork version used by the ad network when signing the winning ad impression? Can anything on the advertised-app side, such as an entitlement, App Store Connect setting, build configuration, registration state, or SDK configuration, cause an attribution to remain on version 3.0? Is there any advertiser-side diagnostic that allows the advertised-app developer to determine which SKAdNetwork version the winning impression was signed with? Given that the postbacks themselves explicitly contain version: "3.0", is there any other condition we should verify on the advertised-app side before asking the ad network to investigate how its impressions are being signed? Example raw postback received directly from the App Store: { "app-id": 6760613806, "fidelity-type": 1, "conversion-value": 1, "campaign-id": 25, "did-win": true, "version": "3.0", "ad-network-id": "v9wttpbfk9.skadnetwork", "redownload": false } We can provide additional production postbacks if useful.

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?

Our app sells two auto-renewable subscriptions. Product loading succeeds and returns both products with correct localized prices, but every purchase attempt fails roughly one second later with "Item Unavailable". No purchase sheet is ever presented to the user. The app has not yet passed its first App Review. It was rejected under Guideline 2.1(b) because the reviewer encountered this same error on their device. MY QUESTION Under what conditions does StoreKit reject a purchase with "Item Unavailable" for a product that has just been returned successfully, with a valid localized price, by a product request? Is an auto-renewable subscription transactable in the sandbox environment for an app that has never had a binary approved by App Review? Question 2 is the one I most need answered. App Review's rejection states that In-App Purchase products "do not need prior approval to function in review", but neither we nor the reviewer can transact them. DIAGNOSTIC LOG Captured on-device during a failing session: 01:08:56 fetchProducts [com.aurascanner.app.pro.weekly, com.aurascanner.app.pro.annual] 01:08:56 fetchProducts -> 2 product(s): com.aurascanner.app.pro.annual=$39.99; com.aurascanner.app.pro.weekly=$6.99 01:08:56 requestPurchase sku=com.aurascanner.app.pro.weekly 01:08:57 purchaseError: code=purchase-error msg=Item Unavailable 01:08:57 error code=purchase-error, storefront=USA 01:09:05 fetchProducts -> 2 product(s), same prices returned again 01:09:05 requestPurchase sku=com.aurascanner.app.pro.annual 01:09:06 requestPurchase threw: Item Unavailable 01:09:06 error code=purchase-error, storefront=USA An introductory-offer eligibility check earlier in the session also succeeded, using the subscription group ID read from the loaded product. So product metadata, including the subscription group, resolves correctly. CONDITIONS Fails identically for both products, on every attempt. Reproduces in TestFlight on our own devices and Apple IDs. Also failed during App Review on iPad Air 11-inch (M3), iPadOS 26.5.2. Storefront reports as USA in every case. Real devices only. Not reproduced on Simulator. ALREADY VERIFIED Paid Applications Agreement: Active, banking and tax information complete. In-App Purchase capability: enabled on the App ID at Certificates, Identifiers & Profiles. Bundle identifier com.aurascanner.app matches the App Store Connect record. Both subscriptions: complete metadata, review screenshots uploaded, USD pricing set, United States availability. Both subscriptions and the subscription group are attached to the current submission, status "Ready for Review". Subscription group has a localized display name. Build distributed via TestFlight, which routes purchases to sandbox automatically. IMPLEMENTATION The app is React Native and uses a wrapper library over StoreKit 2, but the error text originates from StoreKit rather than the wrapper, and the call order follows the documented pattern: Initialize the StoreKit connection. Load products. This succeeds and returns both products. Register transaction update and error listeners. Request the purchase. This is where it fails. Purchases are verified server-side using Apple's App Store Server Library, and the transaction is finished only after verification succeeds. I am not asking anyone to debug the wrapper. My question is about StoreKit and App Store behaviour: what causes the store to quote a product and then decline to sell it? Any pointers appreciated. I can supply screenshots or the full log.

I provide a paid feature behind an annual auto-renewable subscription, using StoreKit 2 and Transaction.currentEntitlements. Many of my users work in remote places with no connectivity for days at a time, so I need to know what happens when a device is offline at the moment the current period ends. The renewal succeeds server-side, but the device cannot fetch the updated signed transaction, so the cached transaction still carries the previous expirationDate, now in the past. Does Transaction.currentEntitlements stop returning the subscription once the cached transaction's expiration date has passed, even though the renewal has already succeeded server-side? Is there any built-in tolerance window on the device that keeps the entitlement alive until the next successful sync with the App Store? Does grace period effect the outcome? I want to avoid revoking access from a paying subscriber who happens to be offline when renewal falls due. Many thanks.

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.

I have the typical StoreKit 2 manager class, where I check currentEntitlements for subscription. I have filed a feedback (FB22349195), I hope someone can take a look at it. func updateCustomerProductStatus() async { var activeSubscription: String? = nil // BUG: In some cases the currentEntitlements does not emit a transaction until the device is reboot for await result in Transaction.currentEntitlements { print("Found transaction: \(result)") // This print does not appear until a restart! do { let transaction = try checkVerified(result) // Skip revoked transactions if transaction.revocationDate != nil { print("Skipping revoked transaction for \(transaction.productID)") continue } // Skip expired subscriptions if let expirationDate = transaction.expirationDate, expirationDate < Date() { print("Skipping expired subscription for \(transaction.productID)") continue } // Check product type switch transaction.productType { case .autoRenewable: activeSubscription = transaction.productID default: break } } catch { print("Unable to verify transaction: \(error)") } } // Update state once after processing all entitlements self.activeSubscription = activeSubscription print("updateCustomerProductStatus() activeSubscription: \(activeSubscription ?? "nil")") } There is some unexpected behavior where the currentEntitlements does not emit a result until the iPhone device is reboot. This bug appeared in iOS 26.4 (and in the betas).

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?

Hi all, I've been debugging a persistent sandbox StoreKit issue for a while now and have ruled out everything I can check from my end. Posting the full picture here in case anyone recognizes this pattern or has advice — genuinely stuck. The core problem AppTransaction.shared (StoreKit 2) consistently fails with: Error Domain=SKServerErrorDomain Code=-1 "(null)" UserInfo={storefront-country-code=AUS, client-environment-type=Sandbox} A real purchase attempt separately fails with: Error Domain=ASDServerErrorDomain Code=3504 "This item cannot be found." UserInfo={storefront-country-code=AUS, AMSServerErrorCode=3504, client-environment-type=Sandbox} What's confirmed working (so I can rule these out as the cause) Product catalog/pricing fetch — real price, title, currency load correctly every time canMakePayments → true getStorefront → AUS, correctly App Store Connect account: Paid Apps Agreement Active, Free Apps Agreement Active, bank account Active, all 3 tax forms Active (ABN/GST, Certificate of Foreign Status, W-8BEN) The IAP itself: correctly configured (com.subwizard.subwizard.unlock, Non-Consumable, "Ready for Review" status) App code: verified twice independently — product ID, type, and registration are all correct, no bugs found Xcode's local StoreKit Configuration file (fully simulated, no network): confirms my purchase/entitlement code works correctly end-to-end when StoreKit cooperates — so this isn't a code bug What's confirmed failing — identically, across every method I've tried Raw Xcode Debug build, installed directly to a real device TestFlight (Internal Testing) install A fresh Xcode Release-configuration run Same error, same domain, same code, every single time: AppTransaction.shared fetch, receipt refresh, Restore Purchases, and the actual purchase attempt (different code, 3504, but same underlying pattern). The pattern that stands out Everything that's a simple read of the public catalog (what does this app sell, what's the price) works. Everything requiring Apple's servers to process something tied to my specific account's transaction/commerce state (transaction history, an actual purchase) fails. My leading theory This is a brand-new Individual Apple Developer account. The Paid Apps Agreement only went Active 5 days before I started testing this. First-ever IAP product, first-ever real purchase attempt on the account. I'm wondering if this is a propagation/settling delay on Apple's commerce backend that the "Active" UI status doesn't fully reflect — I found a few other forum threads where Apple's own response to error 3504 specifically was to double check the Paid Apps Agreement/tax/banking, even in cases where it already showed as complete. What I've already ruled out App Store submission status — per Apple's TN3186 doc and other DTS-engineer forum replies I found, sandbox purchases shouldn't require app/IAP submission or approval at all A raw Xcode install lacking a "real acquisition record" that TestFlight would have — tested directly, TestFlight failed identically Sandbox tester account misconfiguration — sign-in works fine, tester accounts are valid and usable Where things stand right now Given everything above checked out clean, I went ahead and submitted the app + this IAP for App Review, partly just to see whether that changes anything, and partly because I need to actually ship at some point regardless. If it gets approved and the purchase works for the reviewer, that would at least tell me production is fine even if sandbox stays broken — I can live with that. But if it comes back rejected specifically because the purchase doesn't work, I'm genuinely out of ideas on what else to check from my side.

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.

We're currently having an issue with our app where the review prompt is displaying for the user too often. I know the documentation says that: If the person hasn’t rated or reviewed your app on this device, StoreKit displays the ratings and review request a maximum of three times within a 365-day period. If the person has rated or reviewed your app on this device, StoreKit displays the ratings and review request if the app version is new, and if more than 365 days have passed since the person’s previous review. From this post I can see that there's an updated API that is recommended AppStore.requestReview(in:). Is there a currently known bug with the SKStoreReviewController version that would cause the review prompt to display outside of the limitations? Locally we're seeing a limit of 3 prompts in the same session but a few days later, we get the same 3 prompt limit when it's should have been limited for another year. Does using the AppStore version just fix our issue? Is it actually a different API?

Filed as FB24069273. Sandbox POST /inApps/v1/notifications/test consistently returns 404 {"errorCode":4040007} for our app (Apple ID 6765662617), although GET /v1/apps via the App Store Connect API confirms both subscriptionStatusUrl and subscriptionStatusUrlForSandbox are set (V2). With the same JWT, sandbox POST /inApps/v1/notifications/history returns 200 with an empty history — so the key and app resolve correctly. No organic sandbox notifications have ever been delivered, despite active TestFlight sandbox subscription activity. Exhausted remediations (4040007 persists after each, with 30-60+ minute waits): Re-saving the URLs in the App Store Connect UI (two locales) Deleting and re-adding the Sandbox URL PATCH /v1/apps setting the sandbox URL + version V2 twice, with two different valid endpoints (verified by GET each time) Removing the Sandbox URL entirely to rely on the documented Production fallback Deleting BOTH URLs, waiting a full hour, and re-creating them from scratch Testing with both an App Store Connect team key and a freshly generated In-App Purchase key — identical results Endpoints are publicly reachable (HTTPS, TLS 1.2+, port 443). Production App Store Server API returns 401, which we understand is expected for an app not yet released. This looks like a desync between App Store Connect metadata and the notification delivery registry consulted by the test-notification endpoint. Any help would be appreciated.

I have 2 iOS app products. One can fetch subscription product information normally, while the other fails with the error errorCode 4040004 'App not found' in Sandbox. The App Store Connect backend configuration should be fine, and the subscription code on the app side is the same codebase for both. I really can't find the root cause anymore — if anyone knows what's going on, please point me in the right direction. Also, I'm able to sync/download the StoreKit product configuration file from App Store Connect directly in Xcode, which should also confirm that my App Store Connect backend configuration is correct.