Apps that run on your Mac.
Open-source AI models have crossed a threshold. The same hardware that runs your browser can now run a model good enough for real work — transcribing meetings, organizing documents, drafting writing, answering questions about your own files.
The bottleneck isn’t the model anymore. It’s everything around the model.
There’s no easy way to take a useful AI workflow and turn it into an app a friend could install. There’s no place to find such apps. There’s no way to know, before you install one, whether it’s actually local — or whether it’s just sending your data somewhere with extra steps.
Locara is the missing layer.
What Locara is
A website where you find local AI apps. A framework for building them. A registry that signs and reviews them.
Each Locara app is its own standalone Mac app. You download it from a website, drag it to Applications, double-click. No Locara client to install first. No store app to launch. The Locara framework lives inside each app — invisible to you — handling capability enforcement, model loading, and the trust mechanics that make “fully local” verifiable.
Apps built on Locara live entirely on your Mac. The models. The data. The processing. Nothing leaves the device unless the app’s manifest says it does — and when it does, you see exactly what.
Developers write apps in TypeScript. The trust mechanics — capability declarations, kernel-enforced sandboxing, signed builds, public provenance — are baked in below the surface. Users install them the same way they install any other Mac app.
This isn’t only about making local AI apps distributable. It’s about a new kind of app — built in hours, secure by construction, completely local with the AI batteries included, and distributable by default. Today, achieving any one of those properties is its own engineering project; achieving all four at once is research. Locara turns all four into the starting point. The result is something you can build in an evening and hand to a friend.
Build for yourself, or publish for others
Locara works at two scales:
For yourself. You can build a Locara app and never share it. Scaffold, code, run, use. Your transcription tool, your private knowledge base, your custom assistant — they live on your Mac, against your data, exactly the way you want them. The framework is free, the runtime is yours, no one else needs to be involved.
For others. When you want to share what you’ve built, you publish to the Locara registry. Locara CI builds and signs your app from source, Apple notarizes it, and your app gets listed on locara.app. Anyone can browse, click “Download,” drag it into their Applications folder, and run it — same way they install any other Mac app. Your app travels with its capability declarations, its provenance attestation, and the trust mechanics intact.
Publishers don’t need their own Apple Developer Program enrollment. The Locara project owns one and uses it to sign every app, with publishers credited as the authors. Lower barrier, same trust.
Same framework. Same primitives. Same workflow. The only thing that changes between “private tool” and “public app” is one command.
Secure by construction, not by promise
The Locara primitives — chat, transcription, OCR, vision, embeddings, storage, tool execution — are designed to be secure by default. An app starts with zero capabilities. Every primitive call is gated by an explicit declaration in the app’s manifest. The macOS kernel enforces what’s outside the app’s container; the Locara runtime enforces what’s inside.
When an app is published, the registry runs an automated review pipeline. The submitted source is built in a clean environment, statically analyzed against its own capability declarations, and signed. Any mutation between what an app declares and what it actually does — code that tries to fetch a URL when the manifest says no network, code that tries to read your Documents when it only declared user-selected files — is detected at review time and blocks publication.
This isn’t security as a promise we make. It’s security as a property of the architecture. We can’t betray you because the system makes it impossible.
What we believe
Yours. Your apps run on your hardware. Your data lives in your folder. The framework is open source. The catalog is open. You aren’t a tenant in someone else’s product.
Durable. A Locara app written in 2026 should work in 2036. The manifest schema, the SDK, the file formats — all designed for the long arc. Not for next quarter.
Private. Privacy isn’t a policy here; it’s where the data lives. Apps that run on your Mac, against models on your Mac, writing to a database on your Mac, can’t betray you to a server you didn’t agree to.
Malleable. The framework is small primitives, not opinionated architecture. Components are source code in your repo, not opaque packages. You can change anything. Pair with an LLM and rewrite a component during your morning coffee.
Independent. No investors. No exit pressure. The project is sustainable as a small operation, supported by users and optional paid services. The framework is free, forever.
Why local matters
Local-first isn’t an aesthetic. It’s a structural advantage along every axis that matters.
Uptime. Cloud services have outages. Some are minor, some are days. Until energy is solved, this won’t change. Local applications don’t have this problem. As long as your laptop has battery, your apps work. The only “uptime” you depend on is your battery.
Cost. Cloud-AI subscriptions are quietly accumulating into the largest line item in many people’s tech budgets — often hundreds of dollars per month per person, before you’ve shipped anything. A local app runs at the cost of the electricity to power your laptop. Once you’ve bought the device, the marginal cost of running an AI app on it is essentially zero — orders of magnitude cheaper than the cloud equivalent. We’ll have more to say about how this changes the economics of building, charging for, and operating software.
Privacy. Things don’t leave your device by default. Not your prompts, not your documents, not your audio, not your search queries. The privacy story isn’t “we promise we won’t look” — there’s nothing to look at, because the system doesn’t have your data in the first place.
Speed. Local is faster. Network round-trips compound. An agentic app that makes ten cloud-API calls to do its work spends most of its time on TLS handshakes and queueing. The same app running locally — model on disk, tools in a sandbox, data in SQLite — does in milliseconds what the cloud version does in seconds. For any AI app that involves tool use, retrieval, or multi-step reasoning, local is the faster path.
Quality. This is the honest one. The frontier cloud models are still better than what you can run on a laptop, especially for the most demanding tasks. The gap is narrowing — fast — and for many real workloads it’s already small enough that it doesn’t matter. Where it does matter, you can still reach for cloud (apps that declare a network capability can use it). For everything else, local is good enough now and will be more than good enough soon.
Three of these are won by local. One is closing. One is the only one cloud still has, and it’s getting smaller every month.
What we’re not
We’re not building a chatbot. We’re not building a model. We’re not competing with Ollama or Hugging Face — we use them.
We’re not trying to be a general “build any app” platform. Locara is for narrow, opinionated apps that do one thing well and entirely on your device.
We’re not a payments processor. Apps charge users through whatever channel suits them; we take nothing.
We’re not VC-funded. We’re not chasing growth at any cost. We’re building a tool we want to use, in the way we want to use it, on the timeline that makes sense.
What this means in practice
For developers: a CLI that takes you from idea to a signed, distributable app in under an hour. A small SDK with primitives for chat, transcription, OCR, vision, embeddings, and sandboxed tool execution. Components you copy into your repo and own. The kind of build you can pair with Cursor or Claude Code and ship in an evening.
For users: apps that show you exactly what they can and cannot do, before you install. Apps that run when your network is down. Apps that don’t slow your laptop the way 11 Electron windows do. Standalone Mac apps you download from a website, drag to Applications, and use — like any other app, with better trust properties.
For the ecosystem: open code, an open spec, an open registry, open data formats. Forks are tolerated, alternative registries are first-class, and the things you keep are the kind you can extract and carry with you forever. (The framework’s source is open and forkable; the canonical Locara codebase has restricted commit access — anyone can read, fork, or PR, but only a small trust group can ship official releases. This is how we keep the trust roots safe without closing the project.)
Why now
The 2024–2026 generation of small open models — Qwen, Llama, Gemma, Whisper-large-v3, GLM-OCR — crossed the threshold where, for many useful tasks, local matches frontier. Apple Silicon’s neural compute and unified memory makes these models genuinely fast.
The models work. The hardware is here. What’s missing is the connective tissue: how a developer ships, how a user installs, how a community trusts.
That’s what Locara is.
What’s next
We’re building this in public, slowly. The spec is written. The reference apps are coming. The registry comes after that.
If this resonates, follow along. If you want to build, the framework will be ready when it’s ready. If you want to build something specific and need a hand, get in touch.
— The Locara project
This is a draft. The voice is right. The story will tighten.