Meta smart glasses (Meta DAT)

Meta's smart glasses are the primary production target for Extentos. "Ray-Ban Meta" is one model line, not the platform — the hardware family as of 2026 spans five camera-and-audio models — Ray-Ban Meta (Gen 1 and Gen 2), Ray-Ban Meta Optics, Oakley Meta HSTN, Oakley Meta Vanguard, and Meta Glasses (the 2026 Meta-branded EssilorLuxottica line) — plus Meta Ray-Ban Display, the tier with a monocular heads-up display and the Meta Neural Band wrist controller. Third-party apps reach the glasses through Meta's Wearables Device Access Toolkit (DAT) — an Android and iOS SDK, currently in public developer preview, that exposes camera, microphone, and audio capabilities over Bluetooth, adds a display-rendering surface on Meta Ray-Ban Display, and ships a Mock Device Kit for testing without hardware. This page is the consolidated capability matrix, the distribution-and-development state, and the practical answer to "what can I actually build and ship for Meta smart glasses as a third-party developer in 2026?"

This is the Extentos build guide for Meta — how to build and ship with the Extentos SDK. For the neutral, cross-platform view of Meta as one vendor among many (comparable to Snap, Rokid, and the rest of the landscape), see Meta in the ecosystem.

TL;DR

The short version: a third-party developer can build rich photo/video/voice/audio apps for Meta smart glasses today using the public DAT preview — and, on the Display tier, render their own UI via glasses.display.*. Distribution today runs through Meta's release channels (invited testers), because public publishing is still limited to select Meta partners while the toolkit is in preview. Wake-word-engine access and Neural Band raw input stay Meta-only.

Extentos support

The same eleven rows appear on every vendor page, in the same order, so vendors can be compared directly rather than by reading three differently-shaped tables. Depth specific to this vendor follows below.

Compatible models

Extentos runs on every Meta smart-glasses model in market. Compatibility is determined by Meta's Wearables Device Access Toolkit — and DAT exposes the same camera, microphone, and speaker surface uniformly across every model, with Meta Ray-Ban Display adding the display surface on top. Frame styles within a model line don't change what Extentos can do; a Wayfarer-style and a Headliner-style Ray-Ban Meta have identical capabilities to Extentos.

DAT 0.8.0's device-type enum covers every model in market; Extentos surfaces them with these ids — rayban_meta, oakley_meta_hstn, oakley_meta_vanguard, rayban_meta_optics, meta_glasses, and rayban_display — and every one of them is simulatable in the browser simulator. Ray-Ban Meta Gen 1 and Gen 2 share the one rayban_meta profile — the generation changes camera quality and battery, not the capability surface — and frame styles within a line (including the Meta Glasses celebrity co-designed editions) don't carry their own identity.

What this means for the Display model

This is the most-asked compatibility question. Extentos runs on the Meta Ray-Ban Display the same as it runs on any other Meta smart-glasses model — your camera capture, voice triggers, audio playback, and hardware events all work identically. The wearer can use a Display-tier device with your Extentos-built app and get the full app experience.

On the Display tier you can render UI to the heads-up display through glasses.display.* — Meta's DAT opened a third-party display path, and Extentos exposes it as a declarative node tree in both SDKs, fully sim-testable on both; on-glasses rendering via DAT 0.8.0 is live on Android, with iOS on-glasses delivery in progress. (The local-media roots — image(photo:), video(clip:) — are Android-only; iOS uses URL-based media.) Input works like this: the wearer controls your display session with captouch gestures on the temple and EMG gestures on the Meta Neural Band, and DAT delivers those interactions to your app as abstracted tap events on your components (a button press, a selection). What you do not get is raw Neural Band access — no EMG stream, no gesture recognition API, no Band input outside a display session. See the display capability page.

One more distinction worth knowing: the polished full-screen experiences on Meta Ray-Ban Display — pedestrian navigation, WhatsApp, live captions — are Meta's own first-party system apps, not a partner slot that third-party apps compete for. Your app's surface is the display session, rendered through glasses.display.*. See distribution state for how partner publishing differs from what the public preview allows.

Compatibility approach

Extentos doesn't maintain a model-by-model verification matrix because the underlying SDK (Meta DAT) is the same across every Ray-Ban Meta and Oakley Meta variant. A capability that works on one model works on all of them, modulo hardware tier. New Meta-branded smart-glasses models should work without code changes as long as Meta keeps shipping them behind DAT — the consistent pattern since the toolkit launched in late 2025.

