Conduit: a Flutter client that puts Open WebUI and direct model endpoints on iOS and Android

The mobile gap Conduit is built to close

The README states the problem in its own words: Open WebUI is good on the desktop, and on mobile it breaks down at the edges. It names four of those edges. Authentication behind a reverse proxy. Streaming that drops when the app backgrounds. Getting a screenshot into a prompt. Starting a chat from the home screen. Those are not feature requests, they are the friction points that decide whether a self-hosted chat setup gets used from a phone at all.

The intended user is someone who already runs infrastructure. You have an Open WebUI instance, or an Ollama box on the LAN, or an OpenAI-compatible gateway, and you want a client that speaks to it natively rather than loading a web UI in a mobile browser tab. The README is explicit that nothing routes through a backend the maintainer operates, and that chats live on the device first. For people who self-host specifically to avoid a third party in the path, that claim is the whole point.

As of 4.0 the app also works without an Open WebUI server. That matters because it widens the audience from existing Open WebUI operators to anyone with an API key or a local model, and it changes the evaluation: you are no longer only judging a client, you are judging a client that also has its own provider layer.

Six connection modes and what each one actually gives you

On first launch the app asks how you want to connect, and the README describes six options that can be added incrementally. Open WebUI is the full-feature path: chats, folders, notes, channels, workspace, tools, web search, image generation. Direct covers OpenAI-compatible endpoints over Chat Completions or Responses, LM Studio, Azure-style API versions, native Ollama, and first-party OpenRouter. Apple On-Device runs Apple's local SystemLanguageModel on iOS 26 with Apple Intelligence, offline, with streaming, sampling controls, and JSON-schema responses inside a 4K context window. Apple Private Cloud Compute uses the Foundation Models framework on iOS 27 with Apple's managed PCC entitlement. Hermes connects to your own agent server.

The constraints are stated plainly and they are worth reading twice. Apple On-Device does not support image input, reasoning controls, or tool calling. Apple PCC supports image input, reasoning levels, sampling and output limits, JSON-schema responses, live quota and context status, and an optional on-device fallback for network failures, but tool calling is not enabled there either. So the two Apple paths are the ones with the narrowest capability surface, and they are also the two that require specific OS versions and, for PCC, an entitlement. If your workflow depends on the model calling tools, neither Apple provider is the one you want.

Direct connections configured inside Open WebUI are picked up automatically, according to the README, and keys plus custom headers stay in platform secure storage. That last detail is a design decision worth noting: credentials are not held in the app's own database, they go to the OS keychain or keystore.

Streaming over WebSocket and local-first storage

The mechanism the README describes for chat is token-by-token streaming over WebSocket, with the transcript holding its position while a response grows. Pinned prompts stay in place, and long conversations load without stalling the UI. If you have used a chat client that reflows the whole scroll position on every token, you know why this is called out.

Rendering is native Flutter rather than a web view, and the README lists what that buys: syntax-highlighted code blocks with copy and preview, Mermaid diagrams rendered natively, LaTeX and math, expandable reasoning, tool-call and code-execution sections, inline citations, source cards, follow-up suggestions, and Chart.js embeds. That is a longer list than most mobile LLM clients attempt, and it is the part of the project that is hardest to replicate with a wrapper around a web UI.

The storage model is described as device-first: chats live on your device, and notes are documented as working offline with autosave, pinning, AI-generated titles, AI enhancement, and audio recording. The Workspace is implemented as native screens for models, knowledge, prompts, tools, and skills, with unified settings navigation, and the README notes that sections you lack permission for simply do not appear. That permission-aware rendering is a small thing that avoids a common failure mode, where a client shows a menu entry that returns 403 when tapped.

Getting it running: store installs versus a source build

The fastest path is the two store listings linked in the README: Google Play under the package id app.cogwheel.conduit, and the App Store listing for Conduit, the Open WebUI client. There is no server component to install for the app itself. You point it at infrastructure you already have.

The source path is documented in docs/BUILDING.md, which the README links but does not inline, so the exact build commands are not in the material available here. What can be said from the repository metadata is that the primary language is Dart and the app is Flutter, so the toolchain is the standard Flutter one. Beyond that, treat the building guide as the authority rather than any command you might guess.

Configuration happens in the app rather than in a config file. On first launch you choose a connection type, then supply what that type needs: a server URL for Open WebUI or Hermes, an API key or none at all for a local endpoint, and for the Apple providers nothing beyond an eligible device and OS version. The README notes that Direct connections already configured in Open WebUI carry over automatically, which means an existing Open WebUI setup can seed the app without re-entering credentials by hand.

