{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/huggingface-co/2025-11-20-introducing-anylanguagemodel-one-api-for-local-and-remote/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "LLMs have become essential tools for building software. But for Apple developers, integrating them remains unnecessarily painful.\n\nDevelopers building AI-powered apps typically take a hybrid approach, adopting some combination of:\n\n- Local models using Core ML or MLX for privacy and offline capability\n- Cloud providers like OpenAI or Anthropic for frontier capabilities\n- Apple's Foundation Models as a system-level fallback\n\nEach comes with different APIs, different requirements, different integration patterns. It's a lot, and it adds up quickly. When I interviewed developers about building AI-powered apps, friction with model integration came up immediately. One developer put it bluntly:\n\n> I thought I'd quickly use the demo for a test and maybe a quick and dirty build but instead wasted so much time. Drove me nuts.\n\nThe cost to experiment is high, which discourages developers from discovering that local, open-source models might actually work great for their use case.\n\nToday we're announcing [AnyLanguageModel](https://github.com/mattt/AnyLanguageModel), a Swift package that provides a drop-in replacement for Apple's Foundation Models framework with support for multiple model providers. Our goal is to reduce the friction of working with LLMs on Apple platforms and make it easier to adopt open-source models that run locally.\n\n## The Solution\n\nThe core idea is simple: Swap your `import` statement, keep the same API.\n\n```diff\n- import FoundationModels\n+ import AnyLanguageModel\n```\n\nHere's what that looks like in practice. Start with Apple's built-in model:\n\n```swift\nlet model = SystemLanguageModel.default\nlet session = LanguageModelSession(model: model)\n\nlet response = try await session.respond(to: \"Explain quantum computing in one sentence\")\nprint(response.content)\n```\n\nNow try an open-source model running locally via [MLX](https://huggingface.co/docs/hub/en/mlx):\n\n```swift\nlet model = MLXLanguageModel(modelId: \"mlx-community/Qwen3-4B-4bit\")\nlet session = LanguageModelSession(model: model)\n\nlet response = try await session.respond(to: \"Explain quantum computing in one sentence\")\nprint(response.content)\n```\n\nAnyLanguageModel supports a range of providers:\n\n- **Apple Foundation Models**: Native integration with Apple's system model (macOS 26+ / iOS 26+)\n- **Core ML**: Run converted models with Neural Engine acceleration\n- **MLX**: Run quantized models efficiently on Apple Silicon\n- **llama.cpp**: Load GGUF models via the llama.cpp backend\n- **Ollama**: Connect to locally-served models via Ollama's HTTP API\n- **OpenAI, Anthropic, Google Gemini**: Cloud providers for comparison and fallback\n- **Hugging Face Inference Providers**: Hundreds of cloud models powered by world-class [inference providers](https://huggingface.co/docs/inference-providers/en/index).\n\nThe focus is on local models that you can download from the [Hugging Face Hub](https://huggingface.co/docs/hub/). Cloud providers are included to lower the barrier to getting started and to provide a migration path. Make it work, then make it right.\n\n## Why Foundation Models as the Base API\n\nWhen designing AnyLanguageModel, we faced a choice: create a new abstraction that tries to capture everything, or build on an existing API. We chose the latter, using [Apple's Foundation Models framework](https://developer.apple.com/documentation/FoundationModels) as the template.\n\nThis might seem counterintuitive. Why tie ourselves to Apple's choices? A few reasons:\n\n1. Foundation Models is genuinely well-designed. It leverages Swift features like macros for an ergonomic developer experience, and its abstractions around sessions, tools, and generation map well to how LLMs actually work.\n\n2. It's intentionally limited. Foundation Models represents something like a lowest common denominator for language model capabilities. Rather than seeing this as a weakness, we treat it as a stable foundation (*hyuk hyuk*). Every Swift developer targeting Apple platforms will encounter this API, so building on it directly means less conceptual overhead.\n\n3. It keeps us grounded. Each additional layer of abstraction takes you further from the problem you're actually solving. Abstractions are powerful, but stack too many and they become a problem in themselves.\n\nThe result is that switching between providers requires minimal code changes, and the core abstractions remain clean and predictable.\n\n## Package Traits: Include Only What You Need\n\nOne challenge with multi-backend libraries is dependency bloat. If you only want to run MLX models, you shouldn't have to pull in llama.cpp and all *its* dependencies.\n\nAnyLanguageModel uses Swift 6.1 package traits to solve this. You opt in to only the backends you need:\n\n```swift\ndependencies: [\n .package(\n url: \"https://github.com/mattt/AnyLanguageModel.git\",\n from: \"0.4.0\",\n traits: [\"MLX\"] // Pull in MLX dependencies only\n )\n]\n```\n\nAvailable traits include `CoreML`, `MLX`, and `Llama` (for llama.cpp / [llama.swift](https://github.com/mattt/llama.swift)). By default, no heavy dependencies are included. You get the base API plus cloud providers, which only require standard `URLSession` networking.\n\nFor Xcode projects (which don't yet support trait declarations directly), you can create a small internal Swift package that depends on AnyLanguageModel with the traits you need, then add that package as a local dependency. The [README](https://github.com/mattt/AnyLanguageModel#using-traits-in-xcode-projects) has detailed instructions.\n\n## Image Support (and API Design Trade-offs)\n\n[Vision-language models](https://huggingface.co/blog/vlms-2025) are incredibly capable and widely used. They can describe images, extract text from screenshots, analyze charts, and answer questions about visual content. Unfortunately, Apple's Foundation Models framework doesn't currently support sending images with prompts.\n\nBuilding on an existing API means accepting its constraints. Apple will likely add image support in a future release (iOS 27, perhaps?), but vision-language models are too useful to wait for. So we've extended beyond what Foundation Models offers today.\n\nHere's an example sending an image to Claude:\n\n```swift\nlet model = AnthropicLanguageModel(\n apiKey: ProcessInfo.processInfo.environment[\"ANTHROPIC_API_KEY\"]!,\n model: \"claude-sonnet-4-5-20250929\"\n)\n\nlet session = LanguageModelSession(model: model)\nlet response = try await session.respond(\n to: \"What's in this image?\",\n image: .init(url: URL(fileURLWithPath: \"/path/to/image.png\"))\n)\n```\n\nWe're taking a calculated risk here; we might design something that conflicts with Apple's eventual implementation. But that's what deprecation warnings are for. Sometimes you have to write the API for the framework that doesn't exist yet.\n\n## Try It Out: chat-ui-swift\n\n[![Screenshot of chat-ui-swift app](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/any-swift-llm/chat-ui-swift.png)](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/any-swift-llm/chat-ui-swift.png)\n\nTo see AnyLanguageModel in action, check out [chat-ui-swift](https://github.com/mattt/chat-ui-swift), a SwiftUI chat application that demonstrates the library's capabilities.\n\nThe app includes:\n\n- Apple Intelligence integration via Foundation Models (macOS 26+)\n- Hugging Face OAuth authentication for accessing gated models\n- Streaming responses\n- Chat persistence\n\nIt's meant as a starting point: Fork it, extend it, swap in different models. See how the pieces fit together and adapt it to your needs.\n\n## What's Next\n\nAnyLanguageModel is currently pre-1.0. The core API is stable, but we're actively working on bringing the full feature set of Foundation Models to all adapters, namely:\n\n- **Tool calling** across all providers\n- **MCP integration** for tools and elicitations\n- **Guided generation** for structured outputs\n- Performance optimizations for local inference\n\nThis library is the first step toward something larger. A unified inference API provides the scaffolding needed to build seamless agentic workflows on Apple platforms β€” applications where models can use tools, access system resources, and accomplish complex tasks. More on that soon. 🀫\n\n## Get Involved\n\nWe'd love your help making this better:\n\n- **Try it out** β€” Build something, kick the tires\n- **Share your experiences** β€” What works? What's frustrating? We want to hear about the challenges you face integrating AI into your apps\n- **Open issues** β€” Feature requests, bug reports, questions\n- **Contribute** β€” PRs are welcome\n\n## Links\n\n- [AnyLanguageModel on GitHub](https://github.com/mattt/AnyLanguageModel)\n- [chat-ui-swift on GitHub](https://github.com/mattt/chat-ui-swift)\n\nWe're excited to see what you build 🦾\n", "authors": [], "captured_at": "2026-10-04T12:50:30.804479567+00:00", "category": "ai", "content_html": "

LLMs have become essential tools for building software. But for Apple developers, integrating them remains unnecessarily painful.

\n

Developers building AI-powered apps typically take a hybrid approach, adopting some combination of:

\n\n

Each comes with different APIs, different requirements, different integration patterns. It's a lot, and it adds up quickly. When I interviewed developers about building AI-powered apps, friction with model integration came up immediately. One developer put it bluntly:

\n
\n

I thought I'd quickly use the demo for a test and maybe a quick and dirty build but instead wasted so much time. Drove me nuts.

\n
\n

The cost to experiment is high, which discourages developers from discovering that local, open-source models might actually work great for their use case.

\n

Today we're announcing AnyLanguageModel, a Swift package that provides a drop-in replacement for Apple's Foundation Models framework with support for multiple model providers. Our goal is to reduce the friction of working with LLMs on Apple platforms and make it easier to adopt open-source models that run locally.

\n

The Solution

\n

The core idea is simple: Swap your import statement, keep the same API.

\n
- import FoundationModels\n+ import AnyLanguageModel\n
\n

Here's what that looks like in practice. Start with Apple's built-in model:

\n
let model = SystemLanguageModel.default\nlet session = LanguageModelSession(model: model)\n\nlet response = try await session.respond(to: "Explain quantum computing in one sentence")\nprint(response.content)\n
\n

Now try an open-source model running locally via MLX:

\n
let model = MLXLanguageModel(modelId: "mlx-community/Qwen3-4B-4bit")\nlet session = LanguageModelSession(model: model)\n\nlet response = try await session.respond(to: "Explain quantum computing in one sentence")\nprint(response.content)\n
\n

AnyLanguageModel supports a range of providers:

\n\n

The focus is on local models that you can download from the Hugging Face Hub. Cloud providers are included to lower the barrier to getting started and to provide a migration path. Make it work, then make it right.

\n

Why Foundation Models as the Base API

\n

When designing AnyLanguageModel, we faced a choice: create a new abstraction that tries to capture everything, or build on an existing API. We chose the latter, using Apple's Foundation Models framework as the template.

\n

This might seem counterintuitive. Why tie ourselves to Apple's choices? A few reasons:

\n
    \n
  1. \n

    Foundation Models is genuinely well-designed. It leverages Swift features like macros for an ergonomic developer experience, and its abstractions around sessions, tools, and generation map well to how LLMs actually work.

    \n
    2. \n
  2. \n

    It's intentionally limited. Foundation Models represents something like a lowest common denominator for language model capabilities. Rather than seeing this as a weakness, we treat it as a stable foundation (hyuk hyuk). Every Swift developer targeting Apple platforms will encounter this API, so building on it directly means less conceptual overhead.

    \n
    3. \n
  3. \n

    It keeps us grounded. Each additional layer of abstraction takes you further from the problem you're actually solving. Abstractions are powerful, but stack too many and they become a problem in themselves.

    \n
    4. \n
\n

The result is that switching between providers requires minimal code changes, and the core abstractions remain clean and predictable.

\n

Package Traits: Include Only What You Need

\n

One challenge with multi-backend libraries is dependency bloat. If you only want to run MLX models, you shouldn't have to pull in llama.cpp and all its dependencies.

\n

AnyLanguageModel uses Swift 6.1 package traits to solve this. You opt in to only the backends you need:

\n
dependencies: [\n    .package(\n        url: "https://github.com/mattt/AnyLanguageModel.git",\n        from: "0.4.0",\n        traits: ["MLX"]  // Pull in MLX dependencies only\n    )\n]\n
\n

Available traits include CoreML, MLX, and Llama (for llama.cpp / llama.swift). By default, no heavy dependencies are included. You get the base API plus cloud providers, which only require standard URLSession networking.

\n

For Xcode projects (which don't yet support trait declarations directly), you can create a small internal Swift package that depends on AnyLanguageModel with the traits you need, then add that package as a local dependency. The README has detailed instructions.

\n

Image Support (and API Design Trade-offs)

\n

Vision-language models are incredibly capable and widely used. They can describe images, extract text from screenshots, analyze charts, and answer questions about visual content. Unfortunately, Apple's Foundation Models framework doesn't currently support sending images with prompts.

\n

Building on an existing API means accepting its constraints. Apple will likely add image support in a future release (iOS 27, perhaps?), but vision-language models are too useful to wait for. So we've extended beyond what Foundation Models offers today.

\n

Here's an example sending an image to Claude:

\n
let model = AnthropicLanguageModel(\n    apiKey: ProcessInfo.processInfo.environment["ANTHROPIC_API_KEY"]!,\n    model: "claude-sonnet-4-5-20250929"\n)\n\nlet session = LanguageModelSession(model: model)\nlet response = try await session.respond(\n    to: "What's in this image?",\n    image: .init(url: URL(fileURLWithPath: "/path/to/image.png"))\n)\n
\n

We're taking a calculated risk here; we might design something that conflicts with Apple's eventual implementation. But that's what deprecation warnings are for. Sometimes you have to write the API for the framework that doesn't exist yet.

\n

Try It Out: chat-ui-swift

\n

\"Screenshot

\n

To see AnyLanguageModel in action, check out chat-ui-swift, a SwiftUI chat application that demonstrates the library's capabilities.

\n

The app includes:

\n\n

It's meant as a starting point: Fork it, extend it, swap in different models. See how the pieces fit together and adapt it to your needs.

\n

What's Next

\n

AnyLanguageModel is currently pre-1.0. The core API is stable, but we're actively working on bringing the full feature set of Foundation Models to all adapters, namely:

\n\n

This library is the first step toward something larger. A unified inference API provides the scaffolding needed to build seamless agentic workflows on Apple platforms β€” applications where models can use tools, access system resources, and accomplish complex tasks. More on that soon. 🀫

\n

Get Involved

\n

We'd love your help making this better:

\n\n

Links

\n\n

We're excited to see what you build 🦾

\n", "content_markdown": "LLMs have become essential tools for building software. But for Apple developers, integrating them remains unnecessarily painful.\n\nDevelopers building AI-powered apps typically take a hybrid approach, adopting some combination of:\n\n- Local models using Core ML or MLX for privacy and offline capability\n- Cloud providers like OpenAI or Anthropic for frontier capabilities\n- Apple's Foundation Models as a system-level fallback\n\nEach comes with different APIs, different requirements, different integration patterns. It's a lot, and it adds up quickly. When I interviewed developers about building AI-powered apps, friction with model integration came up immediately. One developer put it bluntly:\n\n> I thought I'd quickly use the demo for a test and maybe a quick and dirty build but instead wasted so much time. Drove me nuts.\n\nThe cost to experiment is high, which discourages developers from discovering that local, open-source models might actually work great for their use case.\n\nToday we're announcing [AnyLanguageModel](https://github.com/mattt/AnyLanguageModel), a Swift package that provides a drop-in replacement for Apple's Foundation Models framework with support for multiple model providers. Our goal is to reduce the friction of working with LLMs on Apple platforms and make it easier to adopt open-source models that run locally.\n\n## The Solution\n\nThe core idea is simple: Swap your `import` statement, keep the same API.\n\n```diff\n- import FoundationModels\n+ import AnyLanguageModel\n```\n\nHere's what that looks like in practice. Start with Apple's built-in model:\n\n```swift\nlet model = SystemLanguageModel.default\nlet session = LanguageModelSession(model: model)\n\nlet response = try await session.respond(to: \"Explain quantum computing in one sentence\")\nprint(response.content)\n```\n\nNow try an open-source model running locally via [MLX](https://huggingface.co/docs/hub/en/mlx):\n\n```swift\nlet model = MLXLanguageModel(modelId: \"mlx-community/Qwen3-4B-4bit\")\nlet session = LanguageModelSession(model: model)\n\nlet response = try await session.respond(to: \"Explain quantum computing in one sentence\")\nprint(response.content)\n```\n\nAnyLanguageModel supports a range of providers:\n\n- **Apple Foundation Models**: Native integration with Apple's system model (macOS 26+ / iOS 26+)\n- **Core ML**: Run converted models with Neural Engine acceleration\n- **MLX**: Run quantized models efficiently on Apple Silicon\n- **llama.cpp**: Load GGUF models via the llama.cpp backend\n- **Ollama**: Connect to locally-served models via Ollama's HTTP API\n- **OpenAI, Anthropic, Google Gemini**: Cloud providers for comparison and fallback\n- **Hugging Face Inference Providers**: Hundreds of cloud models powered by world-class [inference providers](https://huggingface.co/docs/inference-providers/en/index).\n\nThe focus is on local models that you can download from the [Hugging Face Hub](https://huggingface.co/docs/hub/). Cloud providers are included to lower the barrier to getting started and to provide a migration path. Make it work, then make it right.\n\n## Why Foundation Models as the Base API\n\nWhen designing AnyLanguageModel, we faced a choice: create a new abstraction that tries to capture everything, or build on an existing API. We chose the latter, using [Apple's Foundation Models framework](https://developer.apple.com/documentation/FoundationModels) as the template.\n\nThis might seem counterintuitive. Why tie ourselves to Apple's choices? A few reasons:\n\n1. Foundation Models is genuinely well-designed. It leverages Swift features like macros for an ergonomic developer experience, and its abstractions around sessions, tools, and generation map well to how LLMs actually work.\n\n2. It's intentionally limited. Foundation Models represents something like a lowest common denominator for language model capabilities. Rather than seeing this as a weakness, we treat it as a stable foundation (*hyuk hyuk*). Every Swift developer targeting Apple platforms will encounter this API, so building on it directly means less conceptual overhead.\n\n3. It keeps us grounded. Each additional layer of abstraction takes you further from the problem you're actually solving. Abstractions are powerful, but stack too many and they become a problem in themselves.\n\nThe result is that switching between providers requires minimal code changes, and the core abstractions remain clean and predictable.\n\n## Package Traits: Include Only What You Need\n\nOne challenge with multi-backend libraries is dependency bloat. If you only want to run MLX models, you shouldn't have to pull in llama.cpp and all *its* dependencies.\n\nAnyLanguageModel uses Swift 6.1 package traits to solve this. You opt in to only the backends you need:\n\n```swift\ndependencies: [\n .package(\n url: \"https://github.com/mattt/AnyLanguageModel.git\",\n from: \"0.4.0\",\n traits: [\"MLX\"] // Pull in MLX dependencies only\n )\n]\n```\n\nAvailable traits include `CoreML`, `MLX`, and `Llama` (for llama.cpp / [llama.swift](https://github.com/mattt/llama.swift)). By default, no heavy dependencies are included. You get the base API plus cloud providers, which only require standard `URLSession` networking.\n\nFor Xcode projects (which don't yet support trait declarations directly), you can create a small internal Swift package that depends on AnyLanguageModel with the traits you need, then add that package as a local dependency. The [README](https://github.com/mattt/AnyLanguageModel#using-traits-in-xcode-projects) has detailed instructions.\n\n## Image Support (and API Design Trade-offs)\n\n[Vision-language models](https://huggingface.co/blog/vlms-2025) are incredibly capable and widely used. They can describe images, extract text from screenshots, analyze charts, and answer questions about visual content. Unfortunately, Apple's Foundation Models framework doesn't currently support sending images with prompts.\n\nBuilding on an existing API means accepting its constraints. Apple will likely add image support in a future release (iOS 27, perhaps?), but vision-language models are too useful to wait for. So we've extended beyond what Foundation Models offers today.\n\nHere's an example sending an image to Claude:\n\n```swift\nlet model = AnthropicLanguageModel(\n apiKey: ProcessInfo.processInfo.environment[\"ANTHROPIC_API_KEY\"]!,\n model: \"claude-sonnet-4-5-20250929\"\n)\n\nlet session = LanguageModelSession(model: model)\nlet response = try await session.respond(\n to: \"What's in this image?\",\n image: .init(url: URL(fileURLWithPath: \"/path/to/image.png\"))\n)\n```\n\nWe're taking a calculated risk here; we might design something that conflicts with Apple's eventual implementation. But that's what deprecation warnings are for. Sometimes you have to write the API for the framework that doesn't exist yet.\n\n## Try It Out: chat-ui-swift\n\n[![Screenshot of chat-ui-swift app](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/any-swift-llm/chat-ui-swift.png)](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/any-swift-llm/chat-ui-swift.png)\n\nTo see AnyLanguageModel in action, check out [chat-ui-swift](https://github.com/mattt/chat-ui-swift), a SwiftUI chat application that demonstrates the library's capabilities.\n\nThe app includes:\n\n- Apple Intelligence integration via Foundation Models (macOS 26+)\n- Hugging Face OAuth authentication for accessing gated models\n- Streaming responses\n- Chat persistence\n\nIt's meant as a starting point: Fork it, extend it, swap in different models. See how the pieces fit together and adapt it to your needs.\n\n## What's Next\n\nAnyLanguageModel is currently pre-1.0. The core API is stable, but we're actively working on bringing the full feature set of Foundation Models to all adapters, namely:\n\n- **Tool calling** across all providers\n- **MCP integration** for tools and elicitations\n- **Guided generation** for structured outputs\n- Performance optimizations for local inference\n\nThis library is the first step toward something larger. A unified inference API provides the scaffolding needed to build seamless agentic workflows on Apple platforms β€” applications where models can use tools, access system resources, and accomplish complex tasks. More on that soon. 🀫\n\n## Get Involved\n\nWe'd love your help making this better:\n\n- **Try it out** β€” Build something, kick the tires\n- **Share your experiences** β€” What works? What's frustrating? We want to hear about the challenges you face integrating AI into your apps\n- **Open issues** β€” Feature requests, bug reports, questions\n- **Contribute** β€” PRs are welcome\n\n## Links\n\n- [AnyLanguageModel on GitHub](https://github.com/mattt/AnyLanguageModel)\n- [chat-ui-swift on GitHub](https://github.com/mattt/chat-ui-swift)\n\nWe're excited to see what you build 🦾\n", "dateCreated": "2026-10-04T12:50:30.804479567+00:00", "date_created": "2025-11-20T00:00:00+00:00", "date_modified": "2025-11-20T00:00:00+00:00", "date_published": "2025-11-20T00:00:00+00:00", "description": "LLMs have become essential tools for building software. But for Apple developers, integrating them remains unnecessarily painful. Developers building AI-powered apps typically take a hybrid approach, adopting some combination of: Local…", "external_url": "https://huggingface.co/blog/anylanguagemodel", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/huggingface-co/2025/11/2025-11-20-introducing-anylanguagemodel-one-api-for-local-and-remote.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/huggingface-co/2025/11/2025-11-20-introducing-anylanguagemodel-one-api-for-local-and-remote.md" }, "id": "urn:aggr:item:b53931fd0e7ee76ba88145595c1c17c2a13384db", "isBasedOn": { "@id": "https://huggingface.co/blog/anylanguagemodel" }, "mainEntity": { "@id": "https://huggingface.co/blog/anylanguagemodel", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/huggingface-co/2025-11-20-introducing-anylanguagemodel-one-api-for-local-and-remote/#webpage" }, "dateModified": "2025-11-20T00:00:00+00:00", "datePublished": "2025-11-20T00:00:00+00:00", "headline": "Introducing AnyLanguageModel: One API for Local and Remote LLMs on Apple Platforms", "timeRequired": "PT6M", "url": "https://huggingface.co/blog/anylanguagemodel", "wordCount": 1132 }, "name": "Archived snapshot: Introducing AnyLanguageModel: One API for Local and Remote LLMs on Apple Platforms", "preview": null, "reading_minutes": 6, "replicated_at": null, "source": "huggingface-co", "source_name": "Hugging Face - Blog", "summary": null, "tags": [], "temporalCoverage": "2026-10-04T12:50:30.804479567+00:00", "title": "Introducing AnyLanguageModel: One API for Local and Remote LLMs on Apple Platforms", "url": "https://aggr.aymericbeaumet.com/items/huggingface-co/2025-11-20-introducing-anylanguagemodel-one-api-for-local-and-remote/", "word_count": 1132 }