Meta Wearables Device Access Toolkit: Quickstart Guide for Event-Driven Mobile Workflows (2026)

Want to extend your mobile app into a glasses form factor—without guessing the connection, permissions, and event lifecycle? This guide gives you the fastest path to a working demo with Meta’s new Wearables Device Access Toolkit, then a production-ready checklist for taking your AI glasses integration to real users.

Watch the Quickstart VSL

The video above walks through installing the toolkit and running a sample app. By the end of this guide, you’ll have a working demo app that connects to Meta’s AI glasses, streams camera input, and responds to a basic event – all using the Device Access Toolkit (developer preview).

What This Guide Covers

• How to get access to the toolkit (Preview program)
• How to install the SDK and run the sample apps (iOS + Android)
• The core building blocks of glasses integration (connect, permissions, events, actions)
• A reusable “first feature” pattern you can adapt to any use case
• Testing, privacy, and rollout basics

Note: The current preview SDK focuses on camera, microphone and audio capabilities. It does not yet support custom HUD displays or neural-band gestures on the glasses – those features are expected in future updates. All examples below leverage what’s available today (mostly camera and voice interactions).

Meta's AI glasses (like the Ray-Ban Meta models) are a key part of the Wearables Device Access Toolkit preview. The SDK lets iOS and Android apps access a glasses’ camera, microphones, and speakers.

To build with the Device Access Toolkit, you’ll need the right accounts, hardware, and dev environment configured. The toolkit is in developer preview, meaning you must sign up and be approved before your app can interface with real glasses. Let’s make sure you have everything ready.

Access & Accounts

• Meta developer account: You’ll need a Meta developer/Meta account (Managed Account) to use the Wearables toolkit (sign up via the Meta Developers site).
• Wearables Toolkit preview access: Ensure you have preview program access to the Meta Wearables Device Access Toolkit. (Request access through the official Meta form and wait for approval).
• Documentation hub: Once in, access the Wearables Developer Centre for SDK documentation (login required). This hub contains API references, guides, and testing tools.
• Support / forums: Join the developer community for Q&A and support. Meta provides discussion forums (e.g. GitHub Discussions for the iOS/Android SDKs) to share feedback and get help.

Devices & Environment

(Supported glasses models include Ray-Ban Meta (gen 1 and gen 2), Oakley Meta, and Meta Ray-Ban Display.)

If you’re using React Native or Flutter, plan to write a thin native wrapper module around the Wearables SDK on each platform. You can keep your business logic cross-platform, but you’ll need Objective-C/Swift and Java/Kotlin code to handle the glasses connection and events.

Quickstart: Install + Run the Samples

Meta provides sample apps to jump-start development. We’ll grab the SDK and sample code, get it running on iOS and Android, and verify we can connect to the glasses.

Step 1) Download SDK + Samples

• Developer Centre: Visit the Meta Wearables Developer Centre to get the SDK (you should have access if approved). Download links for the iOS and Android SDKs are available on the Meta Wearables Notify page.
• Docs: Review the official documentation (API reference and setup guides) on the Wearables Developer Centre for any platform-specific notes.
• Sample apps: Clone or download the sample app repositories from GitHub: Meta Wearables DAT iOS and Meta Wearables DAT Android. Each contains a CameraAccess sample to test camera streaming.

Step 2) iOS: Build & Run

# Add the SDK via Swift Package Manager (SPM):
# In Xcode, go to File > Add Packages...
# Enter the GitHub repo URL (facebook/meta-wearables-dat-ios) and add the package.
# Open the workspace/project, select your development team for signing.
# Connect a physical iPhone via USB (Bluetooth requires a real device, not Simulator).
# Build and run the CameraAccess sample app on the iPhone.

Checklist (iOS)

• Project builds locally (SPM packages resolved)
• App launches on the iPhone
• Required usage descriptions are in the Info.plist (for camera, mic, Bluetooth).
• You can reach the sample’s “Connect to Glasses” screen in the app

Step 3) Android: Build & Run

