[CoreAI] Add the Core AI SDK Swift and Objective-C bridge

[metascroy]

Adds the private bridge between ExecuTorch's Objective-C++ code and the Swift CoreAI framework, and packages it for CMake consumers. No ExecuTorch delegate yet; a later PR wires this into CoreAIBackend.

• runtime/ETCoreAIBridge.h: Objective-C protocols for model acquisition, prepared models, sessions and tensor transfer, plus availability, device architecture and loader factory entry points.
• runtime/ETCoreAIModel.swift (module CoreAIBridge):
  • Restore models from bookmarks, specialize source bundles with the persistent default SDK cache, bind named functions with ordered inputs/outputs, and evict cache entries.
  • Asynchronous SDK calls run in detached tasks and report through completion blocks. Only an SDK nil result is a cache miss; thrown errors keep their underlying cause.
  • Inputs are borrowed from caller storage through Core AI raw views; outputs use one memcpy for dense row-major arrays and strided copies otherwise.
• runtime/ETCoreAITensor.mm, runtime/coreai_bridge.mm: tensor wrappers and C entry points, built as the private coreai_bridge_obj object library so the delegate can absorb them and host tests can substitute a fake bridge.
• Build (backends/apple/coreai/CMakeLists.txt): requires CMake 3.31 and Ninja/Xcode, keeps ExecuTorch's numeric preprocessor definitions away from swiftc, applies an OS 27 minimum only to Core AI targets, and builds coreai_swift. cmake/PublishSwiftHeader.cmake publishes the generated header for Xcode.
• Tests: runtime/test/SwiftBridgeTests.swift is built with the bridge sources into the coreai_swift_bridge_test XCTest bundle (Ninja, macOS) and run by CTest under xcrun xctest. The invalid-URL case uses a non-file coreai-test: URL.
• README: "SDK Bridge" and the build requirements in "Building".
• Changes outside backends/apple/coreai are CMake and CI only, and only take effect when EXECUTORCH_BUILD_COREAI=ON:
  • tools/cmake/ExecuTorchCoreAIDependencies.cmake (new): resolves Foundation, CoreAI and Swift runtime link paths from the consumer's SDK; fails configuration for SDKs older than 27.
  • CMakeLists.txt: install that file into the package config.
  • tools/cmake/preset/default.cmake: note the SDK 27 requirement.
  • .github/workflows/coreai.yml: also trigger on changes to ExecuTorchCoreAIDependencies.cmake.

Stack: 5 of 9, based on #23390. Review only this PR's commit. Next: #23392.

Test plan: built locally for macOS 27.0; ctest -N lists coreai_host_test and coreai_swift_bridge_test, which the Core AI workflow runs on the macOS 27 runner. The XCTest bundle links CoreAI, so it only runs there (first CI run of it). lintrunner is clean.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/23391

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure, 1 Unclassified Failure

As of commit 756e906 with merge base 0b3d26d ():

NEW FAILURE - The following job has failed:

• Apple / build-benchmark-app / macos-job (gh)
  RuntimeError: Command bash /Users/runner/work/_temp/exec_script failed with exit code 128

UNCLASSIFIED FAILURE - DrCI could not classify the following job because the workflow did not run on the merge base. The failure may be pre-existing on trunk or introduced by this PR:

