Swift package fails to compile for the iOS Simulator (no such module 'CoreAI')

[KodaKoder]

Problem

CoreAI.framework ships only in the device SDK (it's the Neural Engine inference runtime) and is absent from the iOS Simulator SDK. The library targets currently guard only the macOS-x86_64 case (#if !((os(macOS) || targetEnvironment(macCatalyst)) && arch(x86_64))), so every source that import CoreAI fails to compile for an iOS Simulator destination.

Because Xcode pre-builds a referenced package for the active destination, any app that links a CoreAI product (e.g. CoreAILM) on device can no longer build its Simulator slice — it fails with no such module 'CoreAI'.

Steps to reproduce

1. Add the package https://github.com/apple/coreai-models to an app target that links CoreAILM (or any CoreAI* library).
2. Select an iOS Simulator destination (e.g. iPhone 17, iOS 27.0).
3. Build.

→ Fails with no such module 'CoreAI' across CoreAILanguageModels / CoreAIDiffusionPipeline / CoreAIImageSegmenter / CoreAIObjectDetector.

Environment: Xcode 27.0 beta · iPhoneSimulator 27.0 SDK · iOS 27.0 deployment.

Proposed fix (ready & verified)

Guard the CoreAI-dependent sources behind #if canImport(CoreAI) — 27 files (every file that imports CoreAI, plus 4 that reference CoreAI-typed symbols: CoreAIRunner, CoreAILanguageModel, PipelineDescriptor, ImageSegmenter). On device canImport(CoreAI) is true and everything compiles unchanged; on the Simulator the CoreAI inference path compiles out (it can't run without the Neural Engine anyway). Purely additive: +54 / −0.

Verified: CoreAILM, CoreAIDiffusion, CoreAISegmentation and CoreAIObjectDetection all build for generic/platform=iOS Simulator (iPhoneSimulator 27.0 SDK).

Branch / diff:
main...KodaKoder:coreai-models:simulator-canimport-guard

I couldn't open a PR directly — PR creation on this repository is currently limited to collaborators. Happy to open one if a maintainer lifts the restriction or wants me to.

Apple Feedback

Also filed as Apple Feedback FB23189921.

[stikves]

I don't think #if canImport(CoreAI) is a solution, as the repository is specifically using Core AI for all inference purposes. It would basically make all operations into no-op

As for the underlying Simulator issue, thanks for bringing this up.

[KodaKoder]

Thanks for taking a look! To clarify the goal: this isn't about running inference on the Simulator (impossible without the ANE) — it's so downstream consumers that link a CoreAI product (e.g. CoreAILM) on device can still compile their Simulator slice. Today the package fails to compile for any iOS Simulator destination (no such module 'CoreAI'), which breaks those apps' Simulator builds entirely.

On the no-op point: the CoreAI-typed API (NDArray, AIModel, …) can't be present on the Simulator at all, since CoreAI.framework is absent from the Simulator SDK. So the realistic options are (a) compile it out under #if canImport(CoreAI) as in the branch, or (b) a separate Simulator-only API surface that throws a clear "unavailable on Simulator" error — a much larger change. Happy to go whichever way you prefer; the ask is just that the package becomes Simulator-buildable so consumers aren't blocked. Repro + a verified branch are linked in the issue.

[Bersaelor]

I just ran into the same issue too, as far as I understand it it makes it really hard to work with SwiftUI Previews and by extension use agentic coding in Xcode 27, as the agents rely on quick iteration of previews.

All I could do, was to separate all CoreAI functionality into a separate target (called it DiffusionKit), and weak link that target into my app target, so I can use Previews while also being able to test Coreai on device.
When I do this though, I get a warning

~/Source/CoreAITestApp/DiffusionKit/DiffusionEngine.swift:1:8 Module 'CoreAIDiffusionPipeline' was not compiled with library evolution support; using it means binary compatibility for 'DiffusionKit' can't be guaranteed

I'm not sure whether putting DiffusionKit into a static library will cause problems with background asset importing and or the binary compatibility mentioned above.