If you have browsed the app store recently, you may have noticed that the apps we highlight are all JS apps: they open in your browser (or in the mobile app), you pick your robot, and they just run. No install step, no waiting, no disk space used on the robot.
This is a deliberate platform decision we converged on months ago, and this article lays out the full reasoning. The short version: we want the Reachy Mini experience to be seamless for everyone, not just developers - and we want creating an app to be as simple as describing it in a prompt.
Python apps are not banned and not going away. They keep working, they remain installable through the desktop app, and they stay searchable in the store behind the "Python apps" filter. What changed is the default path we promote for new apps.
Why JS apps are the default
Nothing to install, ever
A JS app is a web page. "Open the app, pick your robot, it works" is the whole user story - on desktop, on mobile, for everyone. Python apps necessarily add another one: download to the robot, resolve dependencies, wait, sometimes fail, then manage updates and disk space. Two formats force every user to understand a difference they have no reason to care about.
Always up to date
A JS app served from a Hugging Face Space is up to date for every user on the next load. An installed Python app needs version management, an update mechanism on the robot, and support when any of that goes wrong.
Safe by default
A Python app is third-party code running natively on the robot: full network access, filesystem, daemon API - no sandbox. A JS app lives in the browser sandbox, and every capability it gets from the robot can go through an explicit permission. As the catalog grows and apps come from everywhere, that difference matters more every month.
Built for vibe-coding
Our goal is that you can describe an app in one prompt and get something that runs immediately. That is realistic with JS: one self-contained file, zero dependencies, no environment. Python's env/deps/deploy loop fights this at every step.
Zero footprint on the robot
Storage on the robot is finite. Every Python app brings a virtualenv, often heavy dependencies (torch, opencv, numpy - duplicated across apps), and growing caches. Managing that at scale means quotas, "disk full" errors and cleanup screens. A JS app takes zero bytes on the robot, and the experience stays simple because there is nothing to manage.
Apps that do not rot
The JS app-robot contract is additive by design: we add commands, we never remove them, and the SDK major version is pinned on the CDN. An app written today keeps working as the robot software evolves, with no action from its author.
Installed-code ecosystems age differently, through no one's fault. We already see it in the catalog: apps untouched for months, hard-pinned dependencies, unbounded version ranges that break on a fresh install, apps depending on unpinned SDK versions. Nobody did anything wrong - this is just what happens to installed code over time.
"But my app needs Python features"
We audited the top 50 apps in the store, and nothing in there is structurally impossible in JS. The bulk of real usage is conversation or conversation plus moves, and here is what is coming to close the remaining gaps:
- Conversation as a service. The conversation engine is moving into the robot's daemon and will be exposed through the JS SDK: personalities, speech, interruption, transcripts - available to any JS app without reimplementing a voice pipeline.
- Custom tools from JS. The most common reason to fork the conversation app in Python is to add a tool (web search, Home Assistant, a museum guide). The SDK will let a JS app declare a tool and answer its calls directly.
- Raw audio for custom pipelines. If you want your own voice backend (local models, other providers, wake words), the robot works as an audio hub - microphone in, speaker out - while your app owns the brain. This pattern already works and is becoming an official SDK contract.
- Local network access. Browsers cannot reach LAN services directly (CORS, mixed content). A daemon-side fetch primitive, tunneled over the robot connection with per-host permissions, will cover the home-automation use cases - more safely than native code with unrestricted LAN access.
- Autonomous execution. Browser tabs throttle background timers, and the worker-clock pattern already handles that. For the one true gap - the robot running an app with no phone or computer around - we are experimenting with running JS apps directly on the robot, daemon-side, so one app format covers both cases.
What this means for Python app authors
Your app keeps working. It stays in the store, installable through the desktop app, and users who enable the Python filter will find it. We are not removing anything.
If you want your app to reach every user - including the mobile app, where installs do not fit the experience - the path is the JS SDK. Most apps port smaller than their Python version, and once the conversation service lands, the most common patterns become a few SDK calls.
We know a rewrite is a real ask when you have already invested in a Python app. That is exactly why the store keeps both visible today, and why we are prioritizing the SDK primitives above before anything else.