# Open the Android sample in Android Studio:
# - Ensure GitHub Maven and SDK dependencies are added (see README or docs).
# - Add a GitHub PAT token for maven.pkg.github.com (to fetch the SDK packages).
# Sync the Gradle project to download the SDK.
# Connect an Android phone (enable USB debugging).
# Build and run the CameraAccess sample app on the device.

Checklist (Android)

• Project builds locally (Gradle sync succeeds).
• App launches on the phone (with no runtime errors)
• Required permissions are declared in AndroidManifest (Bluetooth, Camera/Mic, Internet) as detailed in our Flutter integration guide
• You can reach the “Connect” screen in the app’s UI

Step 4) Connectivity Smoke Test

Goal: Verify you can connect to the glasses and receive at least one event from them.

1. Pairing: Make sure your glasses are paired to the phone via the Meta AI companion app beforehand. The Meta AI app must be running (even in background) since it brokers the connection between your app and the glasses.
2. Connect: In the sample app, tap the Connect button. You should see a handoff to the Meta AI app for authorisation, then a status change to “Connected” in your app.
3. First event: Once connected, the SDK should start streaming an event (e.g. a camera frame or device state update). For example, the sample might automatically start a camera preview. The LED on the glasses will turn on when the camera is active as a privacy indicator. You should see at least some data or log from the glasses come through.

Expected result: The app indicates a Connected state (e.g. “Device connected”) and you receive live data (for instance, a preview image from the glasses camera). Note: Video streaming may be limited to around 720p resolution over Bluetooth LE – so expect a modest-quality preview.

If it fails: double-check the following:

• Pairing status: Is the companion Meta AI app open and are the glasses paired/ON? Re-pair if necessary via the Meta app.
• Permissions: Did you grant Bluetooth (and Nearby Devices on Android), Camera/Microphone, etc., when prompted? A missed permission can block the connection.
• OS settings: On iOS, ensure the app has Bluetooth permission in Settings (if you accidentally denied it, you’ll need to enable it manually). On Android, confirm that location/Bluetooth is enabled and the Meta app is installed.
• SDK version: Are you using the latest SDK version that matches the glasses firmware? (For example, if the glasses updated, make sure you have the newest preview SDK). Also ensure your GitHub Maven token (Android) is valid so you got the latest libraries, and that the sample app’s dependencies weren’t changed.

Core Concepts You’ll Use in Every Feature

Now that you have a basic app running, let’s break down the key concepts of building features with the glasses. Every workflow you create will use these building blocks:

1) Connection Lifecycle

Handling the connect→use→disconnect flow is crucial. Your app needs to manage the Bluetooth connection to glasses reliably:

• Initial Connect: Use the SDK’s connect method, which will invoke the Meta AI companion app to get user approval for your app to access the glasses. After approval, maintain the connection.
• Background/Foreground: Decide how your app behaves if the user leaves the app. By default, the connection may drop when your app is backgrounded (especially on iOS, unless you enable background Bluetooth modes). Consider enabling background execution if continuous use is needed, but be mindful of battery impact.
• Disconnects & Reconnects: Handle unexpected disconnects (e.g. glasses powered off or out of range). Implement a reconnect strategy with retries and timeouts. The SDK likely provides callbacks for connection loss – use them to update UI status and attempt reconnection (or prompt the user).

2) Permissions & Capabilities

Using AR glasses means dealing with multiple permission layers:

• OS Permissions: Your mobile app must request Bluetooth (for device connection), Camera (even if using the glasses camera, iOS may require this), Microphone (for any audio streaming), etc. Make sure you declare these in your app config and prompt the user at runtime in a clear way (“This app needs Bluetooth to connect to your glasses”).
• Device Permissions: The first time your app tries to use certain glasses features, the glasses/Meta AI app will ask the user for consent (for example, allowing your app to access the glasses camera stream). The user might have to confirm on the glasses or in the Meta app. Your workflow should handle the case where permission is denied (e.g. show an error like “Glasses access not granted” and offer a retry).
• Graceful Fallbacks: If a permission is denied (or glasses are not available), your app should still function. For instance, if glasses camera access is refused, you might let the user fall back to the phone camera, or simply notify them that the feature requires glasses permission to work.

