Meta Wearables DAT lets an iOS app talk to AI glasses

An iOS bridge to the glasses, in developer preview

The Meta Wearables Device Access Toolkit enables developers to use Meta's AI glasses to build hands-free wearable experiences into their mobile applications. By integrating the SDK, an app can reliably connect to the glasses and use capabilities such as video and audio streaming and photo capture. That is the entire product surface the README describes, and it is deliberately narrow. The SDK is a Swift package, with the package badge showing version 1.0.1 and an API reference hosted on the Wearables Developer Center. The state of the project is the thing to weigh first, because the README says plainly that the Wearables Device Access Toolkit is in developer preview. What developers can do at this stage is access the SDK and documentation, test on supported AI glasses, and create organizations and release channels to share with test users. That last point is the practical shape of a preview: you build a channel, you distribute to testers, you are not shipping to the App Store with a settled API.

Adding the package through Xcode

The SDK is distributed as a Swift Package, which is the standard way an iOS dependency ships, and adding it is a sequence of clicks in Xcode. You select File and then Add Package Dependencies, search for the repository URL in the top right corner, select `meta-wearables-dat-ios`, set the version to one of the available versions, click Add Package, then select the target you want the packages added to and click Add Package again. Two steps in that list are worth pausing on. The version is not a floating branch, you pick one of the tagged versions, which is the behaviour you want for a preview SDK where the API can move. And the target selection is separate from the package addition, so a project with several targets needs this done once per target. The repository also carries a `CHANGELOG.md`, and the README points at it for the latest updates, which is the file to watch when the API changes under you.

Analytics are on by default, and the opt-out is a plist key

The data collection story is the part to read before you ship, and the README is unusually explicit about it. By enabling Meta integrations, including through this SDK, Meta may collect information about how users' Meta devices communicate with your app, and that information is used under Meta's privacy policy. The way to limit it is an opt-out, and it is configured in your app's `Info.plist` under the `MWDAT` key. There are two ways to do it. The recommended one is through Xcode, where you select the app target in the Project navigator, go to the Info tab, navigate to Custom iOS Target Properties, find the `MWDAT` key, add a new `Analytics` key of type Dictionary, then add an `OptOut` key of type Boolean inside it and set it to `YES`. The alternative is editing the XML directly.

<key>MWDAT</key>
<dict>
    <key>Analytics</key>
    <dict>
        <key>OptOut</key>
        <true/>
    </dict>
</dict>

The default behaviour is worth being precise about, because the polarity is easy to misread. If the `OptOut` key is missing or set to `NO` or `<false/>`, analytics are enabled, in other words you are not opting out. Setting it to `YES` or `<true/>` disables data collection.

Crash reporting is enabled unless you opt out too

The same pattern applies to crash reporting, and it follows the SDK code's own crashes rather than your app's. The toolkit can capture crashes originating from SDK code, store them locally, and chain with any existing crash handler your app installs, so you do not have to choose between your own reporting and the SDK's. Crash reporting is enabled by default. To opt out, add a `CrashReporting` dictionary with an `OptOut` boolean set to `true` under the `MWDAT` key in your app's `Info.plist`.

<key>MWDAT</key>
<dict>
    <key>CrashReporting</key>
    <dict>
        <key>OptOut</key>
        <true/>
    </dict>
</dict>

Again the default is opt-in, meaning if the `OptOut` key is missing or set to `NO` or `<false/>`, crash reporting is enabled, and `YES` or `<true/>` disables SDK crash capture. Both settings sit under the same top-level `MWDAT` key, so they are configured in one place in the plist, and the Xcode route treats them the same way. One detail is easy to get wrong: the local storage of crashes is part of the design, so a device that has captured SDK crashes holds them until they are reported or discarded, which is worth knowing if your app's privacy policy makes local crash storage a point of review.

The terms you accept by using the SDK

Using the Wearables Device Access Toolkit is agreement to Meta's Meta Wearables Developer Terms, including the Acceptable Use Policy, and the README says so in the Developer Terms section rather than burying it. Two other things are stated in the same place. Meta may collect information about how users' Meta devices communicate with your app, and you may limit that access through the opt-out described above. For a team shipping an iOS app to real users, that combination is the core of the decision. The developer terms are a separate document from the code licence, and the repository's own licence field is recorded as a custom licence that GitHub cannot classify, with the terms in the LICENSE file. The repository also carries a `NOTICE` file and a `CODE_OF_CONDUCT.md`, and the README asks users to create an account on the Wearables Developer Center, set up a project and a release channel, and report bugs through their Developer Center account.

The repository doubles as an agent knowledge base

One thing makes this repository different from a typical SDK drop, and it is worth knowing if you write tooling against it. The repository ships a public DAT knowledge base as a single plugin, plus file-based artifacts for the tools that do not use plugins. The table maps each tool to its artifact and the recommended setup. Muse Code, Claude Code and Codex install from the plugin payload under `plugins/`, with the repository added as a marketplace and then `mwdat-ios` installed. GitHub Copilot reads `.github/copilot-instructions.md` automatically in VS Code, Cursor reads `.cursor/rules/*.mdc` with glob-based triggers, and agents that read `AGENTS.md` get a portable fallback. MCP-compatible editors can connect to a remote HTTP MCP server at the developer endpoint with no authentication required. In other words, an assistant can read the same knowledge base the SDK ships with, which is a reasonable thing to want for a preview SDK whose API surface is still moving.

Installing the knowledge base for each agent

The plugin installs are three commands per tool, and a helper script does the same thing. For Muse Code the marketplace is added, the plugin installed and then approved.

muse plugins marketplace add mwdat-ios-marketplace https://github.com/facebook/meta-wearables-dat-ios
muse plugins install mwdat-ios@mwdat-ios-marketplace
muse plugins approve mwdat-ios

Claude Code and Codex use the same shape with their own command names.

claude plugin marketplace add facebook/meta-wearables-dat-ios
claude plugin install mwdat-ios@mwdat-ios-marketplace

codex plugin marketplace add facebook/meta-wearables-dat-ios
codex plugin add mwdat-ios@mwdat-ios-marketplace

For the tools that rely on the file surfaces instead, the helper script has a target per tool, and an `all` target that installs the plugin form for Muse, Claude and Codex where available plus the Copilot, Cursor and AGENTS.md files.

./install-skills.sh copilot   # .github/copilot-instructions.md
./install-skills.sh cursor    # .cursor/rules/*.mdc
./install-skills.sh agents    # AGENTS.md
./install-skills.sh all       # Muse/Claude/Codex when available, plus Copilot/Cursor/AGENTS.md

The repository also carries a `samples/` directory with three example apps, `BirdSpotter`, `CameraAccess` and `DisplayAccess`, which are the fastest way to see what the glasses can actually do before you design around them.

Editorial conclusion

Adopt the Meta Wearables DAT if you are building an iOS app that has to talk to Meta's AI glasses and you can work inside a developer preview SDK with Meta's terms. Skip it if you need a stable, general availability SDK, since the project states the toolkit is in developer preview. Before you ship, set the analytics and crash reporting opt-out keys in Info.plist if your privacy policy requires it, and read the Meta Wearables Developer Terms and Acceptable Use Policy, because using the SDK is agreement to them.

Frequently asked questions

Official sources

1. facebook/meta-wearables-dat-ios on GitHub
2. Issues
3. README