LangGraph Now Has a Swift Version: Run Agent Workflows on iOS

Swift Developers No Longer Need to Envy Python’s Agent Toolchain

Yesterday, a project called Swarm appeared on Hacker News. Its creator, Christopher Karani, titled it directly: "I Built LangGraph for Swift." This isn’t the first attempt to bring LangGraph into the Apple ecosystem — back in March 2024, Bartolomeo Sorrentino had already created a version called LangGraph-Swift to work alongside LangChain-Swift — but this new wave of projects signals that the community is finally taking something seriously: Agent applications on iOS/macOS should not just be thin API-wrapper clients.

The significance of this goes beyond what it appears to be on the surface. Over the past two years, the battle among Agent frameworks has largely taken place in the Python ecosystem, with LangGraph, LlamaIndex Workflows, CrewAI, and AutoGen taking turns in the spotlight. What about Swift? Apple provided the Foundation Models framework (introduced at WWDC25 for on-device model access), but if you actually wanted to build Agent orchestration — multi-step tool calling, state rollback, loop control, human-in-the-loop interruptions — developers were left either hand-rolling state machines or offloading orchestration logic to Python running on the server while the client remained a pure UI layer. For mobile scenarios that prioritize on-device privacy and responsiveness, this is an obvious mismatch.

What Problem Does It Actually Solve?

LangGraph’s core abstraction really consists of just three things: State (an object shared across the entire workflow), Node (a function that consumes and updates state), and Edge (routing logic that decides where execution goes next, including conditional branches and loops). The value of this design lies in explicitly modeling the Agent’s “think-act-observe” loop as a directed graph, instead of burying it inside layers of if-else statements and while loops.

Swarm and the earlier LangGraph-Swift both adopt this mental model. Taking Sorrentino’s implementation as an example, it provides a StatefulGraph parameterized by a State object, where nodes are async functions receiving AgentState:

try graph.addNode("call_agent") { state in
    guard let input = state.input else {
        throw executionError("'input' argument not found in state!")
    }
    guard let intermediate_steps = state.intermediate_steps else {
        throw executionError("'intermediate_steps' property not found in state!")
    }
    let step = await agent.plan(input: input, intermediate_steps: intermediate_steps)
    return ["agent_outcome": step]
}

try graph.addConditionalEdge(fromNode: "call_agent", condition: { state in
    guard case .some(let outcome) = state.agentOutcome else {
        return "end"
    }
    return outcome.isFinish ? "end" : "action"
})

Anyone familiar with the Python version of LangGraph can understand this immediately — it’s almost a literal translation. And that’s actually a good thing. The biggest risk for Agent frameworks is every vendor inventing their own DSL, turning cross-language migration into a full rewrite of business logic. Consistent APIs mean workflows validated on the Python side can be migrated to iOS with minimal cost.

Why This Matters Now

The mobile AI application ecosystem in 2026 is already very different from what it was a year ago. Several variables are changing simultaneously:

First, on-device models are now usable. Apple’s Foundation Models framework allows developers to directly access built-in system models at around the 3B-parameter scale. These are fully capable of handling tasks like summarization, classification, and structured extraction. This means not every node in an Agent workflow needs to make a network request anymore — lightweight nodes can run on-device while more complex reasoning can go to the cloud, which is becoming a sensible architecture.

Second, Swift Concurrency has matured enough. async/await, Actors, and TaskGroup are naturally suited for expressing concurrent Agent execution — parallel tool calls, timeout control, structured cancellation. Swift’s primitives are much cleaner than Python’s asyncio. LangGraph’s abstraction of “nodes as async functions” actually feels more natural in Swift.

Third, tool calling has become standard. GPT, Claude, and Gemini now all reliably support function calling / tool use, and DeepSeek V3.2 and Qwen3 have caught up as well. The value of Agent frameworks is no longer “teaching the model how to use tools,” but rather orchestrating state across multiple rounds of tool invocation. That is exactly what graph-based frameworks like LangGraph excel at.

How Does It Compare to Alternatives?

To put it plainly, there currently aren’t many things in the Swift ecosystem that deserve to be called “Agent frameworks”:

