How third-party smart-glasses apps are distributed

There is no single "smart glasses app store," and that surprises almost everyone coming from phones. Distribution on smart glasses is downstream of one architectural choice — where your app runs, and whether it's native or web — and that choice differs not just by platform, but sometimes within one platform. Meta alone ships two entirely separate third-party systems. This page is the taxonomy; per-platform SDK detail lives on the vendor pages.

Two app models — plus a wrinkle

The dividing question is: does your code run on the phone (with the glasses as a peripheral), or on the glasses themselves? Everything about distribution follows from that. (A VR-style "headset app" — Android XR headsets like Project Moohan — is a separate device category, not smart glasses, and is out of scope here.)

1. Companion / extension app (runs on the phone)

You extend a mobile app that ships through an existing store; the glasses are camera, microphone, and speaker, reached over Bluetooth. The platform is expanding a broad third-party ecosystem around a large install base. Meta's DAT and Android XR are here.

On Meta (the Wearables Device Access Toolkit), this makes distribution a two-part problem, which is the crux of the confusion:

• The phone app ships through the channel you already know — Google Play or sideload/internal tracks on Android; TestFlight / enterprise / Ad Hoc on iOS.
• The glasses link is separate: the user must be authorized to register your integration with their glasses (on Meta, an invited tester in a release channel — see below). Installing the phone app is not enough on its own.

There is no standalone on-glasses app in this model — which is exactly why there's no store you submit a "glasses app" to.

Android XR takes the same broad-ecosystem approach on the Android app + Play foundation (developer program still gating on Google's GA). Coverage here expands as that program firms up.

2. An app that runs on the glasses

Here the app lives on the device, and distribution is its own path — not tied to a phone-app store. Two flavors:

• Web app (deploy a URL). Meta Ray-Ban Display Web Apps — you host a standard web app over HTTPS and the glasses load it. See the dedicated section below; this is the "separate Meta system" most developers don't know exists.
• Native standalone. Mentra and Even Realities — dedicated glasses apps built and distributed through the platform's own (often open) ecosystem, aimed at a different, more hardware-forward audience.

Meta's two systems: DAT vs. Display Web Apps

This is the part that trips people up: on Meta smart glasses, "build a third-party app" has two different answers, and they barely overlap.

They're complementary, not competing: DAT is the path for camera/voice/audio apps across the whole lineup; Web Apps is a fast, hostless-of-app-stores way to put an interactive UI on the Ray-Ban Display. Extentos builds on DAT — the native, cross-model, camera/voice/display path — not the Web Apps system.

Deploying a Ray-Ban Display Web App

The Web Apps flow is refreshingly light — no store, no review, no native build:

1. Host your web app over HTTPS at a publicly reachable URL (any host works; the glasses just load the page).
2. In the Meta AI app, enable Developer Mode, then go App Settings → App Connections → Web Apps → Add a Web App, give it a name and your URL, and tap Connect.
3. It appears immediately in your Ray-Ban Display app grid — pin it, launch it, drive it with swipes + pinch (a middle-pinch opens a Restart / Resume / Permissions menu).
4. Share it with the Share link button; anyone with Developer Mode is one tap from adding it.

Requirements today: Ray-Ban Display glasses on software v125+, Meta AI app v272+. Because there's no public store for Web Apps yet either, "distribution" is currently link-sharing behind Developer Mode — the same preview-era gating shape as DAT, by a different mechanism.

Meta DAT: the two distribution paths in practice

For the native (DAT) path — the one Extentos targets — distribution has two lanes:

• Release-channel distribution (works today). In the Meta Wearables Developer Center you create versions of your integration and assign them to release channels, then invite testers by email. Channel membership is what lets a user register your app with their glasses through the Meta AI app — there's no Meta content review. The phone app ships separately through your normal channels. iOS App Store publishing isn't supported yet (Meta's SDK triggers App Store rejection under Apple's MFi + privacy-manifest rules); TestFlight + release channels is the iOS path.
• Public publishing (partner-gated). Publishing so any user can register your integration without an invitation is limited to select Meta partners during the developer preview. Meta has said broader publishing is expected in 2026. There's no store-style storefront for glasses integrations today — users manage them in the Meta AI app.

The full mechanics, the launch-partner picture, and the required setup are on the Meta smart glasses page.

Why this matters for how you build

1. Pick the system before the framework. On Meta, "camera/voice app for any model" means DAT (native); "an interactive panel on the Ray-Ban Display" can mean either DAT's glasses.display.* or a Web App — different toolchains, different distribution. Choose deliberately.
2. Plan for tester enrollment, not a store launch. Across every platform's preview, go-to-market today is release channels / link-sharing behind Developer Mode — not "submit and wait for approval."
3. Keep app logic vendor-agnostic. The capability surface (camera, voice, audio, display) is stable across platforms even where the app models and distribution stories differ, so let the transport differ and keep your handler code portable. That's the vendor-portability model.

Related

• The third-party smart-glasses landscape — the platform comparison matrix
• Meta smart glasses → distribution state — the concrete DAT mechanics
• Architecture — how the phone-app-plus-glasses model fits together

Related