3) Events → Actions Pattern

The toolkit is event-driven. It emits events from the glasses, and your app should respond with actions. This pattern decouples the hardware input from your app logic:

• Events: These are notifications that “something happened” on the glasses. Examples: a button was pressed on the frame, a certain gesture was detected, a new camera frame is available, or a voice command was registered. In code, these might come as delegate callbacks, listeners, or observables from the SDK (depending on platform).
• Actions: Your app’s reactions to those events. This could mean starting a workflow, updating the UI, sending data to a server, or invoking some phone functionality. For instance, on a “capture” event (user pressed the capture button on glasses), your app could save the photo and then navigate to a preview screen in the phone app.

By structuring features as event→action pairs, you keep the glasses integration modular. You subscribe to the events you care about, and in the handler, you call into your app’s existing functions or trigger UI updates. This will be the foundation for any glasses-enabled feature you build.

Build Your First Glasses-Enabled Workflow

Now it’s time to actually create a feature. This section is intentionally generic so you can swap in any capability, but we’ll outline a pattern that works for most cases.

Pick a “First Feature” That’s Easy to Validate

Good first features are:

• Observable: You can tell immediately that it works (no complex background processing). E.g. something visibly changes in the app or on the glasses.
• Low-risk: Avoid anything that could crash or corrupt user data while you’re experimenting. Stick to simple interactions.
• Useful: Aim for a feature that has a real user benefit, even if small – this will help you iterate and get feedback.

Examples:

• “Tap on glasses → open a specific screen in the phone app.” (Uses a hardware event from glasses to trigger mobile navigation – easy to see when it works.)
• “Voice intent → start a predefined workflow.” (User says a phrase, captured via glasses mic, your app then performs a fixed action like logging a note or querying something.)
• “Capture button → send a placeholder payload to the phone app.” (Pressing the glasses’ capture takes a photo or records a short clip, and your app simply receives it and perhaps displays a notification or thumbnail.)

The current preview SDK doesn’t allow third-party apps to put content on the glasses display or read neural band gestures yet, so design your feature around inputs like button presses, voice capture, or camera streaming (which are supported).

Implementation Template (Pseudo-Code)

Here’s a pseudo-code outline that you can adapt for your feature:

// 1) Initialize the Wearables SDK in your app (e.g. configure with your App ID)
sdk = MetaWearablesSDK.initialize(appId: "YOUR_APP_ID")

// 2) On app launch, request or verify required permissions:
// Bluetooth, Camera, Microphone, etc., as needed.
sdk.requestPermissions()

// 3) Connect to the glasses:
// Call SDK.connect(), which handles pairing via Meta AI app.
sdk.connect()

// 4) Subscribe to glasses events you need:
sdk.on('event', (data) => {
    handleGlassesEvent(data)
})

// 5) In the event handler: perform an app action:
function handleGlassesEvent(event) {
    if (event.type === 'photoTaken') {
        displayPhoto(event.photo)
    }
}

// 6) Provide user feedback:
updateStatusUI("Glasses Connected")

// 7) Log key lifecycle events for debugging/support:
log("Event received: " + event.type)

This template keeps your integration straightforward. Essentially: init SDK → connect → subscribe → act on events. Once this loop is working for one feature, you can replicate it for others.

Minimal UX Requirements (Don’t Skip These)

Even a simple glasses integration should have some basic UX elements to make it user-friendly:

• Clear status indicators: Show whether the glasses are Connected or Disconnected (and maybe Reconnecting if you implement that). A small coloured dot, an icon, or text status in your app can prevent a lot of confusion.
• Obvious error messages: If something is wrong (glasses battery low, Bluetooth off, permission denied, etc.), display a user-friendly message. For example: “Glasses not found – turn on your glasses and ensure Bluetooth is enabled.” Or “Action requires Bluetooth permission – please enable it to continue.” Guide the user on how to fix it (e.g. a button to open Settings if needed).
• Fallback path: Always allow the user to complete the task without the glasses if possible. If your feature is “take photo with glasses”, also let them take a photo with the phone camera as a fallback. If it’s “voice command via glasses”, allow a manual button tap to do the same action. This way, if the wearable is disconnected or the user hasn’t bought one, your app still works (and you’re not locking out potential users).

