GlassKit Docs — How to build a Meta Ray-Ban Display app

The complete guide to building, previewing, and shipping an app for Meta Ray-Ban Display glasses: the two SDK paths, the Web Apps constraints, and the deploy-to-glasses flow.

This is the practical, end-to-end guide to building an app for the Meta Ray-Ban Display, Meta's first AR glasses with an in-lens display. It covers what the platform actually is, the two ways to build for it, the real constraints of the Web Apps path, and how to get your app running on a pair of glasses.

It's written to be useful whether or not you ever use GlassKit. If you just want the fastest production path, jump to Where GlassKit fits.

What the Meta Ray-Ban Display is

The Meta Ray-Ban Display is a pair of smart glasses with a small, monocular, full-color display built into the right lens, paired with the Meta Neural Band, an EMG wristband that reads finger gestures from the muscle signals at your wrist. It is the first mainstream consumer device that puts a genuine heads-up display in an everyday form factor.

For developers, the important part is this: since the developer preview opened on May 14, 2026, Meta lets third parties build for the display. The hardware is $799 including the Neural Band and, as of mid-2026, sold in the US only (per meta.com). There are two distinct paths.

The two build paths

Meta ships two separate developer paths, documented at wearables.developer.meta.com, and they are not interchangeable.

1 · Meta Wearables Device Access Toolkit

Native mobile SDK: Swift (iOS) / Kotlin (Android). Extends an existing mobile app onto the glasses. The only path with camera + audio capture. Deepest hardware integration.

2 · Web Apps

Standalone path: HTML / CSS / JS hosted at a public HTTPS URL. No native code, no app store. The path most indie developers will take, and what the rest of this guide covers.

Which should you pick?

If you need the camera, you need the native Meta Wearables Device Access Toolkit. For everything else (utilities, navigation, fitness, reference, AI experiences), Web Apps are faster to build, deploy via URL, and work with the stack you already know.

What a Web App can and can't do

The Web Apps path has a specific, well-defined surface. Design for it from the start.

The display

600 × 600 pixels. Your entire app is a single 600×600 square.
Additive display. The display is additive: black renders as transparent. You design on a dark base with bright, high-contrast elements that "float" in the wearer's view.
Single screen. There's no scrolling browser chrome. Think one focused view, not a multi-page website.

Input

D-pad navigation only. The Neural Band and the temple touch surface reach your app as standard Arrow keys + Enter (the pinch is the select gesture behind Enter). There is no raw gesture API for Web Apps.
There are no custom gestures, no cursor, and no text input. You get directional focus movement and select. Mark interactive elements as focusable and manage focus accordingly.

Sensors and data a Web App can access

Motion and orientation: accelerometer / gyroscope data via DeviceMotion / DeviceOrientation
GPS: navigator.geolocation, resolved via the paired phone
Neural Band input: the discrete Arrow-key + Enter events above
Local storage: localStorage / sessionStorage (5 MB)

What a Web App cannot do

No camera, no audio capture

Camera and microphone access is exclusive to the native Meta Wearables Device Access Toolkit. No web app on the platform can see through the glasses or capture audio. Web Apps also have no text input, no back navigation, no cursor, and no offline mode.

Building your first Web App

Because a Web App is just HTML, CSS, and JavaScript served over HTTPS, you can build it however you like: vanilla files, or a framework like Vite + React if you want a component model and TypeScript.

A minimal app is three files: index.html, styles.css, app.js. Meta's own AI toolkit (a plugin for Claude Code, Cursor, Codex, and Copilot) will scaffold exactly that. Whatever you use, respect the constraints:

A 600×600 viewport as your root container
A dark / transparent base with bright foreground elements
A .focusable convention so D-pad input has something to move between
High-contrast type. The display is small and see-through

Previewing your app

You do not need the glasses to start. A Web App runs in a normal desktop browser.

Open your app in the browser and size the viewport to 600×600.

Use the arrow keys to simulate D-pad navigation.

Use Chrome DevTools → More tools → Sensors to override location and orientation, so you can test GPS- and motion-driven features without moving.

This means the entire build-and-iterate loop happens on your laptop. The glasses are only needed for final on-device polish.

Deploying to the glasses

A Web App goes onto the glasses by URL.

Host it at a publicly accessible HTTPS URL. Vercel, Netlify, Cloudflare Pages, GitHub Pages: any static-capable HTTPS host works.

Enable Developer Mode in the Meta AI app (tap the app version a few times in Settings).

Add the app: in the Meta AI app, go to your Display Glasses settings → App connections → Web apps → Add a web app, and enter the URL. (Tools like GlassKit generate a QR code that encodes this URL as a convenience; the official Meta flow is the HTTPS URL itself.)

Your app now runs on the glasses. Minimum versions: glasses software v125+ and Meta AI app v272+.

Today's publishing limits

Developer preview limits as of mid-2026

No public app store yet. You can't list an app for the general public; Meta says broad publishing is planned for 2026, with select partners distributing during the preview.
Distribution is by URL. Anyone with the HTTPS URL and developer mode enabled can add your Web App to their glasses today.

Practical takeaway: build and test now, ship the day publishing opens. Teams that are fully built when the gate lifts win the early catalog.

How to build a Meta Ray-Ban Display app