--- title: "How open is smart-glasses development?" seoTitle: "Smart-Glasses Development Openness: The Full Spectrum" description: "A mental model for the openness spectrum in smart-glasses development — SDK availability, license, build-time gating, and publishing gating — with today's platforms placed on it." type: guide platform: all related: - /docs/ecosystem - /docs/ecosystem/distribution - /docs/ecosystem/ai --- "Is this platform open?" is the wrong question. It compresses at least four independent decisions into one word, and every smart-glasses vendor answers them differently. A platform can hand you a free, permissively-licensed SDK and still refuse to let you ship to real users. Another can gate the SDK behind a paid program yet let you publish to a public store in a weekend. If you pick where to build on a single "openness" vibe, you will be surprised at exactly the wrong moment — usually the day you try to put your app in someone else's hands. This page gives you the model we use to reason about it, then places today's platforms on it. ## Openness has two phases, not one The single most useful distinction: **build-time openness and ship-time openness are separate, and they don't correlate.** - **Build-time** — Can you get the SDK, write code, and run it on the hardware? This is where the SDK license, price, and the "who is allowed to build" gate live. - **Ship-time** — Can you get that code into an end user's hands, and how wide can that audience be? This is a completely different gate: a store, a review pipeline, a partner agreement, or nothing at all. [Meta](/docs/vendors/meta) is the canonical example of the split: the SDK is real and documented, but the preview program is invite-gated at build time *and* publishing is partner-gated at ship time. [Vuzix](/docs/ecosystem/platforms/vuzix) is the opposite corner — open SDK, and because the Z100 is a display-only Bluetooth peripheral, you ship an ordinary phone app through Google Play or the App Store with no glasses-specific gate at all. [Even Realities](/docs/ecosystem/platforms/even-realities) splits the other way: a genuine public web/TypeScript SDK, but first-party onboarding is application-gated and its first-party store is manually reviewed. Hold those two phases apart and the rest of the model falls out cleanly. ## The four dimensions Score any platform on these four and you have its real posture: 1. **SDK availability & cost** — Is there a public SDK you can download *today* without an invite? Free, paid, or application-gated? 2. **License** — Permissive open source (BSD / MIT / Apache-2.0), or a proprietary closed binary (an AAR, an xcframework, a signed runtime)? This governs whether you can fork, self-host, audit, and survive the vendor changing direction. 3. **Who-can-build gating** — Anyone; a dev-mode toggle; a paid developer program; a light application form; or invite/partner-only. 4. **Publishing gating** — Self-distribute with no gatekeeper; an open store with light review; a curated/manually-reviewed store; phone-store-only (ordinary app review); partner-gated; enterprise-MDM-only; or no path at all. A platform that is open on all four is a place you can move fast and keep control. A platform that is open on (1) and (2) but closed on (4) is fine for prototypes and demos and a trap for a product. ## The spectrum From most open to most closed. The tiers are about *net* freedom to build and ship to real users — a permissive license pulls a platform up, a publishing wall pushes it down. ### 1. Fully open — OSS SDK, self-distribute, no gatekeeper You get open-source SDKs, you keep the keys, and you distribute your own host app, so there is no one to ask permission of at either phase. - [Brilliant Labs](/docs/ecosystem/platforms/brilliant-labs) (Frame & Halo) is the most open in the category: OSS multi-language SDKs (BSD-3/MIT), an on-device Lua VM over plain BLE, a first-party IDE, an open-source reference host app, open hardware/firmware, and an OSS BYO-key/self-host assistant. You ship your own app; nobody gatekeeps either phase. - MICROOLED ActiveLook — an open BLE SDK (Android + iOS + a generic API) you embed in your own app, no gatekeeper. - Omi (OmiGlass) — open SDKs (Python, Swift, RN, Expo), full AI access with BYO keys or local models, an app marketplace *and* open GitHub self-distribution. - Mentra (MentraOS) — an MIT TypeScript SDK (`@mentra/sdk`) with a live store and web-link install. Notably it is *cross-vendor*, which is why it also shows up as the ungated path on hardware whose first-party channel is narrower (see Even Realities and Vuzix below). ### 2. Open to build and ship — permissive-enough SDK, open publishing, proprietary core Publishing is genuinely open, but the SDK itself is proprietary or carries a cost/hardware gate. Net freedom is still high. - [Snap Spectacles / Specs](/docs/ecosystem/platforms/snap) — a free public SDK (Lens Studio 5) plus an independent WebXR path, and public Lens Explorer distribution with a narrow ~2–3 day review. Camera/mic/location + internet *is* publicly publishable via Transparent Permissions, including BYO-AI Lenses through the Remote Service Gateway. The only real wall is hardware access: a paid, US-only $99/month developer program (or a purchased pair from fall 2026). - [Vuzix](/docs/ecosystem/platforms/vuzix) — a free, publicly downloadable native SDK (Android + Apple) plus MIT-licensed MentraOS; a Z100 app is an ordinary phone app in the normal stores. - [Solos](/docs/ecosystem/platforms/solos) — a paid but public SDK (standard iOS/Android, commercial use allowed) with a light application step; ship-time is wide open through the normal app stores. Audio-first, no HUD. - Iristick — a native Android + iOS SDK; distribution through Google Play and the App Store. - [INMO (Air3)](/docs/ecosystem/platforms/inmo) — a standalone Android 14 device that ships internationally with the Google Play Store, plus a Unity SDK; publishing mixes an open Play path with a curated first-party Air3 store. Qualified openness — the real API reference sits behind a login-walled doc. ### 3. Dev-mode / sideload — open to build, no consumer publishing surface You can build freely and run on-device via ADB/sideload, but there is **no public store or review pipeline** to reach a wide audience yet. Great for internal tools and demos; you own the distribution problem. - [RayNeo](/docs/ecosystem/platforms/rayneo) — an open, standard-based build path (MIT OpenXR Unity ARDK + native Android ARDK, no invite gate), but a real developer-mode unlock and delivery only via ADB or community catalogs (TapLink/GBox). No public app store. - [Rokid](/docs/ecosystem/platforms/rokid) — a registration-free suite with four parallel dev axes; the on-glasses AIUI runtime (JSAR) is Apache-2.0 while the native SDKs are closed AARs. Sideload works today (phone app, WebUSB, community stores); a first-party native store is still emerging. - XREAL — a Unity SDK; sideload / OTA via ControlGlasses. - VITURE — a cross-platform + Unity SDK; distribution through host-platform stores. - Epson Moverio — a native Android AAR SDK; sideload APK, no store. - Lenovo ThinkReality A3 — Snapdragon Spaces (OpenXR, Unity/Unreal); sideload, Google Play, or Lenovo-managed. ### 4. Application- or partner-gated build The SDK exists but you must be approved to get it or to onboard through the first-party channel. - Jorjin J-Reality — the J7 SDK is gated by an application form; distribution is partner/ODM. - [Even Realities](/docs/ecosystem/platforms/even-realities) *(first-party track)* — a public SDK, but developer onboarding is a pilot/early-access application and the Even Hub store is manually reviewed. The ungated escape hatch is MentraOS + raw-BLE community tooling, which supports both G1 and G2 with no Even gate. ### 5. Invite / partner preview — gated at both phases - [Meta](/docs/vendors/meta) — a DAT companion SDK and Display Web Apps, but an invited-tester preview at build time and partner-gated publishing at ship time; Meta AI is closed to third parties. The most-watched platform, and among the most gated. - [Android XR](/docs/vendors) — the Jetpack XR SDK is public, but the platform is GA-gating with Gemini as the assistant; treat it as staged-rollout rather than freely shippable today. ### 6. Enterprise-managed Open enough to build, but distribution assumes a managed fleet — the "public store" is an MDM console, not a consumer channel. - RealWear — a standard Android SDK plus WearHF/WearML; RealWear Cloud + APK sideload; the Ari assistant is end-user-facing, BYO-AI for your own apps. - DigiLens (ARGO) — a DigiOS SDK (AOSP 12) + Unity/Spaces; sideload + enterprise MDM; Gemini voice via Google Cloud. - ThirdEye Gen — Android (Java) + Unity + a VisionEye SLAM SDK; you upload APKs to a ThirdEye App Store dashboard. - Emteq Labs (OCOsense) — a Unity SDK + Python LSL client shipped as a developer kit via GitHub/UPM; a specialized affect/expression sensing platform rather than a general app target. ### 7. Closed / none - [Apple](/docs/vendors) — no third-party glasses SDK yet. There is nothing to build against. ## The openness map at a glance | Platform | SDK license | Who-can-build gate | Publishing gate | |---|---|---|---| | [Brilliant Labs](/docs/ecosystem/platforms/brilliant-labs) | OSS (BSD-3/MIT) | None | Self-distribute, none | | ActiveLook | Open BLE SDK | None | Embed in your app, none | | Omi | OSS | None | Marketplace + GitHub | | Mentra | MIT | None | Open store + web-link | | [Snap](/docs/ecosystem/platforms/snap) | Free, proprietary | Paid $99/mo (or buy hardware) | Open Lens Explorer, ~2–3 day review | | [Vuzix](/docs/ecosystem/platforms/vuzix) | Free native + MIT MentraOS | None | Ordinary phone stores | | [Solos](/docs/ecosystem/platforms/solos) | Paid, public | Light application | Ordinary phone stores | | Iristick | Native, public | None | Google Play + App Store | | [INMO](/docs/ecosystem/platforms/inmo) | Unity + native | Buy device (login-walled docs) | Play + curated Air3 store | | [RayNeo](/docs/ecosystem/platforms/rayneo) | MIT OpenXR + native | Dev-mode unlock | Sideload / community catalogs | | [Rokid](/docs/ecosystem/platforms/rokid) | Mixed (AIUI Apache-2.0; native closed) | None | Sideload; native store emerging | | XREAL | Unity SDK | None | Sideload / OTA | | VITURE | Cross-platform + Unity | None | Host stores | | Epson Moverio | Native AAR | None | Sideload, no store | | Lenovo A3 | Snapdragon Spaces | None | Sideload / Play / managed | | Jorjin | J7 SDK | Application form | Partner/ODM | | [Even Realities](/docs/ecosystem/platforms/even-realities) | Public web/TS (+ MentraOS) | Pilot application (first-party) | Curated store (or self-host BLE) | | [Meta](/docs/vendors/meta) | DAT companion, closed AI | Invite preview | Partner-gated | | [Android XR](/docs/vendors) | Jetpack XR | GA-gating | Staged | | RealWear | Standard Android | None | Cloud/MDM + sideload | | DigiLens | DigiOS (AOSP 12) | None | Sideload + MDM | | ThirdEye | Android + Unity | None | ThirdEye dashboard store | | Emteq | Unity + Python | Dev kit | GitHub/UPM | | [Apple](/docs/vendors) | None yet | — | — | ## Where the phone-companion model sits A cross-cutting factor the table hints at: **who runs your code changes the gate.** When the glasses are a display-or-audio peripheral and your app runs on the phone, publishing collapses to ordinary phone-store review — which is why display-only peripherals like Vuzix and audio-only Solos land in the "open to ship" tier despite proprietary SDKs. When the app runs *on the glasses*, you inherit that device's store, sideload story, or partner gate. Extentos targets the phone-companion side of that line: the app lives on the phone, the glasses are the transport, and distribution rides the phone stores you already ship through. That inherits the ship-time openness of the peripheral model rather than a per-vendor on-glasses store — one reason the model ports across several of the vendors above. Which posture is right is a function of your product, not a universal ranking; the point of this page is to make the trade legible, not to sell one answer. ## What this means for choosing where to build Read the two phases against your actual goal: - **Prototype or internal tool, wide reach not required?** Tier 3 (sideload/dev-mode) is fine — [RayNeo](/docs/ecosystem/platforms/rayneo), XREAL, [Rokid](/docs/ecosystem/platforms/rokid). Don't over-index on the missing store; you don't need it yet. - **Consumer product you must ship broadly?** Weight **ship-time** heavily. Open publishing (Tiers 1–2) beats a great SDK trapped behind a partner gate. A brilliant SDK you can't distribute is a demo. - **You need to fork, audit, self-host, or outlive the vendor?** Weight **license.** Only Tier 1's permissive OSS (Brilliant Labs, ActiveLook, Omi, Mentra) gives you that guarantee; a proprietary AAR can change under you. - **You want to own the AI layer?** Openness of the *SDK* and openness of the *assistant* are yet another independent axis — Snap and Brilliant Labs invite BYO-AI, while Meta's assistant is closed and RayNeo's is closed and region-split. If AI is your product, check that axis explicitly, not the general openness label. - **Betting on a not-yet-open platform?** [Meta](/docs/vendors/meta), [Android XR](/docs/vendors), and [Apple](/docs/vendors) may open further; build with an eye on portability so a gate that opens late doesn't strand you. The honest summary: there is no single "most open" platform for every job. Rank the four dimensions by what your product actually needs to survive, score your candidates on each, and let the two-phase split — build vs ship — do the deciding. Each vendor page linked above carries the specifics for that scoring.