Hello, We are seeing what appears to be a regression in the Core ML multifunction ML Program loading path on macOS 27.0. A compiled multifunction ML Program is correctly recognized by MLModelAsset and MLModelStructure, but loading either named function through MLModel fails with an error claiming that the model is not an ML Program. Environment macOS 27.0 Build: 26A428 Apple silicon Mac BABANE 1.0.4, build 16 Application built with the macOS 26.5 SDK Reproduces both inside and outside App Sandbox Approximately 98 GiB of disk space is available Public reproduction BABANE is available from the Mac App Store: BABANE on the App Store Apple engineers can reproduce the issue without receiving a separate model archive: Install BABANE from the App Store on macOS 27.0. Download either available translation model in the app. The model is delivered using Apple-Hosted Background Assets. Trigger model loading by starting a translation. Core ML fails while loading the first named function. The downloadable models are approximately 1.9 GB, so the App Store build is the most practical complete reproduction environment. Model structure The model is a specification-version-9 ML Program containing two functions: infer prefill Core ML correctly recognizes both functions: let asset = try MLModelAsset(url: compiledModelURL) let functionNames = try await asset.functionNames print(functionNames) Output: ["infer", "prefill"] MLModelStructure also returns a .program structure containing both functions. Loading code import CoreML func loadModel( at url: URL, functionName: String? ) throws -> MLModel { let configuration = MLModelConfiguration() configuration.computeUnits = .cpuAndNeuralEngine configuration.functionName = functionName return try MLModel( contentsOf: url, configuration: configuration ) } Loading either function: try loadModel(at: compiledModelURL, functionName: "infer") or: try loadModel(at: compiledModelURL, functionName: "prefill") fails with: `MLModelConfiguration`'s `.functionName` property must be `nil` unless the model type is ML Program. This contradicts the results returned by MLModelAsset and MLModelStructure. Setting functionName to nil is not a workaround. It fails with: This MLModel doesn't support the multi-function description syntax. Unified logging Immediately before the public Core ML error, unified logging reports: E5RT encountered an STL exception. E5RT: <private> (11) Core ML then returns the misleading functionName error. Tests performed We tested: functionName = "infer" functionName = "prefill" functionName = nil .cpuOnly .cpuAndGPU .cpuAndNeuralEngine .all App Sandbox application Non-sandboxed command-line executable Existing .mlmodelc A newly compiled .mlmodelc produced on macOS 27 All named-function combinations fail in the same way. The failure is independent of compute-unit selection and App Sandbox. The source package recompiles successfully on macOS 27, but the newly compiled model still fails to load. As an additional control: A system-provided multifunction ML Program exhibits the same loading failure on this installation. A single-function Core ML model loads successfully. This appears specific to the multifunction model loading path. Documentation The current Core ML documentation still describes MLModelAsset.functionNames as the way to discover functions and MLModelConfiguration.functionName as the way to select one: MLModelConfiguration.functionName MLModelAsset.functionNames We could not find any macOS 27 documentation or release-note entry stating that this behavior changed, that named functions now require a different loading API, or that a new entitlement is required. We found some potentially related reports: Core ML loading crash on macOS 27.0 build 26A428 Historical multifunction model loading crash Core ML/E5RT AOT loading regression with an Apple DTS response None of these reports documents the exact functionName failure described here. Expected behavior A model recognized as a multifunction ML Program should load when MLModelConfiguration.functionName is set to one of the names returned by MLModelAsset.functionNames. Actual behavior MLModel rejects the named function and incorrectly reports that the model is not an ML Program. Questions Is this a known macOS 27.0 regression in the Core ML multifunction loading path? Does MLModelConfiguration.functionName still accept names returned by MLModelAsset.functionNames on macOS 27? Is there a new required loading API, deployment target, SDK, entitlement, or model-packaging rule? Is there a supported workaround other than exporting each function as a separate model? Which diagnostics should we attach to a Feedback Assistant report besides the reproducer, unified logs, sysdiagnose, and exact OS/Xcode builds? Thank you.

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.