As of 2026-07 — model lineup and toolkit boundaries move with Meta's release cadence. Current state lives at Meta's Wearables Developer Center, the DAT GitHub repository, and the Meta smart-glasses product page.

What's in the Wearables Device Access Toolkit (DAT)

Meta DAT is the official public SDK for talking to Meta smart glasses from third-party Android and iOS apps. It is a developer preview (0.x versions — 0.8.0 as of 2026-06), open to any developer. The modules are mwdat-core / MWDATCore (registration, device discovery, sessions, permissions), mwdat-camera / MWDATCamera, mwdat-display / MWDATDisplay, and mwdat-mockdevice / MWDATMockDevice. As of 0.8.0 the toolkit plus the standard Bluetooth profiles expose:

Capabilities (public developer preview)

Capabilities NOT in the public toolkit

These are real Meta smart-glasses features but not third-party-accessible:

• The "Hey Meta" wake-word engine. The glasses run a dedicated low-power engine that is always listening for Meta AI's reserved phrases ("Hey Meta"). In DAT's model those are system-owned transactions, and the engine is closed to third parties — you can't register your own phrase with it, and you don't receive its triggers. A custom wake phrase is therefore a phone job: stream the normal glasses microphone over Bluetooth and match the phrase with phone-side speech recognition. That's exactly what Extentos's wake_word primitive and the listening_mode toggle implement for you.
• Raw Neural Band input. There is no EMG stream and no gesture-recognition API. On Meta Ray-Ban Display the Band is how the wearer drives your display UI, but DAT hands your app only the abstracted result (tap/selection events on your components) — never the gesture itself.
• Custom gesture recognition. Captouch behavior is system-defined: taps pause/resume a session, tap-and-hold stops it, and display apps receive tap events on components. You can observe all of that, but you can't map arbitrary tap/swipe patterns to your own semantics.
• Motion sensors (IMU). DAT 0.8.0 exposes no accelerometer, gyroscope, or magnetometer API. When Meta's docs say "sensors" they mean camera, microphone, and speakers.
• Listening while your app isn't running. Continuous mic capture works for as long as your integration is active (see audio architecture), but there's no way to install an always-on background listener that outlives your app — that privilege belongs to Meta's own wake-word engine.

Why these matter for app design: voice triggers in your app must be custom phrases recognized on the phone over Bluetooth audio — not "Hey Meta, my app, do X". The glasses are the microphone; the phone is the recognizer.

Distribution state (2026-07)

This is the part that surprises new Meta smart-glasses developers. DAT is in developer preview, and distribution reflects that: there are two paths, and the fully public one isn't open to everyone yet.

Path 1 — Release-channel distribution (works today)

During the preview, an end user can only register your glasses integration if they're enrolled as a tester. The flow:

• In the Meta Wearables Developer Center, you create versions of your integration and assign them to release channels.
• You invite testers by email. Each invitee needs a Meta account and accepts the invitation (testers manage theirs at wearables.meta.com/invites). Channel membership is what allows a user to register your app with their glasses through the Meta AI app.
• The phone app itself ships however you normally distribute: sideload/internal/enterprise tracks or Google Play on Android; TestFlight, enterprise, or Ad Hoc on iOS.
• iOS App Store publishing is not yet supported. Meta states this explicitly: the SDK currently uses Apple's ExternalAccessory framework, which leads to App Store rejection under the MFi program and privacy-manifest requirements. Meta plans to support App Store publishing in the future; until then, TestFlight plus release channels is the iOS path.
• There's no Meta content review of your app — the gate is tester enrollment, not approval. Distribution features require recent glasses firmware (v125+).

This is the path every non-partner Meta smart-glasses app uses today, and the one Extentos optimizes for.

Path 2 — Public publishing (partner-gated during the preview)

Publishing an integration so that any user can register it — no tester invitation — is limited to select Meta partners while the toolkit is in developer preview. There is no public submission flow yet; Meta has said the ability to publish to the broader community is expected in 2026. There's also no store-style storefront for glasses integrations today — users connect and manage integrations through the Meta AI app.

As of 2026-07 — distribution policy is the area most likely to evolve. Meta's annual Connect conference (typically September) is historically when developer-program expansions are announced.

Partner integrations (the "how did they get that" question)

A small set of launch partners built with DAT ahead of and during the preview, and they're the visible demos of what the toolkit can do:

• Twitch and Streamlabs (Logitech) — hands-free POV livestreaming from the glasses camera
• 18Birdies — real-time golf yardages and club recommendations by voice
• Be My Eyes and Microsoft Seeing AI — camera-based accessibility for blind and low-vision users
• L+R and Pixel and Texel — early design/engineering partners

