Mentra Roadmap Update: Moving to Miniapps on the Phone
Over the last year, MentraOS has grown because of this community.
Developers have built apps, tested new ideas, given us direct feedback, debated our architecture, and helped us understand what smart glasses software actually needs to become. At the same time, we’ve been working closely with several OEM partners preparing to launch with MentraOS later this year and next year. Their feedback has been strongly aligned with what we’ve heard from the community: the platform needs to become more local, more reliable, lower latency, more private, and easier to integrate deeply.
Thank you to everyone who has helped us get here and shared feedback on MentraOS. We love that this has already become a community-driven project, with thousands of developers, users, and companies helping shape the future of smart glasses.
In this note, we’re outlining the next phase of that journey.
How MentraOS works today
Today, MentraOS apps run in the cloud.
The current architecture looks roughly like this:
Glasses → phone → Mentra cloud relay → developer cloud app, and back again
This model let us move quickly. It let MentraOS support multiple pairs of smart glasses, reach tens of thousands of downloads, and let developers ship apps without building native mobile integrations. It helped prove that smart glasses need an app platform.
But the current architecture has limits. Because apps run in the cloud, the phone needs a relay to connect the glasses to those apps. Otherwise, every app would need its own streams for audio, display, camera, and control, which would quickly get bad for data usage, battery life, latency, and reliability.
The relay solved an important problem, but it also created new tradeoffs. A platform centered around Mentra cloud infrastructure raises concerns around control, privacy, enterprise deployment, and OEM ownership. We have done a lot of work to improve those issues, but they are not fully solvable with the current architecture.
A simple example is a button press. If an app needs to respond to a hardware button on the glasses, that event goes from the glasses, to the phone, to the Mentra cloud relay, to the developer’s cloud app, and back again. Even in a good case, that can mean hundreds of milliseconds before the app can respond. For interaction on smart glasses, that is not good enough.
The new architecture: apps run locally on the phone
A core requirement for MentraOS is that smart glasses should be able to run multiple apps at once, even though the glasses only have one active connection to the phone.
That means apps cannot each connect to the glasses independently. If every app owned its own Bluetooth connection, you would be limited to one app at a time, and every developer would need to rebuild the same glasses integrations.
MentraOS 3.0 solves this by putting all apps inside one phone host app.
OEM apps that ship with MentraOS include the Mentra runtime. If an OEM releases glasses powered by MentraOS, their mobile app can host the same local runtime as the Mentra app. As a developer, your app runs locally inside that runtime and can work across MentraOS-supported glasses.
The Mentra app is our open source, hackable host app for building, testing, and distributing apps across supported glasses.
The new architecture looks roughly like this:
Glasses → phone app → local mini app, and back again
Mini apps will be built with the Mentra Miniapp SDK. They run locally on the phone, inside the host app, and use the Mentra runtime to control glasses input and output, app lifecycle, permissions, storage, networking, and native phone features.
For developers, this means:
- much lower latency
- better reliability
- local-first app behavior
- direct connection to your own backend
- local data storage
- better privacy and compliance options
- less dependency on Mentra cloud infrastructure
- one app that can work across multiple glasses supported by MentraOS
This is the architecture that makes MentraOS feel like an operating system for smart glasses: fast, local, extensible, and built for deployments that matter.
Mentra Bluetooth SDK
As more companies have started deploying and experimenting with MentraOS, we have heard a consistent need from businesses, OEMs, and enterprise teams: some deployments need direct app control, on-premise support, offline behavior, stricter compliance paths, or deeper integration into an existing mobile app.
For that, we’ve modularized MentraOS so the Bluetooth connection layer between the phone and glasses can be used independently.
That is now available as the Mentra Bluetooth SDK.
We believe direct access should be official, documented, and compatible with the broader MentraOS ecosystem, not something teams have to reverse engineer.
The Bluetooth SDK is best for:
- B2B deployments
- single-purpose applications
- direct integrations into an existing mobile app
- cases where one app controls the glasses directly
The tradeoff is that with the Bluetooth SDK, you own everything above the Bluetooth connection. You need to build or integrate your own ASR, TTS, AI layer, glasses scanning and connection flow, app distribution, permissions, lifecycle handling, and power-saving behavior.
With the Mentra Miniapp SDK, those platform pieces come out of the box. It is usually 3–10x faster to build on the Miniapp SDK, and your app can still run across the MentraOS ecosystem.
You can start here:
https://github.com/Mentra-Community/Mentra-Bluetooth-SDK-Starter-Kit
For most developers, the Mentra Miniapp SDK is the better path. It gives you the app platform, not just the connection layer.
The Bluetooth SDK gives you direct control for single-purpose deployments.
The Mentra Miniapp SDK gives you the platform for building apps.
Roadmap and migration
For Mentra Live camera apps, we are ending active support for the current cloud SDK on June 12.
Going forward, developers building direct camera or B2B integrations for Mentra Live should use the Mentra Bluetooth SDK, available now for Android, iOS, and React Native.
For display glasses, we will continue supporting the current cloud SDK for roughly the next month.
By roughly the end of July, the official SDK path will move to the Mentra Miniapp SDK. Existing cloud apps are not being immediately shut off, but the cloud runtime will no longer be the supported path. We will not continue adding features to it, and new apps should be built on the Miniapp SDK.
For anyone with an existing app, we will publish a detailed porting guide and provide support if you hit issues during migration.
Why this is better for developers, users, and businesses
This change is about making MentraOS a better platform for you to build and deploy your apps.
Apps built with the Mentra Miniapp SDK will be faster, more reliable, more private, and more powerful. Developers will be able to build apps that feel instant, work closer to the edge, store data locally, connect directly to their own backend, and still distribute through the Mentra ecosystem.
Users get apps that feel more responsive and dependable. Businesses get a cleaner path for privacy, compliance, offline behavior, and direct integration into their own systems. OEMs get more control over their own user experience while still giving developers one runtime that can work across many different glasses.
This is the version of MentraOS the community has been asking for: local apps, lower latency, better reliability, and one SDK for the next generation of smart glasses.