One thing to check before you invest time: the README describes a full Open WebUI feature set including channels, workspace, tools, and web search. Those depend on what your server actually exposes. The Hermes section makes the same point explicitly, saying Conduit only exposes the capabilities your server reports. Expect the same posture elsewhere.

Where Conduit is the wrong tool

The clearest limitation is stated by the project itself: tool calling is not enabled on either Apple provider. If you want an agent that runs tools on-device or through Private Cloud Compute, this app will not give you that today, regardless of what the underlying model can do.

The second limitation is version gating. Apple On-Device requires iOS 26 and Apple Intelligence. Apple PCC requires iOS 27, Apple Intelligence availability, and Apple's managed PCC entitlement. Those are not settings you can turn on. If you are on an older device, in a region where Apple Intelligence is unavailable, or without the entitlement, those two connection modes are simply not in reach, and the app falls back to whatever else you configured.

The third is the one that bites operators. Conduit is a client, and a client is only as capable as the server behind it. Channels appear when your server enables them. Workspace sections appear when you have permission. Direct connections depend on the endpoint accepting the request shape you picked, whether that is Chat Completions, Responses, or an Azure-style versioned path. A reverse proxy that terminates WebSocket upgrades will break streaming, and the README lists authentication behind a reverse proxy as one of the original mobile pain points rather than something the app can paper over.

Finally, this is a Flutter app under GPL-3.0. If your organisation has policies about copyleft in distributed software, a mobile client is a distribution surface. That is a licensing question for your own counsel, not something this article can settle.

What it replaces, and what it does not

The obvious comparison is a mobile browser pointed at your Open WebUI instance. That approach has real advantages: zero install, always the same version as your server, and no second client to keep in step. Conduit's answer is that the browser path is where the four named pain points live. Backgrounding a browser tab during a long stream, attaching a screenshot, and launching straight into a chat from the home screen are all things a native app handles differently. If none of those bother you, the browser tab remains a perfectly reasonable choice and costs nothing to maintain.

The second comparison is a generic OpenAI-compatible mobile chat client. Those tend to be built around a single provider and a single API shape. Conduit's Direct mode is broader on paper: Chat Completions or Responses, LM Studio, Azure-style API versions, native Ollama, and OpenRouter. The difference in approach is that Conduit treats Open WebUI as a first-class backend rather than an afterthought, which means folders, notes, channels, and workspace screens are native surfaces instead of a link out to a web page. If you do not run Open WebUI, that advantage disappears and you are comparing provider coverage and rendering quality.

The third comparison is Apple's own model access. Conduit wraps SystemLanguageModel and the Foundation Models framework behind the same chat path as everything else, which is convenient, but the capability ceiling is Apple's, not Conduit's. A dedicated Apple Intelligence app would hit the same wall.

Maintenance, release cadence and licence cost

The release history shows a steady cadence: v4.1.2 on 2026-08-26, v4.1.3 on 2026-08-28, v4.1.4 on 2026-09-01, with the last push to the repository on 2026-09-03. Three patch releases in about a week suggests active maintenance, and it also suggests you should expect to update. For a client that talks to a moving server API, frequent point releases are normal rather than alarming.

The maintenance cost for an adopter is mostly on the server side. Every Open WebUI upgrade is a chance that a workspace or channel endpoint changes shape, and the app's permission-aware rendering means a mismatch may show up as a missing screen rather than an error message. Budget for checking the app after server upgrades, particularly around channels, tools, and web search.

On licensing, Conduit is GPL-3.0. For individual users installing from the App Store or Google Play, this is not a practical concern. For anyone modifying the app and distributing it, including inside a company, the copyleft terms apply and the source obligations travel with the binary. The README does not discuss commercial licensing or an exception, and this article cannot give legal advice, so treat that as something to verify with your own counsel before you fork and ship.

The project also carries a Vercel OSS Program badge and a Trendshift badge in its README. Those indicate recognition programs and a daily ranking, not a measure of code quality, and they should not factor into an adoption decision.

Editorial conclusion

Adopt Conduit if you already run Open WebUI or a self-hosted Hermes agent and want a native mobile surface for it, or if you want to talk straight to an OpenAI-compatible endpoint or local Ollama from a phone without standing up Open WebUI at all. Skip it if you are not on Flutter tooling, if you need tool calling against Apple's on-device or PCC models, or if your only client is a desktop browser. Before committing, verify three things: that your Open WebUI version exposes the workspace and channel endpoints Conduit's screens expect, that your reverse proxy handles the WebSocket upgrade path streaming uses, and that the GPL-3.0 obligations are acceptable for however you intend to distribute a build.

Official sources

1. cogwheel0/conduit on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases