Looking for the
@mentra/sdk cloud SDK? Apps used to be cloud-hosted
servers built with @mentra/sdk. They’re now built on-device with the Mentra
Miniapp SDK (@mentra/miniapp), which these docs cover. The older cloud SDK
docs live at mentraglass.com/legacy.Dev install (you, iterating)
While you’re building,mentra-miniapp dev serves
your project over the LAN with hot reload. Scan the QR from the Mentra App and
your changes reload on save. This is the inner loop; see the
Quickstart.
Dev mode is not an installation: the computer and CLI must remain running to
serve each miniapp’s runtime bundle. The Mentra App keeps a separate dev entry
for each manifest package name and caches its name and icon, so you can scan and
test multiple dev miniapps together. Rescanning the same package updates that
entry. Use a release install when you want the miniapp to run without the
computer. On a phone signed in to a company workspace, the Miniapp Developer
tools appear only if the workspace allows miniapp development.
A dev build runs as the package named in its miniapp.json, so it can stand in
for an installed copy of that package. Dev code is unsigned: the Mentra App runs
it in place of an unsigned install, but refuses it while the package is
installed from a bundle signed with a publisher key. Uninstall the miniapp from
the phone first, then scan again. session.auth works in a dev build the same
way it does for the installed miniapp.
Release install (local testing over LAN)
To put a real, installed build on one or more test phones on your local network, run:miniapp://release QR. Anyone
on the same network can scan it to install. The miniapp installs on the device,
runs offline, and persists across restarts: no laptop required once it’s
installed. This is intended for local testing, demos, and dogfooding; it is not
a supported distribution channel.
Each install is logged in your terminal, and the server stays up so multiple
devices can install from the same QR. The miniapp opens on the phone as soon as
it installs.
A release install is a fixed snapshot, like a React Native release build. After
each change, run mentra-miniapp release again and rescan. While you develop,
use mentra-miniapp dev instead: scan once, and every saved change reloads on
the phone.
Future distribution
In a future release, developers will upload miniapps through the Mentra Developer Console, and users will download them from the Mentra Miniapp Store. The Developer Console and Mentra Miniapp Store do not support Miniapp SDK distribution in MentraOS 3.0. The CLI can already produce the ZIP artifact intended for that future workflow:build/<packageName>-<version>.zip. Make sure your
miniapp.json is accurate before you
pack: its hardwareRequirements will decide which glasses can see your miniapp,
and its permissions will drive the OS prompts users see.
Camera, photo, and live-streaming features run through the on-glasses Bluetooth
stack, not a cloud server. See the Bluetooth SDK docs
for those workflows.
Versioning
Bumpversion in miniapp.json for every release build; it must be a semantic
version such as 1.2.0. The CLI names the artifact
<packageName>-<version>.zip.
The Mentra App installs a release only when its version is the same as or newer
than the installed one. Installing the same version again replaces it; an older
version is refused, whether it comes from a release QR or is bundled with the
Mentra App. To go back to an older build, publish it again under a newer version.
Signing
Signing is optional.mentra-miniapp pack --sign (or release --sign) embeds a
publisher signature in the bundle; see Signing
for keys and CI. The Mentra App follows the Android model: the installed signer
decides which bundles may replace a miniapp.
Uninstalling the miniapp clears its recorded key. The same rule applies to every
way a miniapp reaches the phone; there is no exception for first-party miniapps.
Next steps
CLI reference
dev, release, and pack in detail.The manifest
Get permissions and hardware requirements right before you build a release.