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

I have filed Feedback Assistant report FB24182480 for this issue. On an Apple Watch Series 6 running watchOS 26.6 (23U67), a TestFlight watchOS app can successfully load a non-consumable StoreKit 2 product from Sandbox and display its localized price. However, a subsequent single call to product.purchase() can fail before, or while, the system confirmation sheet is displayed. The app itself remains alive. It receives StoreKit.StoreKitError.systemError (code 1), with an underlying NSCocoaErrorDomain error 4097, consistent with losing the XPC connection to storekitd. The affected run’s private co-sysdiagnose shows this sequence: storekitd starts processing the payment. The Sandbox purchase request returns HTTP 200. AMSPaymentSheetTask begins. The kernel reports that storekitd exceeded its ActiveSoft 5 MB limit and terminates it as the high-water process. The app receives Cocoa error 4097. A later user-initiated retry was handled by a restarted storekitd process and ended with the same result. There are no overlapping product, entitlement, or purchase operations, and the app does not automatically retry purchase(). The issue is intermittent: in other runs on the same Watch, the Sandbox purchase sheet has appeared successfully. This makes it appear to be a system purchase-service lifecycle or memory-management issue rather than a product-configuration or product-loading issue. Environment: Apple Watch Series 6 (Watch6,4) watchOS 26.6 (23U67) TestFlight build StoreKit 2 Sandbox non-consumable IAP One explicit Buy tap per attempt Has anyone seen storekitd being terminated with a high-water reason during a watchOS purchase flow, or found a supported app-side mitigation for the resulting StoreKit error 1 / Cocoa 4097? I have kept the sysdiagnose and recordings private in Feedback Assistant because they contain account, device, and network information.

Hi, We are seeing Apple-hosted Managed Background Assets download failures on macOS 26.6.1 and would appreciate confirmation of whether this is a known issue or a configuration problem. Environment macOS app using Apple-hosted Managed Background Assets Apple Silicon Macs: M1 and M4 App version: 1.0.2 (build 10) App and downloader extension are sandboxed and use the same App Group No ba-serve development URL override is configured: xcrun ba-serve url-override reports that no override is set. Observations On the same M1 Mac: On macOS 26.5.2, Background Assets began transferring an asset pack successfully. The log recorded 136,586,876 bytes received before I manually cancelled the download. After upgrading to macOS 26.6.1, Background Assets reaches manifest resolution and download scheduling, but the asset transfer fails. The macOS 26.6.1 logs show: NSURLErrorDomain -1200 The certificate for this server is invalid / secure connection failed kCFStreamErrorDomainSSL -9816 server closed session with no notification NSURLErrorDomain -3007 Download decoding failed A separate M4 Mac running macOS 26.6.1 also reproduces the issue. One relevant variable: both the working 26.5.2 log and the failing 26.6.1 log show the Background Assets traffic passing through a local HTTP/S proxy at 127.0.0.1:6152. I am now testing a direct route for odr.itunes.apple.com and amp-api.apps.apple.com, but this proxy path was also present in the 26.5.2 transfer that started successfully. The asset pack IDs in the two captured logs are not identical, so this is not a strict same-pack A/B comparison. However, the failure is reproducible for Apple-hosted packs on 26.6.1, while the pre-upgrade log shows a real transfer on the same M1 Mac. Has anyone seen either of these on macOS 26.6 / 26.6.1? NSURLErrorDomain -3007 (Download decoding failed) for Apple-hosted Background Assets TLS error -1200 / kCFStreamErrorDomainSSL -9816 during a Background Assets pack transfer A change in support or behavior for HTTP/S proxy routing of Apple-hosted asset-pack downloads I have filed Feedback Assistant report FB24301118 with the relevant logs and diagnostic attachment. Thanks.