Swarm: a Swift-native agent runtime for on-device and server-side agents

The problem Swarm addresses for Swift developers

Most agent frameworks are written in Python or TypeScript. A team shipping an iOS or macOS app in Swift that wants tool-calling agents has two options: run a sidecar service and talk to it over HTTP, or reimplement the agent loop against a provider API. The first adds a deployment surface and a network hop. The second means writing your own tool-schema generation, retry logic, streaming event handling and conversation state, then keeping all of it in sync as models change.

Swarm's answer is to keep the loop in Swift. The README describes it as a "Swift-native agent runtime for type-safe tools, on-device Apple Foundation Models, composable workflows, memory, guardrails, and streaming," built for iOS, macOS and Linux with the same agent loop. The audience is narrow and specific: Swift developers who want agents inside an app or a server process they already control, rather than a separate Python service. If your stack is not Swift, the package offers nothing you cannot get more cheaply elsewhere.

How the agent loop, tools and workflows fit together

The mechanism visible in the README is a macro-driven tool layer over a pluggable inference provider. You declare a tool as a Swift type annotated with `@Tool`, and each parameter with `@Parameter`. The README states that the `@Tool` macro generates tool schemas from Swift types at compile time. That is the core design decision: the schema the model sees is derived from the Swift type system rather than written by hand as JSON, so a parameter rename is a compile error rather than a runtime mismatch. `FunctionTool` is the escape hatch when you do not want macros at all.

Inference sits behind an `InferenceProvider` protocol. The README lists Apple Foundation Models, Ollama or LM Studio over local HTTP, OpenAI, Azure or OpenRouter through an OpenAI-compatible API, and custom providers. The agent loop is unchanged across all of them, which is the claim that matters: you can develop against a local Ollama model and ship against Foundation Models or a cloud endpoint without rewriting the agent. A process-wide default can be set with `await Swarm.configure(provider:)` so you do not pass a provider to every agent.

Above single agents, `Workflow` composes them. The README shows `.step()` for sequential chains, `.parallel([...], merge: .structured)` for fan-out with a structured merge, and `.route { input in ... }` for conditional dispatch. The same workflow type also supports repeat and timeout according to the README's summary of capabilities. Memory is a separate choice: `Conversation` preserves multi-turn state, and the available strategies are conversation, sliding-window, vector, summary and hybrid. Guardrails validate inputs, outputs and tool arguments before they reach application code. Streaming exposes lifecycle, tool, thinking and output events through `AsyncThrowingStream`.

The concurrency model is worth calling out because it constrains how you write tools. Swarm uses Swift 6.2 strict concurrency, so values crossing actor boundaries must pass compiler checks. That is a real benefit for correctness in concurrent agent execution, and a real cost in migration effort if your existing code is not yet strict-concurrency clean.

Installing Swarm with Swift Package Manager and running a first agent

Swarm installs through Swift Package Manager. The README's default package is deliberately lean: core Swarm, Foundation Models and macros, resolving only swift-syntax (pulled in by the default-on Macros trait) and swift-log. Add the dependency with a version requirement of `from: "0.6.2"`.

dependencies: [
    .package(
        url: "https://github.com/christopherkarani/Swarm.git",
        from: "0.6.2"
    )
]

Optional surfaces are gated behind traits, and specifying traits replaces the defaults, so you must combine them explicitly. The README documents three: `Integrations` for the durable graph, ContextCore/Wax memory, Membrane and web helpers; `MCP` for the SwarmMCP adapter and the MCP Swift SDK; and `OpenTelemetry` for the OpenTelemetry wrappers. Both `MCP` and `OpenTelemetry` also enable Macros.

.package(
    url: "https://github.com/christopherkarani/Swarm.git",
    from: "0.6.2",
    traits: ["Integrations", "MCP", "OpenTelemetry"]
)

For a macro-free build, the README says to use `traits: []` and define tools with `FunctionTool`.

The first real use is a tool-using agent. The README's opening example declares a stock price tool with one parameter and runs it against Foundation Models on supported devices.

import Swarm

@Tool("Looks up a stock price")
struct PriceTool {
    @Parameter("Ticker symbol") var ticker: String

    func execute() async throws -> String {
        "AAPL: $182.50"
    }
}

You should see the schema for `ticker` generated at compile time and the agent call the tool when the question references a ticker. If Foundation Models is unavailable, the README says to use an OpenAI-compatible provider, Ollama, a mock provider, or the deterministic examples. To confirm the package works on your machine before wiring a provider, the repository ships runnable examples; the OnDeviceChat example can be started in demo mode without API keys or Apple Intelligence.