• Test ROCm AOTI / unittest-rocm-gfx950-rocm7.2 / linux-job (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  backends/cuda/tests/test_sdpa_splitk_replacement.py::TestUnsupportedSDPAStaysWithRegularLowering::test_float_mask_is_not_replaced

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[metascroy]

@claude review this PR

[claude]

Claude finished @metascroy's task in 2m 27s —— View job

---

This PR adds the Swift and Objective-C bridge to the Core AI SDK, plus the CMake packaging for it. The main problem is that the runtime availability API can't do its job: the bridge objects are built with an OS 27 minimum and CoreAI is linked strongly, so ETCoreAIIsAvailable() can only ever return YES.

Detailed review

PR Review: #23391

Summary

This PR adds the private Swift and Objective-C bridge to the Core AI SDK and its CMake/package plumbing. The tensor copy, overflow checks and error mapping look correct. The issues below are mostly about how the bridge links and how its contract is documented.

API Design

• ETCoreAIIsAvailable() and the @available checks are always true at compile time. See runtime/coreai_bridge.mm:13-25, together with coreai_require_os27(coreai_bridge_obj) (CMakeLists.txt) and INTERFACE_LINK_LIBRARIES "${foundation};${coreai}" (tools/cmake/ExecuTorchCoreAIDependencies.cmake).
  • coreai_bridge.mm and ETCoreAIModel.swift are compiled with a minimum of 27.0, so @available(macOS 27.0, iOS 27.0, *) is a constant YES.
  • CoreAI is linked as a full framework path, and Swift's import CoreAI autolinks it too. Both produce a strong LC_LOAD_DYLIB.
  • The PR says it "applies an OS 27 minimum only to Core AI targets", which implies the host app can target an older OS. If it does, dyld will fail at launch on an OS 26 device before ETCoreAIIsAvailable() ever runs.
  • ETCoreAICreateModelLoader() has no availability guard either. It only compiles because the minimum is 27.
  • Fix, either:
    • weak-link CoreAI and the Swift module (-weak_framework CoreAI / LINKER:-weak_framework,CoreAI) and build the bridge at the host's deployment target, so the checks become real; or
    • document that any binary containing the Core AI backend needs OS 27, and remove ETCoreAIIsAvailable since it can't return NO.
• ETCoreAISession doesn't say which thread its completion runs on. See runtime/ETCoreAIBridge.h:49-55 and ETCoreAIModel.swift:304-316.
  • executeInputs calls completion synchronously on the caller's thread when validation fails (input count, shape or dtype). On success it calls it from a detached task.
  • loadFunctionNamed documents "May complete synchronously". ETCoreAISession should state the same, so the delegate in the next PR doesn't assume completion always happens off the calling thread (for example, by taking a lock it already holds).

Thread Safety

• Waiting synchronously on a Task.detached can deadlock under Swift concurrency. See ETCoreAIModel.swift:60 ("ExecuTorch waits synchronously") and :318.
  • If an app calls ExecuTorch execute from Swift async code, the delegate blocks a thread from the cooperative pool while it waits for the detached task. That task needs a thread from the same fixed-size pool.
  • With enough concurrent inferences, this starves the pool or deadlocks.
  • This isn't triggered in this PR, but it's part of the bridge's design. Either document that execute must not run on a Swift-concurrency thread, or run the SDK call through something that doesn't depend on the cooperative pool. Low confidence on whether that is practical with the CoreAI SDK; flagging it for discussion.

Infrastructure

• The installed coreai_swift can't link on its own. See CMakeLists.txt (install(TARGETS coreai_swift EXPORT ExecuTorchTargets ...)).
  • libcoreai_swift.a references ETCoreAIErrorDomain, ETCoreAIInputTensor and ETCoreAITensor. These are defined in ETCoreAITensor.mm, which is only in coreai_bridge_obj, and that target isn't installed.
  • Exporting it now gives package consumers an archive with unresolved symbols.
  • Suggest moving the install into the delegate PR, where these objects are absorbed into coreai_backend.
• The new CMake checks also block the existing ObjC++ host test. See CMakeLists.txt:11-13 and :69-74.
  • The CMake ≥3.31, Ninja/Xcode and Darwin/iOS checks run unconditionally.
  • So coreai_host_test, which needs no Swift, can no longer be configured with Makefiles or an older CMake.
  • If that's intended, fine. Otherwise, put the Swift-only requirements behind the Swift section.

Testing

• No test covers CoreAISwiftSession, the most intricate logic in the file. See ETCoreAIModel.swift:244-351. Untested paths:

  • the ordered-binding validation (duplicate names, name-set mismatch, stateful functions)
  • input dtype/shape checks against descriptors
  • output reordering by outputNames
  • the synchronous-failure completion path

  The XCTest bundle already runs on the macOS 27 runner. A small checked-in test model (or one generated in the test) that goes through specializeModel → loadFunctionNamed → executeInputs would cover the real SDK path, which none of the current tests reach. testHitPinsPreparedModelThroughCompletion only calls the fake ProtocolPreparedModel.

Code Quality

• ETCoreAIModel.swift:25-39: Completion<Value> and AcquisitionCompletion are the same unchecked-Sendable box. One generic box (holding any closure) would do for both, and evictModel's Completion<Void> adapter could go.
• ETCoreAIModel.swift:259-264: inputNames.count == descriptor.inputCount and descriptor.inputNames.count == inputNames.count check the same thing. With the Set equality and uniqueness checks, one count check per side is enough. The same applies to outputs.

Recommendation

Needs Discussion: the main question is whether the bridge should be weak-linked so that ETCoreAIIsAvailable works, or whether OS 27 is required for the whole binary. The answer decides the linking and the availability API before the delegate PR builds on them. The remaining items are small.