Repository navigation
Roadmap: 1.0 (Foundation Models 26) and 2.0 (Foundation Models 27) #210
Description
Now that @pcuenca and I are back on this, here's the plan:
1.0 — a stable release against the current Foundation Models API in iOS/macOS 26. Before tagging it, I want to tidy up the places where AnyLanguageModel grew beyond what Apple's framework offers, mostly to compensate for early limitations:
- Remove the APIs that are already marked deprecated (Llama passthrough properties, the legacy Gemini
Thinking/ServerTooltypes). - Fix
respond(to:schema:), which currently ignores itsschemaargument. - Make
InstructionsSendable, and close a few other small parity gaps. - Clearly mark our extensions (tool execution delegate, image inputs,
[custom:]options) as extensions.
2.0 — track the Foundation Models changes in iOS/macOS 27. I expect source-breaking changes around session construction, image inputs, and generation options, so that'll be a major version. Availability-gated additions (like #206) can land before then.
If there's something you need in 1.0, please say so here.
Activity
mergesort commentedon Sep 2, 2026
Hey @mattt and @pcuenca, want to start by saying thank you for the great library — I really appreciate it!
Will 2.0 support deployments back to OS 26 as well, or will it be considered a source breaking change that only works with 27+. I'd really appreciate being able to use 2.0 to support my users on both iOS 26/27, while providing access to the new PCC models on iOS 27.
james-333i commentedon Sep 3, 2026
@mattt I've been working on Core AI this week and was able to get Core AI models running independently of AnyLanguageModel for things like Stable Audio audio generation (I handle audio and CoreML image generation independent of this library in my app). It works well.
As a follow on to that, I have been prototyping a Core AI backend for AnyLanguageModel against apple/coreai-models, structured the same way as the MLX and Llama traits. The new LanguageModelSession(model:) construction in Foundation Models 27 makes it a natural fit for the 2.0 direction described here. Two packaging issues in Apple's package are worth knowing about before it lands on anyone's roadmap.
First, the package declares platforms: [.macOS("27.0"), .iOS("27.0")] and its sources carry no availability annotations. Any consumer with a lower deployment floor fails SPM validation, which rules out AnyLanguageModel at iOS 17 and any shipping app with an existing user base. I created a local patch that lowers the floor and adds 241 mechanical @available(macOS 27.0, iOS 27.0, *) annotations to top-level declarations. The diff is additions only, and I plan to offer it upstream to Apple.
Second, CoreAI.framework does not exist in the iOS 27 simulator SDK, so the package cannot compile for simulator destinations at all. That is apple/coreai-models#49. The patch wraps the sources in #if canImport(CoreAI) so the module compiles empty for the simulator and normally for device and macOS.
With those two changes the backend drops in cleanly behind a CoreAI trait and uses exported bundles through the same Foundation Models session machinery as SystemLanguageModel. One operational note: iOS static bundles need to be AOT-compiled to .aimodelc ahead of time (coreai-build compile); loading the raw .aimodel IR triggers an on-device compile that takes many minutes, so precompiled artifacts are the only practical distribution for iOS. It compiles end to end and streaming chat is working on device.
Happy to send a PR with the local work I have completed (just keep in mind that it depends on a fork of coreai-models for now).
james-333i commentedon Sep 4, 2026
@mattt Noting I also got Apple PCC working and will share a PR for it. It requires requesting access to the entitlement and max 2 million users on an app. After that, adding the entitlement to the app it works well.
mattt commentedon Sep 4, 2026
Hi @mergesort. Thanks! Yes, that's the intent: 2.0 will keep the iOS 26 floor and gate the OS 27 features (Private Cloud Compute, image attachments, and so on) behind availability checks, the same way #206 does today. "Source-breaking" is about API shape, not deployment target. If that turns out to be impractical for some piece, I'll say so here before it lands.
mattt commentedon Sep 4, 2026
@james-333i That's great work, and thanks for the packaging notes. I'd be glad to look at the backend as a draft PR so we can see the shape, with the understanding that it can't merge while it depends on a fork of apple/coreai-models. If you offer those two fixes upstream, link them here and we can track when it becomes mergeable.