An app store that adapts to you
Möbius grew an app store. Install an app by pasting a URL, tweak it by asking, run it offline, save it to your home screen. The store is the on-ramp; the bigger shift is the agent growing a cross-app personal system that adapts to you over time.
TL;DR. Möbius grew an app store, and the store is the on-ramp. The bigger idea is that the agent grows a cross-app personal system around you, rather than a heap of one-off apps. Apps share a storage layer and a permission model, so the agent can compose them and reshape the whole thing around you over time. You install by pasting a URL, tweak by asking, run offline, save to your home screen, and break things cheaply because the system is built around recovery.
- The store is a curated starter pack rather than an open registry. A published app is a public repo with a
mobius.jsonand anindex.jsxentry point, and sharing one means sharing a URL. - The bigger idea is one connected system. Shared storage and a shared permission model let the agent compose your apps and grow them around you.
- Updates are URL-keyed and three-way merged. Bump the version upstream, the store shows "Update available", and reinstalling merges the new code with any tweaks you made and keeps your data; on a real conflict the old version keeps running while the agent resolves it with you.
- Recovery makes breaking cheap. Atomic installs that cannot half-land, a
/recoverroute, and a git history of your whole instance. - Offline plus home screen. Apps install to your home screen as standalone PWAs and keep working with no network. Writes queue and sync when you reconnect.
- The honest edges. The full cross-app compose flow and per-app rollback are not built yet, and I say so where it matters.
This is the third post about Möbius, a personalized AI agent you self-host. The first post is about the agent building the tools you ask for and editing the interface around them. The second is about the loop the developers use to make the agent better at building them. This one is about what those apps became once they stopped being one-offs and grew a place to live.
Across the series, Möbius is built around one goal, being genuinely useful to you. The app store gives that goal an on-ramp. Because your apps share a storage layer and a permission model, the agent can compose them and reshape the whole system around how you actually live.
The primitives that make this work are small on purpose. You can inspect the source. The smallest app is one source file and a small manifest the agent (or you) can rewrite in place; larger apps add only a few more files. An update is a new version of those files. Installing is a transaction the platform can roll back. Some of those pieces are solid; others are still plans.
The store starts as a starter pack
The app store is itself a Möbius app. On first boot the platform installs it through the exact same path you use for everything else, which keeps the install channel the same for the store and every other app.
.tex as you watch it typeset. 
Today it is a hand-picked set. You can install from outside it:
| App | What it does |
|---|---|
| News | A daily AI-curated digest. A background job wakes at 10:00, runs the agent with web search only, and writes the morning’s report. |
| Workout | A natural-language workout logger. Type what you did, like “3×5 deadlift at 100kg”, and it parses the sets. No agent, no cloud, all on your device. |
| Atlas | A draggable 3D globe; tap the countries you have been to and the count climbs toward 195. |
| Memory | An Obsidian-style graph of what the agent has learned about how you work, the lessons worth keeping, made browsable. |
| LaTeX | An Overleaf-style editor with a file drawer and a real tectonic engine; an AI sub-agent writes .tex while you watch it typeset. |
| Reflection | Overnight, the agent reviews the day’s work and leaves a one-page morning brief, so it starts the next day a little sharper. |
Each of those is a public git repo in the mobius-os organization, named app-<something>, with a mobius.json manifest, an index.jsx entry point, and a 1024×1024 icon. The smallest apps are that single file; larger ones pull in a few more, but the manifest plus an entry point is the whole contract. An app the agent builds just for your own instance needs none of this; the manifest only matters once you want to publish one. Publishing means making a repo public and sharing its manifest URL. The list above is a starter pack I picked. The install button takes any manifest URL you paste, and the store warns and lets you continue when it comes from a host it has not seen before.
index.jsx the app itself, one React component the agent wrote mobius.json the manifest: name, version, what it may reach icon.png a 1024×1024 icon job.jsoptional a background job, if the app has one What “install” actually does
When you tap Install, the work happens on the server in one transaction. The platform fetches the manifest (because that URL can point anywhere, it refuses private networks and cloud metadata endpoints and re-checks every redirect), then the app’s source, icon, background job, and any starter data it ships. It compiles off to the side and goes live only after the database row commits, so only a complete app can open. If anything fails, the whole thing rolls back and leaves nothing behind.
That all-or-nothing property lets an update patch your app in place, and it lets recovery treat any break as something to undo.
Updates keep your data
An installed app remembers the URL it came from, and that URL is its identity. The name and version can change; the URL is what ties your copy to upstream. The store periodically checks each app’s upstream manifest, and when the version there is newer than yours it shows an “Update available” pill.
Tapping Update reinstalls from the same URL. The backend switches into update mode and patches the parts that should change (the code, description, permissions, icon, schedule), then recompiles and remounts. Your data stays out of that patch. Starter data only seeds missing keys, so an update can ship new defaults without trampling your logged workouts, your visited countries, your notes.
mobius.json I am glad I built this part. Each installed app is its own git repo, so an update runs as a three-way merge. It avoids the blunt overwrite path. If the upstream author ships a new version and you have asked the agent to customize your copy, the merge carries your edits forward. When the two genuinely collide, your old version keeps running while the agent opens a chat to work the conflict through with you, so a bad merge leaves your working app alone. The smarter merge is still ahead, the one that reconciles by intent instead of by lines of text. The plumbing it would run on is already here.
Recovery makes breaking cheap
Recovery works the way it does in the first post. The /recover page renders outside the shell so it loads even when the shell is broken, and your whole instance is a git repo the agent can walk back when you tell it what went wrong. The store adds one fallback of its own. Installs are atomic, so a failed or broken update lands fully or rolls back; the previous working version is restored from a snapshot, and a deleted app can be reinstalled from the same URL and come back with its data. A one-click “roll this app back to last week” button still needs building, so recovery today uses reinstall, /recover, and that git history.
Your home screen works with or without Möbius
An app you install also lives outside the chat. Each one is served at its own address, with its own web manifest and icon, as a standalone progressive web app. Add it to your phone’s home screen and it launches like any native app, full screen and without the drawer or chat. Workout opens straight to today’s session; Atlas opens to the globe.
Run standalone, an app vendors its own copy of React from your server because it runs without the Möbius shell that normally supplies shared libraries. Everything it needs comes from your server, which lets it render with the network off.
Offline work catches up
“Works offline” is easy to claim and hard to land on a phone. This part got the most unglamorous engineering, and it holds.
When an app is marked offline-capable, a service worker caches the shell and the app’s code, so opening it with the network off renders the real app. Storage works offline for every app, including ones without the offline-capable marker. Reads come instantly from a local cache and refresh in the background; writes you make offline queue in a local outbox and sync the moment you reconnect.
Your data survives a dead connection, and I have checked it on a real phone after the usual desktop-pretending-to-be-a-phone pass. Two operations stay online by design (a cached listing could resurrect things you deleted, and chat is online-only). Conflicts are last-write-wins per item, which is right for a single owner and needs more thought for a shared one.
One system made from small apps
Once your apps share a storage layer and a permission model, the agent can build across them. It can pull data from one app into another and build new tools on top of both.
Tweaking an app you have is real and easy. Open it, tell the agent what you want different (a darker palette, a new column, a weekly view instead of daily), and it edits the app’s source in place and recompiles. You skip the fork button and project setup; the app is one file, and the agent edits that file the same way it would write a new one.
Composing several apps into a new one is the next rung, and I still have to build the full flow. The idea is a health dashboard that reads across your workout tracker, calorie log, gratitude journal, and dream diary, then surfaces the metrics you actually care about. The backend already has the pieces. An app can declare that it reads another app’s data, and the backend enforces the handshake on both sides. But almost nothing uses it today, each app’s storage is scoped to itself by default, and the product still lacks a “build me an app that unifies these” flow. When I build it, this is the example I will build it against.
The two apps I have barely touched here, Memory and Reflection, drive most of this adaptation. Memory records the lessons worth keeping from what the agent has learned about how you work. It avoids profile-building and focuses on what works. Reflection is the overnight job that reviews the day’s work and feeds new lessons back in. Together they are how the agent gets sharper at fitting your system to you over time. I cover them in your agent improves itself.
Building these apps well leans on the same two levers as the rest of Möbius, both from the harness post. One is the introspection loop that tightens the agent’s instructions. The other is a design phase where I drive with Claude and pressure-test with Codex before a line of the app is written, since the build is cheap and the leverage is in the design.
Philosophy under all of it
Code empowers the agent; policing is a last resort. When the agent needs to install an app, write to your shell, or schedule a job, the platform’s job is to make that possible and reversible, with second-guessing reserved for failures that would be silent and catastrophic. Validators show up only in those cases; everywhere else the lever is a clear contract and a good recovery path.
Low floor, high ceiling. A personal tracker that stores a little data and works offline should take one sentence, and an app that wants its own local database is free to reach for one. The one real wall right now blocks arbitrary network connections from apps to outside services, a deliberate security line I have not yet built a careful door through.
You own all of it. Your data is on a server you control. Your apps are files you can read. Your shell is a git repo you can revert. The system is tuned for usefulness. Engagement hacking is the wrong goal here. Across this series, I have been arguing for an assistant that builds the thing you asked for and then leaves you with software you actually own.
After the starter pack
An app store was the obvious next thing once the agent could build apps reliably. With a store, Möbius becomes a system where the unit of software is small enough for the agent to write and repair, installing and breaking are reversible, and “I wish I had a thing that…” becomes a thing you can open on your phone.
The apps above are a starter pack; the interesting ones are still ahead. If you deploy an instance and build something, or tear one of these apart and rebuild it as something better, that is the use case I care about, and I would love to see it.
The source is on GitHub, the app repos are under mobius-os, and the deploy button gets you a working instance in about three minutes.