Implementing these small UX details will make your first feature feel much more polished and reliable, even while the glasses integration is in preview.

Testing & Troubleshooting

With your first feature implemented, thorough testing is vital – wearables introduce more variables (battery, BLE connection quality, user movement, etc.). Use the following test matrix and watch out for common issues:

Test Matrix

Create a table of scenarios to test, like below:

Run through these scenarios on both iOS and Android. It’s best to test with different devices if possible (various phone models, OS versions) to catch device-specific quirks.

Common Gotchas

Be aware of these common pitfalls (many devs hit these on the first try):

• Forgetting runtime permission prompts: You declared permissions in the manifest/Info.plist but didn’t actually request them in-app. Result: features silently fail. Always use requestPermissions() at appropriate times (and handle the user’s response).
• Build and signing issues (iOS): If Xcode complains about code signing or bundle ID, make sure you used a unique bundle ID and selected your Apple development team. For example, the sample’s default ID might need to be changed to your own prefix to run on a device.
• Gradle/Maven auth issues (Android): A common headache – you see 401 Unauthorized when Gradle tries to fetch mwdat-core. This means your GitHub Packages token wasn’t configured properly. Double-check the maven { url ... credentials } setup and ensure your PAT has the right scopes.
• OS killing background processes: Some Android phones aggressively kill background apps to save battery. If your integration needs to run in background (say to keep a connection for real-time updates), you might need to instruct users to disable battery optimisation for your app. This varies by manufacturer – keep it in mind during testing if you see disconnects when the app is backgrounded.
• “Works once” syndrome: Perhaps you got everything working for a single session, but after disconnecting and reconnecting, something fails (like events not re-registering). This often means you didn’t fully reset state on disconnect. Make sure to re-subscribe to events on each new connection and handle any needed cleanup on disconnect. A robust reconnection logic will make your feature reliable beyond the demo.

By anticipating these issues, you can fix them proactively (or at least recognize them quickly when they arise).

Privacy, Security, and AU Notes

Building on cutting-edge wearables is exciting, but it also raises privacy and security considerations – especially if you’re in a jurisdiction like Australia with strict privacy laws. Here are some practical defaults and tips:

Practical Defaults

AU context: In Australia, if your app or service will handle personal information from the glasses (photos, audio of people, etc.), you must align with the Privacy Act 1988 (Cth) and the Australian Privacy Principles. This means being transparent about data collection and usage in your privacy policy, and securing that data appropriately. Also be mindful of any surveillance/device laws if your use case involves recording in sensitive environments, so be sure to review our wearable camera privacy checklist.

For more regulated environments (enterprise, government, healthcare), consider mapping your controls to frameworks like the Australian Cyber Security Centre’s Essential Eight strategies. For example, one strategy is controlling application allow-listing – ensure your glasses integration doesn’t allow unauthorised apps to connect. While the Essential Eight is broad, using it as a checklist (patching, admin privilege management, etc.) can help harden your solution from day one.

Lastly, design with privacy-by-design in mind. Meta’s glasses have built-in indicators (like the recording LED) – don’t try to bypass or disable these. (Refer to the privacy checklist for more on indicator standards.) Embrace them as features: they build trust with users and bystanders. Clearly inform users when the glasses are capturing information and provide easy ways to opt out or disable the integration if desired.

Production Readiness Checklist

Got a cool prototype running? Great – but before shipping a production feature, make sure you’ve checked off the following:

