Glassly Miniapp SDK betaThe SDK is in beta, so its APIs may change before general availability.Developing on Mentra Live? We recommend using the Glassly Bluetooth SDK.The developer tools are available in the Glassly App under Settings → Miniapp Developer Settings.Share feedback with an in-app bug report, on Discord, or by email at [email protected].
A miniapp is a bundle that runs on the user’s phone: there’s no server to host, no domain, no uptime to manage. Distribution means producing that bundle and getting it installed. There are three ways to get a miniapp onto a device, from quickest to widest reach.

1. Dev install (you, iterating)

While you’re building, glassly dev serves your project over the LAN with hot reload. Scan the QR from the Glassly 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 Glassly 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.

2. Release install (sharing a build over LAN)

To put a real, installed build on one or more phones without going through the Glassly Miniapp Store, run:
This builds, packs, and serves the bundle behind a 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. Great for testers, demos, and dogfooding. Each install is logged in your terminal, and the server stays up so multiple devices can install from the same QR.

3. Store submission (reaching everyone)

To reach users who aren’t on your network, publish to the Glassly Miniapp Store. Sign in to the Developer Console once to create your developer org. The org owns a package prefix such as com.example, and every miniapp you publish must have a packageName under it (the scaffolder asks for the prefix so a new project starts out right). Then, from the miniapp folder:
publish reserves the package name for your org on first use and submits the release for review; the console shows its status. Make sure your miniapp.json is accurate before you publish: its hardwareRequirements decide which glasses can see your miniapp, its permissions drive the OS prompts users see, and its tagline and tags are the copy on your store card. If you only want the artifact, glassly pack writes the same build/<packageName>-<version>.zip without uploading it.

Store listing media

The store icon is the icon.png from your bundle. To ship screenshots with a release, add a store/ folder next to miniapp.json:
glassly publish uploads the folder with the release. After a release is published, the Developer Console’s miniapp page lets you replace the icon, add or reorder screenshots, and override the tagline, description, and tags without shipping a new version.
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

Bump version in miniapp.json for every release you distribute. The CLI names the artifact <packageName>-<version>.zip, and installed miniapps are stored per version (lmas/<package>/<version>/), so a new version installs cleanly alongside or over the old one.

Next steps

CLI reference

dev, release, pack, and publish in detail.

The manifest

Get permissions and hardware requirements right before you ship.