Two things people often conflate with DAT partnerships, which are different programs entirely: Meta AI voice integrations (Spotify, Audible, and similar "Hey Meta, play…" experiences are Meta AI feature partnerships, not DAT apps), and Meta's first-party Display experiences (pedestrian navigation, WhatsApp, live captions on Meta Ray-Ban Display are Meta's own system apps — navigation, for instance, is Meta's, not a Google Maps integration).

The partners' distribution privilege is publishing reach — the capability surface they build on is the same public DAT you have. A new third-party developer should plan for the public preview toolkit plus release channels as of 2026-07.

Development state — what you can test with today

Building and testing an app for Meta smart glasses in 2026 is more accessible than the distribution story suggests. The development tools are open to everyone:

You don't need permission from Meta to start developing. Sign up at the Wearables Developer Center, drop the DAT SDK into your Android or iOS app (or use Extentos, which wraps it), and you can test today against Mock Device Kit, Extentos's browser simulator, or your own paired glasses.

The public-distribution gate is the hard one. Development is open.

Required setup for development

Concrete checklist for a third-party Meta smart-glasses app, regardless of whether you use Extentos:

Both platforms

• Meta Wearables Developer Center account (one-time, free)
• Meta App ID and Client Token from the Developer Center
• Paired glasses to test on real hardware (or Mock Device Kit / Extentos simulator instead)

Android

• Min SDK: 31 (the Extentos library floor; com.extentos:glasses requires API 31+ — DAT itself supports lower)
• Maven artifacts under the com.meta.wearable group (singular): com.meta.wearable:mwdat-core, com.meta.wearable:mwdat-camera, com.meta.wearable:mwdat-display, optional com.meta.wearable:mwdat-mockdevice for testing. Pinned to v0.8.0 in current Extentos builds.
• Distributed via Meta's GitHub Packages with token-based access setup
• AndroidManifest permissions: BLUETOOTH_CONNECT, BLUETOOTH_SCAN (the library declares these), plus RECORD_AUDIO, CAMERA (app-declared, depending on capabilities), INTERNET
• Signature registered with the Meta App ID for production

iOS

