Reins: a private local AI chat client for Apple devices

A chat client that talks to your own models

The repository description names the project precisely. Local AI chat for iPhone, iPad and Mac, connecting Ollama, LM Studio or any OpenAI-compatible server, or running MLX models on-device, and it includes tools and web search.

The About section puts it plainly. Reins is a private AI chat app for iPhone, iPad and Mac. It connects to your Ollama, LM Studio or OpenAI-compatible server, or runs models directly on your device with no server at all. Every chat has its own model, system prompt and settings, so each conversation works the way you want.

So the architecture is a client, not a service. There is no account to create, no request to a vendor's API and no per-token billing, and the model is whichever one you already have. That is the appeal, and it also defines the audience: people who run a model locally or on a server they control, and who want a phone-shaped interface for it.

The three claims in the README that frame everything else are short:

No login. No data collection. Your chats stay on your device.

The primary language is Dart, the app is on the App Store, and the homepage is getreins.app. The licence is GPL-3.0 and the default branch is main, with the last push on 2026-10-14.

Any server, or no server at all

The first feature entry covers the connection side, and it is the one that decides whether the app is useful to you.

Any server or On-Device: connect to Ollama, LM Studio, Ollama Cloud or any OpenAI-compatible server. You can also run MLX models and Apple's Foundation Models on-device and share them with other devices on your local network.

That last clause is the interesting one. MLX is Apple's framework for running large models on their own hardware, and Apple's Foundation Models is the on-device model family that ships with the platform. Running one of those on the iPhone or the Mac means no server is involved at all, which is the strongest form of the privacy claim in the README. And sharing them with other devices on your local network extends that to a household or a studio, which is a different arrangement from pointing the app at a remote machine.

The OpenAI-compatible route is what makes the app usable with the wider ecosystem, because LM Studio, Ollama and others all expose that API shape, so an existing local server needs no adaptation.

The server management feature sits alongside this. You can browse, download and manage models from the app, add multiple servers with API keys and custom headers, and switch between them instantly.

The ability to switch servers without leaving a conversation is what makes multi-server setups usable. A local Ollama for routine work and a remote server for a heavier model is a realistic arrangement, and a client that forces one connection at a time would make it tedious.

The trade-off is that the app is only as private as the endpoint you point it at. A local model keeps the conversation on the machine, and a remote OpenAI-compatible server receives the same traffic any chat client would send, which is worth keeping in mind when reading the no data collection line.

Tools, web search and per-chat settings

The second and third features are what separate this from a minimal chat window.

Tools and web search: models can call tools, search the web, fetch pages and reason across multiple steps, with no API key required. The last part is the notable one. Tool use and web search in most clients depend on a provider's hosted capabilities or on your own key for a search service, and here the model reaches the web through the server you have already configured. Whether that works depends on what your server exposes, which the README does not spell out, but the intent is clear: the local model gets the same capabilities without a second account.

Per-chat configuration: set the system prompt, model, temperature, context size and more for each conversation.

That is a real departure from the usual arrangement. Most chat clients keep one system prompt and one model for the whole app, and changing them means changing settings globally. Here each conversation carries its own, which means a coding conversation with a long context window and a quick question with a small one can live side by side without fighting over a single slider.

Together, the two features answer the question that matters most for a local-first client. The model is local, but it is not cut off from the world, and the conversation you are in is configured the way that conversation needs rather than the way the last conversation needed.

The features that make it a chat client rather than a demo

The rest of the feature list is where the app's daily usefulness lives, and several entries point at problems that chat clients usually handle badly.

Branch and continue: duplicate a chat to explore another path, and pick up cut-off responses where they stopped. Duplicating a chat to ask a different question is the natural move when a model goes down a path you did not want, and having the branch as a separate conversation means the original stays intact.

Attachments: send images, PDFs, CSVs and text files. A local model that can see an image or read a PDF turns the app from a text toy into something you can use on real documents.

Temporary chats: chat without leaving a trace. On a device that stores every conversation locally, the ability to have one that is not stored is the exception people ask for.

Background generation: responses and downloads keep running after you leave the app. That is what makes model downloads and long responses tolerable on a phone.

And there are two smaller ones with real appeal. Thinking mode turns on reasoning for harder questions, which matters most for the small local models that otherwise cannot do it. Export and import lets you back up or share conversations, which is the obvious answer to the question of what happens to a chat history that lives only on one device.

Taken together, these are the features of a client meant to be used daily on a phone, which is a harder brief than it sounds, because the phone is not always the place you configured the model.

The repository stops at version 1.3.4

The final line of the README is the one an evaluator has to read carefully. This repository contains the source code of Reins up to version 1.3.4.

That sentence sits in tension with the release history. The recent releases are 2.3.2 from 2026-10-14, v1.3.4 from 2026-02-24 and v1.3.3 from 2025-12-18. So the most recent release, 2.3.2, is dated on the same day as the last push to the repository, and it is not the code that is in the tree.

Everything between 1.3.4 and 2.3.2 is therefore closed in this repository, and 1.3.4 itself is eight months old. That does not make the project bad, and the app is on the App Store with a website, a privacy policy and terms of use, so there is clearly more than the repository. It does change what the repository is for: it is the source of an earlier version, not the source of the app you would install today.

For a reader who wants to build the app, that is a hard boundary. You can read the 1.3.4 source, compile it, and see how a Flutter client for Ollama, LM Studio and MLX is put together, but you cannot read the code that produced the binary on the store.

The licence compounds it slightly. GPL-3.0 obliges anyone who distributes a modified version to publish the source, so an app whose repository does not carry the current code is an unusual combination, and it is worth asking about before building on this repository for anything you intend to ship.

What the README does confirm is the behaviour of the published app, and the About section's promise is unambiguous about where the data goes.

A Flutter project with every Apple and desktop target

The repository layout is a Flutter application rather than a Dart library, and the directories show the platform coverage.

There is a lib directory for the Dart source, an assets directory, a test directory, and a pubspec.yaml with a pubspec.lock. Then there are the platform folders: android, ios, macos, linux, windows and web. Six targets from one codebase, which is what Flutter's cross-platform model is for.

The configuration files around them are the standard Flutter set, with.metadata recording the Flutter version the project was created against, devtools_options.yaml holding DevTools settings, and analysis_options.yaml holding the lint configuration that the Dart analyzer uses.

What is absent is as informative as what is present. There is no native module directory for the MLX runtime or for Apple's Foundation Models, no separate package for the OpenAI-compatible client, and no service directory, because the whole thing is one application with its dependencies declared in pubspec.yaml rather than a workspace of packages.

That is consistent with the product. Reins is an end-user application whose value is the assembled experience, per-chat configuration and tool use, rather than a reusable component, and its differentiation from a plain chat window is in the interface rather than in a library others would build on.

The support model is also simple and worth noting for anyone evaluating an app that handles your own data. Problems go to the GitHub issue tracker or to [email protected], and the project links a website, a privacy policy and terms of use.

Editorial conclusion

Reins fits an Apple user who wants a chat client for a model running on their own machine or their own server, and who values per-conversation configuration, tools and attachments over a hosted product with an account. It is the wrong choice for anyone assessing it as an open source codebase, because the repository stops at version 1.3.4 while the current release is 2.3.2, so most of the current application is not in the tree. Verify first which version you would be building from, that the server you want to talk to exposes an OpenAI-compatible endpoint if that is the path you take, and what the GPL-3.0 licence means for a distributed build of the app.

Frequently asked questions

Official sources

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