• Robust connect/reconnect handling: The app cleanly handles glasses being turned off/on, losing connection, or user stepping out of range, without crashes or stuck states.
• Permission recovery paths: Every permission denial triggers a user-friendly response (and the app can recover if the user later grants permission via Settings).
• Feature flags or kill-switch: If using any preview or experimental glasses features, guard them behind a feature flag or remote kill-switch. This allows you to disable the glasses integration if something goes wrong in production.
• Logging & crash reporting: Integrate analytics or logging to record glasses-specific events (connection success, failures, usage frequency) – but make it exportable or observable for support. If a user reports “glasses won’t connect,” your logs should help pinpoint why.
• Device and version compatibility notes: Document which glasses models and firmware versions you tested against, and any known issues (e.g. “currently not working on Oakley Meta beta firmware v0.x”). This helps QA and support teams.
• Onboarding UX: Ensure a first-time user (think: a non-developer) can get set up with minimal help. This means your app’s onboarding covers installing the Meta AI app, pairing the glasses, granting permissions, etc., in a clear sequence. If possible, have a colleague or friend run through it fresh and observe where they get stuck.

When all the above is in good shape, you’re much closer to a reliable, user-ready feature rather than just a hacky demo.

Next Steps

• Pick your next glasses-powered feature and repeat the “Events → Actions” implementation pattern. Maybe you started with a photo capture; next could be a voice command or a glasses gesture (when available).
• Gradually replace any placeholder or “demo” actions with real production logic – e.g. if your first feature just showed a local notification on event, maybe now it navigates to a live camera view or sends data to your backend.
• Test with real users (or at least internal beta testers). Glasses are a new paradigm – user feedback will teach you a lot about what works and what’s clunky. Use TestFlight, internal app sharing, or APKs to get the app in the hands of a few trusted users along with the glasses.

Need help hardening the integration or brainstorming use cases? Cybergarden can help you go from prototype → production. We’ve worked on native wrappers, event-driven architectures, testing setups, and privacy-by-design approaches for emerging tech. Feel free to reach out for a consultation and accelerate your glasses project! 🚀

FAQs

Q1: Do I need preview access to use the toolkit?

Yes. As of now (early 2026), the Meta Wearables Device Access Toolkit is in developer preview – you must sign up and be approved to download the SDK and use it with real devices. Follow the official sign-up process on Meta’s developer site (fill out the interest form and agree to the terms). Once you have access, you can download the SDK packages and run the sample apps. Without preview access, your app won’t be authorised to connect to the glasses yet.

Q2: Can I build with React Native or Flutter instead of native iOS/Android?

Yes, with a caveat. You can absolutely use React Native, Flutter, or other cross-platform frameworks, but the Wearables SDK itself is native (provided for iOS and Android). This means you’ll need to create a bridge to the native code:

• For React Native: write a Native Module (Objective-C/Swift for iOS, Java/Kotlin for Android) that wraps the SDK’s functions (connect, subscribe to events, etc.) and exposes them to JavaScript. Your UI can remain in React Native.
• For Flutter: use Method Channels to communicate between Dart and native. Implement the Wearables integration on iOS and Android natively, then call into it from Dart. You might also consider writing a Flutter Plugin package for the glasses SDK to reuse in other projects.

The key is to keep as much logic as possible in your cross-platform layer, but delegate the device-specific handling to native code. This way, you benefit from RN/Flutter for UI and core logic, while still leveraging Meta’s native SDK for the heavy lifting. Many developers have done this for other device SDKs – it’s a proven approach.

Q3: What’s the fastest path to a working demo?

The quickest way is to start with the provided sample app and make a minimal change to it:

1. Run the sample app as-is to ensure you can connect and get a basic event (e.g. camera preview or a photo capture) – you’ve likely done this in the Quickstart above.
2. Implement one simple action in response to that event – something visual. For instance, if it’s a button press event, make it toggle a piece of text on screen or send a local notification saying “Button pressed on glasses!”. If it’s a photo capture, maybe just count the captures or display the image in an image view.
3. Verify it on the device with the glasses. When you press the actual button on the glasses, does your new action happen? Seeing this end-to-end loop working is the “hello world” of glasses integration.
4. Add some basic UI feedback (as discussed, a status indicator or toast) so you know what’s happening without reading logs.

By using the sample as a starting point, you avoid a lot of setup and can focus on the event→action wiring. Once you have that working, you can incrementally build it into a feature. This beats trying to code everything from scratch on day one. Remember, the goal is to quickly prove that your app can communicate with the glasses – after that, you’ll have a blueprint to build something truly awesome.