Swarm for Swift

The deciding trait is that the same agent loop runs on a phone, a laptop and a server. For anyone building in Swift, that removes the usual ugly step where the app talks to a Python service you also have to operate, and the tools your agent calls are the same Swift types the rest of your code already uses.

Outside Swift it is irrelevant, and inside Swift there is almost nothing else, which makes the choice easy in both directions. Pick it if you are shipping an agent inside an Apple app. Pick a Python framework if your agent lives on a server anyway.

The published version is 0.6.2 and the documented install pins a lower bound rather than an exact release. Before one-point-zero a minor bump is allowed to break you, and a lower bound accepts every one of them, so the default instruction in the README is the one that will wake somebody up. Pin the exact version instead.

Nothing else here is dangerous, because the runtime does not touch a shell, a repository or a file. The risk is entirely in the dependency, which is the correct place for it to be, and it is the risk everyone ignores until a build fails on a machine that is not theirs.

1. Tool definitions are checked by the compiler. A macro turns an annotated struct into the tool schema, so the mismatch between a declared parameter and the code behind it becomes a build error rather than a runtime surprise, which is a class of failure most frameworks handle with validation at call time. 2. That moves verification earlier than any prompt-level guard can reach.

2. The cost is that a tool cannot be defined at runtime, and no evaluation is offered on any of it. This is a design argument, and the argument is sound on the axis it chooses.

One author, 574 stars, and a language with exactly one platform owner, who has every reason to ship this itself. That last part is the whole position: the most likely competitor is a first-party framework announced at a developer conference, and the most likely outcome is that it arrives.

Moat: being early in a small language community, which is worth something for about two years. Likely path: it stays the community option alongside whatever Apple ships, or it is superseded outright. Likely acquirer: nobody, though the author is exactly the profile a platform team hires. Position: use it, and write your tool structs so they survive being ported.

This is not a purchase, it is a dependency, and the review that matters is the one my mobile team does before it ships inside a product customers install. There is no console, no seat count and nothing for procurement to sign, which resolves the budget question and creates a different one about what our app is doing on a customer's device.

For sixty engineers it is relevant to the handful writing Swift. Nothing runs in a pipeline, so it never appears in my metrics. Approved with conditions: the mobile team owns it, and the guardrails it ships with are configured before anything reaches a release build.

MIT, and the model story is the best kind: on-device Apple Foundation Models where the hardware has them, Ollama where it does not, and an OpenAI-compatible endpoint for everything else. An agent that runs with no network at all, on a phone, is a thing I did not expect to be able to build this year.

The default package is deliberately lean, which I appreciate more than any feature, because a dependency that drags twelve others in is a dependency I end up removing. There is no MCP client, so servers I run are not reachable from an app built on this.