--- title: How third-party smart-glasses apps are distributed seoTitle: How are third-party smart glasses apps distributed? description: "Smart glasses don't have one app store. The app-model taxonomy — companion mobile app vs. an app that runs on the glasses (native or web) — and why a single platform (Meta) offers two entirely separate developer systems: DAT and Ray-Ban Display Web Apps." type: guide platform: all related: - /docs/ecosystem - /docs/vendors/meta - /docs/concepts/architecture --- 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](/docs/vendors). ## 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. | | **Device Access Toolkit (DAT)** | **Display Web Apps** | |---|---|---| | What you build | A native **iOS/Android app** | A **web app** (HTML/JS, standard web APIs) | | Where your code runs | On the **phone**; glasses are the peripheral | **On the glasses** (a WebView on Ray-Ban Display) | | Which glasses | Every Meta model (camera + audio); native display on Ray-Ban Display | **Ray-Ban Display only** | | Capability focus | Camera, microphone, audio, plus a native display tree (`glasses.display.*`) | Display, input, sensors, location, local storage (web APIs) — no camera/audio path | | How you deploy | Publish/sideload the mobile app | **Host it over HTTPS at a public URL** | | How a user adds it | Register the integration via the Meta AI app (release-channel tester) | **Meta AI app → App Connections → Web Apps → Add → your URL** | | Distribution today | Release channels (invited testers); public publishing partner-gated | **Share a link** (recipient needs Developer Mode); appears in the glasses app grid | | Docs / repo | `meta-wearables-dat-*` | `meta-wearables-webapp` (separate) | 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](/docs/vendors/meta#distribution-state-2026-07) 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](/docs/vendors). ## Related - [The third-party smart-glasses landscape](/docs/ecosystem) — the platform comparison matrix - [Meta smart glasses → distribution state](/docs/vendors/meta#distribution-state-2026-07) — the concrete DAT mechanics - [Architecture](/docs/concepts/architecture) — how the phone-app-plus-glasses model fits together