cd Examples/OnDeviceChat
swift run OnDeviceChat --demo

A local model is configured by passing the OpenAI-compatible provider with an Ollama model name, which lets you exercise the same loop without a cloud key.

Where Swarm is the wrong tool

The platform floor is the first constraint. Swarm requires Swift 6.2 and iOS, macOS or tvOS 26.0. A team maintaining an app that must run on earlier OS versions cannot adopt the Foundation Models path at all, and the README does not describe a compatibility shim for older Apple platforms.

Linux is supported, but unevenly. The README states that the default Swarm graph is CI-tested on Ubuntu with Swift 6.2, and that Apple-only features such as Foundation Models, SwiftData, OSLog and some built-in tool behavior are unavailable or different on Linux. So a Linux deployment is viable for the core loop with an OpenAI-compatible provider, but the on-device inference story and parts of the memory and platform integration layer do not carry over. If your plan is a single codebase that behaves identically on Apple hardware and Linux servers, the README does not promise that.

The README also does not document rollback behavior for checkpoints, nor does it describe what happens to an in-flight workflow when a checkpoint written by an older release is resumed by a newer one. Durable execution is listed as a capability gated behind the `Integrations` trait, with checkpoint and resume after a process restart, but schema evolution across versions is not covered. Treat that as unverified until you read the relevant guide.

Finally, ecosystem size. Swarm's topics list includes langchain, which invites a comparison, but the two are not substitutes. LangChain is Python and JavaScript with a large integration catalogue; Swarm is Swift with a small set of providers and traits. If your team is polyglot and the agent is not required to live inside the Swift process, the Python or TypeScript ecosystems have more connectors and more prior art.

How Swarm differs from LangChain-style runtimes

The difference is not feature count, it is where the type boundary sits. In a LangChain-style Python runtime, a tool is typically a decorated function whose argument schema is produced at runtime from a signature or a Pydantic model, and the agent receives a dictionary of arguments. In Swarm, the README states that the `@Tool` macro generates tool schemas from Swift types at compile time, and Swift 6.2 strict concurrency means values crossing actor boundaries must pass compiler checks. The practical consequence is that an argument type mismatch between the model's output and your tool is caught by the compiler or by decoding, not by a runtime error deep in a chain.

The second difference is inference locality. LangChain-style runtimes assume a remote model by default. Swarm treats Apple Foundation Models as a first-class provider with an on-device path on supported devices, and keeps Ollama, LM Studio and OpenAI-compatible endpoints as alternatives behind the same `InferenceProvider` abstraction. For an app that must work offline or keep prompts on the device, that ordering matters. The trade-off is reach: the provider table in the README is short, and there is no claim of a large third-party integration catalogue.

Maintenance, releases and licence cost

The repository is not archived, and the last push was on 2026-09-09. Releases are frequent and small: 0.6.2 on 2026-08-14, 0.6.3 on 2026-08-28, and 0.6.4 on 2026-08-29. That cadence suggests incremental change rather than long-stable API surface, so pinning a version in `Package.swift` and reading release notes before bumping is the sensible default. The README does not describe a deprecation policy or an API stability guarantee, which is consistent with a pre-1.0 line.

Upgrade cost is shaped by the trait system. Because specifying traits replaces the defaults, an upgrade that changes which traits exist, or which dependencies a trait pulls in, can change your resolved dependency graph. The lean default keeps swift-syntax and swift-log only; enabling `MCP` adds the MCP Swift SDK and `OpenTelemetry` adds the OpenTelemetry wrappers. A team that wants none of those should stay on the default or on `traits: []` with `FunctionTool`.

The licence is MIT. That permits use in closed-source applications and modification, subject to the usual requirement to preserve the copyright notice and licence text. It does not grant trademark rights, and it comes with no warranty. This is a description of the licence identifier in the repository, not legal advice; if you are redistributing the package or bundling it into a product with a compliance process, have counsel read the LICENSE file rather than this paragraph.

Editorial conclusion

Adopt Swarm if your application is already Swift and you want the agent loop, tool schemas and workflow composition to live in the same language and the same concurrency model as the rest of your code, with an on-device inference path on Apple hardware. Do not adopt it if you need a mature cross-language agent ecosystem, or if you are targeting Apple platform versions below 26.0. Before committing, verify three things in your own environment: that your deployment target meets the iOS, macOS or tvOS 26.0 minimum, that the provider you intend to use is reachable from the platform you ship on, and that the trait combination you need resolves without dragging in the MCP Swift SDK or OpenTelemetry when you do not want them.

Frequently asked questions

Official sources

1. christopherkarani/Swarm on GitHub
2. License: MIT
3. Project website
4. README
5. Releases