• Min iOS: 16.0 — the Extentos package floor. (Meta's DAT itself tracks the Meta AI app's OS minimums, which are lower, and supports Xcode 14+; the Extentos package builds with the Swift 6 toolchain.)
• Swift Package Manager dependency on https://github.com/facebook/meta-wearables-dat-ios
• SPM modules: MWDATCore, MWDATCamera. (Meta also ships an optional MWDATMockDevice module for testing; Extentos builds don't consume it.) Pinned to from: "0.8.0" in current Extentos builds.
• Info.plist keys:
  • MWDAT dictionary with MetaAppID, ClientToken, TeamID, AppLinkURLScheme (a custom URL scheme — not a universal link)
  • CFBundleURLTypes matching the AppLinkURLScheme
  • LSApplicationQueriesSchemes includes fb-viewapp (to query the Meta AI app)
  • UISupportedExternalAccessoryProtocols includes com.meta.ar.wearable
  • UIBackgroundModes includes bluetooth-central, bluetooth-peripheral, external-accessory
  • Privacy strings: NSCameraUsageDescription, NSMicrophoneUsageDescription, NSSpeechRecognitionUsageDescription, NSBluetoothAlwaysUsageDescription
• The companion-app registration callback returns to your app via the configured URL scheme — Wearables.shared.handleUrl(_:) must be wired in onOpenURL for the registration flow to complete

Extentos generates the boilerplate for all of this through the MCP server's generateConnectionModule tool — see Quickstart with an AI agent.

Audio architecture (developer-relevant)

This is a recurring source of confusion that's worth pinning down explicitly:

• Microphone capture path: the glasses microphones physically capture audio (beamformed to the wearer's voice). That audio streams to the phone over Bluetooth via the HFP/SCO profile, which negotiates wideband speech (mSBC, 16 kHz mono). Speech recognition runs on the phone, not on the glasses.
• Speaker playback path: TTS audio is synthesized on the phone, then routed to the glasses speakers via Bluetooth A2DP. Synthesis is a phone job; playback is glasses output.
• Continuous listening is supported. Your app can hold the HFP mic open for as long as it's running — this is how always-listening assistants and Extentos's continuous transcription work, and it's what the listening_mode toggle (off / wake_word / on_demand / always_on) governs — see capabilities. The honest trade-offs: HFP and A2DP are mutually exclusive, so playback drops from hi-fi A2DP to voice-band HFP mono while the mic is open; battery drain is real; background capture needs a foreground service on Android and Bluetooth background modes on iOS; and the wearer can always pause or stop the session by folding, removing, or tapping the glasses.
• Coexistence constraint: A2DP (high-quality stereo) and HFP/SCO (low-latency bidirectional) on the same Bluetooth connection compete, and camera streams add pressure. Extentos handles the routing; a blocked combination surfaces as a CoexistenceBlocked error on the affected call.
• Zero Extentos runtime cost. Both platforms handle the hard parts (recognition, synthesis) natively. The Extentos library wires the Bluetooth audio session so the right mic and speaker are in the path. Your shipped app pays nothing to Extentos for voice or audio at runtime.

Roadmap and what to expect

As of 2026-07 — this section is forward-looking. Update after each Meta Connect.

Based on the toolkit's trajectory since its late-2025 developer-preview launch (versions 0.3 through 0.8 in under a year):

• The release cadence is steady. Meta has shipped display rendering, video-stream quality controls, Mock Device Kit upgrades, and session-lifecycle improvements across the 0.x line. Expect capability adds to keep landing between Connects.
• Third-party display rendering already opened — Extentos surfaces it as glasses.display.* in both SDKs, fully sim-testable; on-glasses rendering via DAT 0.8.0 is live on Android, with iOS on-glasses delivery in progress.
• Public publishing is the one to watch. Meta has said broader publishing (beyond select partners) is expected in 2026, and that App Store publishing support is planned. Watch Meta Connect (September).
• Voice invocation may be coming. The Wearables Developer Center already lists a "voice invocation" permission alongside camera and microphone, with no public API documented yet — a hint that launching integrations by voice is on Meta's radar.
• Custom gestures are plausible future-toolkit work — captouch hardware exists and display apps already receive abstracted taps; only a general-purpose API surface is missing.
• "Hey Meta" wake-word-engine access is unlikely to open — the engine is core to Meta AI's product positioning. Plan on phone-side recognition for custom phrases.

Plan for the public DAT preview as it stands. Treat release-channel distribution as the production path until broader publishing opens.

How Extentos relates

Extentos sits on top of Meta DAT and abstracts it:

• RealMetaTransport wraps the real DAT SDK (mwdat-core / MWDATCore + mwdat-camera / MWDATCamera, plus mwdat-display on Android — the iOS package links MWDATCore + MWDATCamera). Your app code talks to glasses.camera.capturePhoto(); Extentos translates to DAT calls.
• LocalSimTransport is Extentos's own in-memory deterministic transport. Same glasses.* API, no real glasses needed, no network, no DAT SDK.
• BrowserSimTransport is Extentos-original — a browser-based simulator that tests the wearing experience (voice triggers, TTS, hardware alerts) at the app layer rather than the Bluetooth layer. See transport vs app simulation for the framing.

When Meta opens new public-toolkit capabilities, Extentos adds them to the SDK surface. Display rendering already landed this way (glasses.display.*); when Meta opens custom gestures or broader publishing, Extentos's capability vocabulary and the simulator extend to cover them. Your handler code doesn't change shape.

When other vendors enter the market, Extentos ships additional transports and the capability primitives stay vendor-agnostic. That is demonstrated rather than promised: the Android XR transport landed in 2026-07 without changing a single app-facing API, so existing Meta handler code already runs under an Android XR device identity in the simulator.

Frequently asked questions

Can I distribute my Meta smart-glasses app to the public today?

Not store-style, yet. During the DAT developer preview, public publishing is limited to select Meta partners; Meta has said broader publishing is expected in 2026. What works today for everyone: distribute your phone app through your normal channels and enroll users as testers in a release channel in the Meta Wearables Developer Center — that enrollment is what lets them register your integration with their glasses. There's no Meta content review involved.

How do users install my Meta smart-glasses app?

Two halves. The phone app installs like any app — sideload, internal track, or Google Play on Android; TestFlight, enterprise, or Ad Hoc on iOS (the iOS App Store isn't supported yet — Meta's SDK currently triggers App Store rejection under Apple's MFi and privacy-manifest rules, and Meta plans to fix this). The glasses link additionally requires the user to be an invited tester in one of your release channels, after which your app pairs with their glasses via the DAT registration flow through the Meta AI app.

Why do Meta's own Display apps look richer than what I can build?

The full-screen experiences on Meta Ray-Ban Display — pedestrian navigation, WhatsApp, live captions — are Meta's first-party system apps (navigation is Meta's own, not a Google Maps integration). Third-party apps get the display-session surface instead: your own UI rendered through glasses.display.* (see the display capability), with wearer input arriving as abstracted tap events. That's a real rendering path — it's just not the system-app tier.

Can my third-party app trigger on "Hey Meta, [my app], do X"?

No. "Hey Meta" is detected by a dedicated always-listening wake-word engine on the glasses, and that engine is system-owned — third parties can't register phrases with it or receive its triggers. Use a custom wake phrase instead: stream the normal glasses microphone over Bluetooth and recognize the phrase on the phone. Extentos's wake_word primitive does this for you.

Can my app listen continuously?

Yes, while it's running. The glasses mic streams over Bluetooth HFP for as long as your app holds the session, which is how always-ready voice assistants work — Extentos exposes this through continuous transcription and the listening_mode toggle (always_on). The trade-offs are battery, playback dropping from hi-fi A2DP to voice-band HFP mono while the mic is open, and platform background-execution rules. What you can't do is listen when your app isn't running — that's the wake-word engine, which is Meta-only.

Does my app work on all Ray-Ban Meta and Oakley Meta variants?

Yes. Extentos runs on every model in market — Ray-Ban Meta Gen 1 and Gen 2 (Wayfarer, Headliner, Skyler, and other frame styles), Ray-Ban Meta Optics, Oakley Meta HSTN, Oakley Meta Vanguard, Meta Glasses (the 2026 Meta-branded line), and Meta Ray-Ban Display. Frame style doesn't affect capabilities. Camera, microphone, and speaker support is identical across every model.

Does Extentos work with Meta Ray-Ban Display?

Yes. Your Extentos-built app runs on a Meta Ray-Ban Display the same way it runs on Gen 1 or Gen 2 — full camera, voice trigger, and audio support. You can also render UI to the heads-up display via glasses.display.* when glasses.display.isAvailable reports the surface is present — guard on availability and fall back to voice on display-less devices. On-glasses rendering via DAT 0.8.0 is live on Android; iOS on-glasses delivery is in progress. The wearer drives your display UI with captouch and the Neural Band; your app receives the interactions as tap events. Raw Neural Band gesture access isn't part of the public toolkit. See the display capability.

What Meta smart-glasses models does Extentos support?

All of them. Compatibility is determined by Meta's Wearables Device Access Toolkit, which is uniform across every Ray-Ban Meta and Oakley Meta variant — see the model table above. Newer Meta-branded models that ship after this writing should work without code changes as long as Meta keeps shipping them behind DAT.

Do I need a paid Meta developer account to ship a Meta smart-glasses app?

No. The Meta Wearables Developer Center account is free. The DAT SDK is free. Mock Device Kit is free. Meta charges nothing for using the public preview toolkit.

What happens to my app when the user folds their glasses?

Closing the hinges drops the Bluetooth link and stops the device session (DAT doesn't expose hinge position directly — the fold shows up as the session ending). Extentos surfaces it through glasses.connection.state as a Disconnected transition (today with cause DeviceDroppedConnection; the dedicated HingesClosed cause is declared but not yet wired) — branch on the disconnect state and decide what to do. Reopening the hinges restores Bluetooth but does not auto-restart the session; Extentos's reconnect flow handles starting a fresh one. Most apps cancel active work (scope.cancel() / task.cancel()) and wait for reconnection.

Is real-hardware testing required to develop a Meta smart-glasses app?

No. Extentos's on-device LocalSimTransport (in-memory local sim) and the Extentos browser simulator (BrowserSimTransport at extentos.com/s) cover the bulk of the dev loop. Real hardware verifies the final-mile fit — fidelity of the camera frames, latency of the voice loop, real-world A2DP/HFP coexistence — but is not required for daily iteration.

What about Apple smart glasses?

Apple has signaled smart-glasses development but has not shipped a third-party SDK as of 2026-07. Extentos plans to add an Apple transport once Apple opens a developer toolkit; your handler code won't need to change.

What about Android XR?

Android XR is in preview: the projected transport is built and proven on Google's emulator, and the simulator carries an Android XR device identity, so you can already check how your app behaves under it. The module is unpublished and no Android XR glasses are buyable, so nothing there is production-supported. See Android XR for the exact status.

Related

• Transport vs app simulation — how Meta DAT's Mock Device Kit and Extentos's browser simulator complement each other
• Capabilities — Extentos's vendor-agnostic capability primitives
• Quickstart with an AI agent — install the MCP server and start building
• iOS quickstart · Android quickstart
• Pricing — Extentos is free; Meta DAT is free; only the glasses cost money

Related