Platform overview
Build C plugins for glasses and Web plugins for phones with MemoMind. Develop with the public SDKs, test both sides in desktop Studio, then use the MemoMind App to install and verify your application on real glasses.
Start here#
The toolkit and each runtime#
Get the complete Plugin Open Platform toolkit and keep GlassSDK, PhoneSDK and Studio in the same working directory. The public SDKs provide APIs, examples and build tools. Desktop Studio is distributed as a prebuilt application for Windows, macOS and Linux.
| Component | How developers use it | Responsibilities |
|---|---|---|
| GlassSDK | Write glasses plugins in C and build them into .gmp files. | Use the firmware Host API for UI, buttons, IMU and messaging, and manage resources throughout the plugin lifecycle. |
| PhoneSDK | Write Web plugins in HTML, CSS and JavaScript and build them into .mmpkg files. | Pages run in the MemoMind App WebView and use the Bridge to access supported phone and glasses capabilities. |
| MemoMind Plugin Studio | Select built plugins, preview and test them together, and generate an installation QR code. | Run Web plugins and the glasses GMP simulator on your desktop, inspect logs, package the current selection into a unified ZIP, and serve it over the LAN. |
| MemoMind App and glasses | Connect plugin-compatible glasses, scan the Studio QR code, grant permissions and run the app on the device. | The App loads Web pages and transfers the GMP to the glasses. The glasses firmware validates the plugin format and API version before loading and running it. |
How plugins reach the glasses#
Start with a prebuilt example. After editing source code, build it before asking Studio to generate a ZIP of the current combination. The App stores the complete downloaded ZIP and extracts the components it needs at runtime.
Application types#
- PHONE · WEB
Primarily on the phone
For accounts, networking, long content, files and settings. The ZIP contains an MMPKG. The current App uses its built-in default bridge GMP at runtime, so you do not need to write a separate glasses program.
Read guide - GLASSES · C
Primarily on the glasses
For standalone games, sensor interactions and native UI. The ZIP contains a custom GMP and its build sidecars. The phone handles QR download and Bluetooth startup.
Read guide - PAIRED · WEB + C
Phone and glasses together
The phone provides a control page while the glasses run custom logic. One ZIP contains the MMPKG, custom GMP and its build sidecars, which run together according to the pairing declaration.
Read guide
Check capabilities and the user experience first#
Start with what the hardware supports, then decide which device should handle each interaction. Display, input, IMU, audio, networking and storage use different entry points. Your first project does not need to use every capability.
Roles and responsibilities#
| Role | Responsibilities | Boundaries to understand |
|---|---|---|
| Platform and tools | Provide public SDKs, desktop Studio, and App download, installation and execution capabilities. | Each runtime offers different capabilities. Verify tool checks, simulated execution and real-device behavior separately. |
| Plugin developers | Implement features and protocols, manage resources, complete testing, and maintain backend services, permission explanations and version information. | Take responsibility for your business results and data handling. Do not rely on unpublished APIs or treat a successful send as completion of a business operation. |
| Users and testers | Scan the QR code in the App to download the application, grant requested permissions, perform real operations and report issues. | Understand the application source and current state, and how to stop, exit or cancel unwanted operations. |
Development and device debugging workflow#
- Run an unmodified example to verify your tools and devices, then choose a C, Web or paired development path.
- Implement features, build with build.py, and verify UI, input and messaging in Studio.
- Generate a ZIP of the current combination and test core features and failure scenarios on a real phone and glasses.
- After changing source code or configuration, rebuild, repackage and scan again. Confirm that the device is running the latest version.
Desktop debugging and device testing boundaries#
- SDK headers and Web type definitions define the API entry points. Actual availability also depends on the matching App and glasses firmware. Handle unsupported features, disconnections, permission denial and exit.
- Studio supports desktop development. Verify features, display appearance, sensors and background behavior on a real phone and glasses.
Complete a repeatable device test#
Keep the complete ZIP generated by Studio and record the SDK, Studio, App and firmware versions together with the actual results. This stage is complete only when scanning the same ZIP reproduces the result.