• LangChain-Swift + LangGraph-Swift: Sorrentino’s duo of projects, community-maintained, with the highest API alignment to the Python versions. Suitable for teams already using the LangChain stack.
• Swarm (new): Similar positioning. Based on Hacker News discussions, the author emphasizes lightweight design and native Swift ergonomics, without dragging in the entire LangChain ecosystem.
• Apple Foundation Models Guided Generation: The official approach. The advantage is deep system integration; the downside is that it only works with Apple’s own models, making cross-model orchestration impossible.
• Building everything yourself: Still the practical choice for many teams, but then you must handle state management, resumable execution, observability, and all the associated pitfalls on your own.

The conclusion is simple: If your iOS app just calls an LLM once to get a result, you don’t need a framework. But as soon as you enter the loop of “the model calls a tool, inspects the result, and decides the next step,” the cost of hand-writing a state machine quickly exceeds the learning cost of introducing a framework. Swarm and LangGraph-Swift fill precisely this gap.

A Real-World Example

Consider a concrete example. Suppose you’re building an email assistant on iOS. The user says: “Find the email my boss sent last week about the Q3 plan, summarize the key points, and draft a reply.”

Using a traditional implementation, you would need to write: query the email API → determine whether there’s a match → retry with different keywords if not → summarize the matched email with an LLM → generate a reply draft with another LLM call → ask the user for confirmation → regenerate if the user edits feedback.

Expressed as a LangGraph-style graph, it becomes:

search_email → [conditional: found?] → summarize → draft_reply → 
    [conditional: user_approved?] → send / regenerate (back to draft_reply)

The state object contains query, search_results, summary, draft, and user_feedback. If any node fails, execution can roll back to the previous stable state. If the user closes the app midway, the workflow can resume from where it stopped next time — because the entire execution trace is simply a sequence of state transitions, which is naturally persistable.

This is the core advantage of graph-based frameworks compared to “a pile of async functions awaiting each other”: execution becomes data, not control flow.

Pitfalls Worth Noting

A bit of cold water: porting abstractions from the Python ecosystem into Swift is not without cost.

1. Ecosystem fragmentation. The Python version of LangGraph sits atop the entire LangChain ecosystem — hundreds of integrations, LangSmith observability, LangGraph Platform deployment. The Swift versions currently provide little beyond the core library. If you want Pinecone integration, Tavily search, or tracing, you’ll need to build adapters yourself.

2. Fragmented model SDKs. If you want to call GPT, Claude, Gemini, and DeepSeek simultaneously on iOS, you either install every SDK separately or wrap all the HTTP calls yourself. This is why many iOS developers prefer OpenAI-compatible aggregation gateways — platforms like OpenAI Hub let one API key access mainstream models, with direct connectivity available domestically as well, avoiding the headache of maintaining multiple authentication schemes and endpoints in the app. Inside an Agent framework, switching models then becomes as simple as changing a model string.

3. Debugging experience. On the Python side, LangSmith provides detailed traces for every step. On Swift, developers currently rely mostly on print statements or wiring up OSLog manually. The worst thing when an Agent fails is not knowing at which step execution went off course, and the tooling ecosystem here still needs time to mature.

A Final Assessment

Projects like this won’t see explosive user growth in the short term, but the direction is correct. Running Agents on mobile devices will become a clear trend from the second half of 2026 into 2027, for a simple reason: model capabilities are now sufficient, on-device compute power is sufficient, and user expectations for “intelligent assistants on phones” have already been raised by Apple Intelligence and AI smartphones from various manufacturers. But the engineering infrastructure required to support all this — frameworks, debugging tools, deployment solutions — is only just beginning to emerge.

For Swift developers, now is a good time to get involved. Learn the LangGraph mental model once, and you can reuse it across both Python and Swift. The frameworks themselves are still small enough that reading the source code, submitting PRs, and influencing API design are all still realistic opportunities. By the time Apple enters the space with something similar next year (I’d personally bet WWDC26 will include movement here), the experience accumulated in the community today will become an early-mover advantage.

References

• Swarm - LangGraph for Swift (GitHub): A new project featured on Hacker News, implementing LangGraph for Swift from scratch
• LangGraph-Swift (GitHub): Bartolomeo Sorrentino’s 2024 release designed to work alongside LangChain-Swift