Meta hasn't built an app store for Ray-Ban Display. Two people already did.

Meta's Ray-Ban Display glasses run Web Apps: ordinary HTML, CSS and JavaScript, rendered on the glasses at a fixed 600 by 600 viewport. The runtime is real and it works. What it does not have is anywhere to put anything.

So two people built that part.

What Meta actually shipped

There is no store, and the distribution flow is exactly as manual as that sounds. You host your app over HTTPS. Then, in the Meta AI app, the user goes to App Settings → App Connections → Web Apps → Add a Web App, types a name, pastes your URL, and taps Connect. The app appears at the bottom of the glasses' app grid.

Sharing is a link. Meta's docs describe a Share link button, and note that whoever receives it "can also access your Web App. If they have Developer Mode enabled, they'll be one tap away from adding your Web App. Otherwise, they'll be asked to enable Developer Mode first."

That sentence is the whole shape of the platform right now. Developer Mode is a requirement of the wearer, not of the developer. Meta's FAQ repeats it: a user can add a Web App if they "have toggled the Developer Mode."

And publishing, in the sense every mobile developer means by the word, does not exist. Meta's FAQ is direct about it:

Publishing is currently not available during the Developer Preview phase. We're working toward open publishing and will share updates as the platform matures.

A runtime, then, with no shelf, no review, no payments, and an audience gated behind a developer toggle.

What appeared in the gap

Two unofficial catalogues, both indexing Display Web Apps, both built by individuals rather than companies. Counts below were taken on 26 August 2026 and will have moved by the time you read this.

GlassApps lists 44 apps and games. It describes itself as "a community catalog of apps, games and experiences built for Meta smart glasses with a display," is credited to Timur Abdrakhimov, has an "Add your app" submission route and a Discord.

MetaGlassApps lists 22, describes itself as "a catalog of apps, games and experiences for Meta Ray-Ban Display smart glasses," and is credited in its footer to iSee Labs. It also has a submission route, and one detail worth pausing on: its main call to action is "Install the Store on your Meta Ray-Ban Display." The storefront is itself something you add to the glasses, through the same Add a Web App flow as everything it lists.

Both sort their catalogue into the same eight buckets: game, productivity, utility, social, health, navigation, media, other. Both were built in the window between Meta shipping a runtime and Meta shipping a shelf.

I want to be fair to what these are. Somebody looked at a platform with no front door and built one in a few weeks. That is the correct instinct and it is more than most people do.

They are not app stores, and the difference matters

A store does four jobs: discovery, distribution, trust, and payments.

These catalogues do one of them. They cannot install anything. Installation is the Meta AI app's Add a Web App flow and nothing else can perform it, which is why each GlassApps listing carries an "Add to Meta AI" button that hands off into exactly that flow. The catalogue takes you to the door. Meta owns the door. They cannot review anything into or out of existence, because there is no publishing pipeline to gate. There are no payments. What they have is discovery, and discovery alone.

That is not a criticism of the builders. It is a description of the ceiling Meta's current design puts on anybody who tries. You cannot build the other three jobs on top of a platform that has not exposed them, and you cannot reach past Developer Mode to an audience that has not enabled it.

So the honest description is not "third-party app store." It is a directory, which is the thing that appears whenever a runtime is open and the shelf is not.

The part with no moat

Here is the detail that I think decides how this plays out, and it is sitting in Meta's own documentation rather than in anybody's roadmap.

Meta asks every Web App developer to add this to their <head>:

<meta name="mrbd-web-app-capable" content="yes">

The stated reason, verbatim from the docs, is that it "allows your web app to support upcoming discovery surfaces and enables us to message users when a website isn't compatible with MRBD."

Meta does not say what those surfaces are or when they arrive, and I am not going to pretend otherwise. But it has asked the entire developer base to self-identify in a machine-readable way, for discovery, in advance. That is a request you make when you are building the index.

From there the argument is mine rather than Meta's: an index a platform can assemble from a tag it already asked everyone to add does not lose to an index assembled by hand. GlassApps and MetaGlassApps are collecting submissions one at a time. Whatever Meta ships will start complete, because completeness is the cheap part when developers have been labelling themselves for you.

The list is the part with no moat. It is also, right now, the entire product.

What does not transfer automatically is judgment. Forty-four apps sorted into eight buckets tells you what exists, not which three are worth putting on your face. Every day-one store in history has shipped complete and unopinionated, and the useful curation has arrived later, from people who actually used the things. That is the asset these two are accumulating, whether or not they are thinking about it that way, and it is the only part that survives contact with a first-party surface.

Where this could be wrong: I am assuming Meta's discovery surface arrives open and automatic. If it instead ships curated, or invite-only, or with a review queue that most Web Apps do not clear, then a hand-picked list of the good ones is precisely the right asset to have been building, and the argument above inverts. Meta has not said. Anybody claiming to know which way it goes is guessing, including me.

This has already happened, three times

The reflex is to read this as a Meta story. It is not. The same sequence has run on three other platforms, and on at least one of them it ran first.

Even Realities launched an official plugin SDK on 3 April 2026, with a CLI and a simulator. Its plugins are WebView apps running on the paired phone, with the glasses rendering the layout and relaying microphone and input over BLE. A web runtime on smart glasses, shipped before Meta's.

Snap runs a real store in Lens Explorer, with review in a couple of business days. It also runs WebXR Browser Lenses, which distribute by ordinary web hosting, by URL, with no Lens Explorer submission and no documented review step. The same platform ships both models at once.

Rokid has community stores. RokidBrew and awesome-rokid exist for the same reason GlassApps does, and predate it.

Read together, the pattern is not "Meta forgot the store." It is that a web runtime is dramatically cheaper to ship than a marketplace, so vendors ship the runtime first, every time, and the gap between the two is long enough for somebody outside the company to build a directory in it. We track this across 32 platforms in the ecosystem reference, and the distribution column is the messiest one on the page by a wide margin.

What to do about it today

If you are building a Display Web App, add the meta tag. It costs one line, it is documented, and it is the only stated hook into whatever discovery surface Meta ships.

Almost nobody has. On 26 August 2026 I took every app listed on GlassApps, resolved 35 of them to a live hosted URL, and fetched each one looking for mrbd-web-app-capable in the served HTML. Three had it. Thirty-two did not.

One caveat on that number: I checked the HTML as served, so an app injecting the tag client-side after load would not have counted. Even allowing for a few of those, the tag Meta asked for is close to unused by the apps most likely to want the discovery it points at.

Then submit to both catalogues, because 66 listings between them is where the people who own these glasses are actually looking, and it costs you a form.

And be clear-eyed that neither of those is distribution yet. Until Developer Mode stops being a prerequisite for the wearer, every Display Web App has an audience of developers. If you need to reach people who own the glasses rather than people who develop for them, that path today is the native toolkit route into an app you already ship on iOS or Android, which is a different bet with a different set of costs.

Both bets are live. Only one of them currently has users.