Mentra Roadmap Update: Moving to Miniapps on the Phone | Mentra

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 miniapp, and back again

Miniapps 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...