Meta Wearables Device Access Toolkit: Quickstart Guide for Testing Meta Glasses Apps: Automated QA Strategy Without Physical Hardware (2026)

Want to extend your mobile app to Meta’s AI glasses but don’t have a physical device to test on? Building hands-free features without real hardware can feel like guesswork. This guide shows you how to use the new Meta Wearables Device Access Toolkit to build and automate-test your glasses-enabled app – all without owning a pair of Meta glasses.

This quickstart will give you the fastest path from signing up for Meta’s toolkit preview to running the sample app and implementing a simple glasses-connected feature. By the end, you’ll have a working demo on iOS/Android and a strategy for QA testing it thoroughly even if you don’t have the actual glasses in hand.

Watch the Quickstart VSL

This short video walks through installing the Meta Wearables Toolkit and running a sample app on your phone. By the end of the video, you’ll see how to connect to a simulated glasses device and capture a test photo—no real glasses required.

What This Guide Covers

• How to get access to the toolkit (developer preview) and set up your accounts
• How to install the SDK and run the sample apps on iOS and Android
• The core building blocks of glasses integration (connect flow, permissions, events, actions)
• A reusable “first feature” pattern you can adapt to your app
• Testing your integration with and without hardware (using Meta’s Mock Device Kit)
• Basics of privacy, security, and rollout for an Australian context (Privacy Act compliance, etc.)

Before You Start

Access & Accounts

• Meta Developer account: Create or log in to the Meta for Developers portal (a standard Meta/Facebook developer account). Ensure you have access to the Wearables Device Access Toolkit preview programme (you may need to apply for the preview, which is currently gated).
• Wearables Device Access Toolkit preview: Sign up or request access via the Meta Wearables Developer Centre (the toolkit is available in developer preview). Once approved, you’ll get access to SDK downloads and documentation.
• Documentation hub: Access the official docs at the Meta Wearables Developer Centre (which includes API reference, guides, and sample code).
• Support / forums: Join the Wearables developer community for support. Meta provides GitHub discussion forums (for iOS and Android SDKs) where you can ask questions, report issues, and share feedback with other developers.

Devices & Environment

If you’re using React Native / Flutter, plan for a thin native wrapper module around the SDK to interface with your JavaScript/Dart code.

If you don’t have a physical glasses device handy, use the Mock Device Kit in the SDK to simulate one to start developing. (The toolkit lets you pair a virtual glasses device and even simulate camera input, so you can start building without actual hardware.)

Quickstart: Install + Run the Samples

Step 1) Download SDK + Samples

• Wearables Developer Centre: Log in to the Meta Wearables Developer Centre (preview portal) to download the SDK. You’ll find both iOS (Swift) and Android (Kotlin) packages, along with documentation.
• Sample apps: Grab the official sample applications for iOS and Android (e.g. a “Camera Access” sample). These provide a working demo of connecting to glasses and streaming video. The sample apps are available via the official blog introduction and GitHub (Facebook’s meta-wearables-dat-ios and meta-wearables-dat-android repos).
• Include Mock Device support: The SDK is modular – make sure to include the Mock Device Kit component if you plan to test without hardware. For example, on Android you would add the mwdat-mockdevice library to your Gradle dependencies from the official README (and on iOS the Swift Package includes a similar mock device module). This gives your app the ability to simulate a glasses connection in code.

Step 2) iOS: Build & Run

# Install Swift Package dependencies via Xcode
# (The SDK is distributed as a Swift Package, not CocoaPods.)
open MetaWearablesToolkit.xcodeproj  # open the sample Xcode project
# In Xcode, select your development team for signing (if running on device)
# Ensure a physical iPhone is connected (required for Bluetooth connectivity)
# Build and run the sample app on your iPhone

Checklist (iOS)

• Project builds successfully in Xcode (after adding the toolkit Swift Package)
• App launches on your iPhone (ensure the phone is connected via cable or Wi-Fi)
• Required usage descriptions are in the Info.plist (camera, microphone, Bluetooth, etc.)
• You can reach the toolkit’s Connect screen in the app (the sample’s UI should show a “Connect to Glasses” button)

Step 3) Android: Build & Run

# Add Maven repo and dependency in Gradle (see Step 1 notes)
./gradlew assembleDebug  # build the sample app
# Connect your Android device via USB (or use ADB over network)
./gradlew installDebug   # install the app on the device
# Launch the app on your Android phone

Checklist (Android)

• Project builds successfully in Android Studio/Gradle (after adding the Maven package and mock device dependency)
• App launches on your Android phone (ensure “Install from Unknown Sources” is allowed if installing outside Play Store)
• Permissions are declared in AndroidManifest.xml (camera, mic, bluetooth) and requested at runtime on first launch
• You can reach the Connect screen in the app (the sample should prompt for or show a connect button for glasses)

Step 4) Connectivity Smoke Test

Goal: Verify you can connect to the glasses (real or simulated) and receive at least one event from the device. In the sample app, this means successfully pairing and seeing a camera feed or status update from the glasses.

• If you have physical glasses: Put your Ray-Ban/Oakley Meta glasses in developer mode (if required) and attempt to connect via the sample app’s interface. You should see a “Connected” status and be able to start a video stream or take a photo.
• If you’re using the Mock Device Kit: Launch the mock/simulated device. (In the Developer Centre or via the SDK API, pair a virtual glasses device with your app.) The app should treat it like a real device – e.g., showing “Connected” and streaming a dummy video feed.
• Expected result: A successful connection message in-app (e.g. “Glasses Connected”) and at least one event, such as a preview frame from the camera or a log message indicating the session started.

If the connection fails or no events come through, double-check the following: pairing status (did the Meta AI app approve the connection?), all necessary permissions (camera, Bluetooth) are granted, your phone’s Bluetooth is on, and that you’re using the correct SDK version. For simulated testing, ensure you have properly initialised the mock device and provided any required sample media or permissions in the simulator.

Core Concepts You’ll Use in Every Feature

Understanding these fundamentals will help you build any glasses-enabled functionality:

1) Connection Lifecycle

• Connect/Disconnect Handling: Your app must initiate a secure session with the glasses through the Meta AI companion app. Handle the connect flow (usually via a provided Connect button UI from the SDK) and listen for disconnect events. Ensure you handle unexpected drops (e.g. glasses power off or go out of range) by prompting the user to reconnect or retry gracefully.
• Foreground/Background Behaviour: Decide what happens if your app goes to the background. The Device Access Toolkit manages session interruptions (e.g. incoming phone calls or the user taking off the glasses) and will notify you of state changes. Typically, video streaming will pause if the app is backgrounded or an interruption occurs – design your app to either maintain the session alive (if appropriate) or to gracefully pause/stop streaming when not active.
• Reconnect strategy: Implement a strategy for reconnection. For example, automatically attempt to reconnect if the connection is lost unexpectedly (with sensible limits to avoid battery drain). This ensures a smoother experience instead of a “works once and then you have to restart” situation. Timeouts and user prompts (“Tap to reconnect your glasses”) are good practices to include.

2) Permissions & Capabilities

• Runtime permissions: Meta’s glasses require various phone permissions to function. Your app needs camera and microphone access (for video/audio streaming), Bluetooth access (to communicate with the glasses), and perhaps local network permissions depending on implementation. Always request these at runtime and handle denial gracefully (e.g., show a dialog explaining why the permission is needed).
• Capability checks: Not all glasses models have the same features. Currently, the preview supports camera streaming and audio via Bluetooth. Note that there is no display API yet; you cannot send content to the glasses’ HUD in this toolkit. Consult the official FAQ for the latest capability updates. Build your features accordingly, and use feature flags or checks for capabilities (e.g., if a future model adds a display, your app might detect and use it, but for now assume camera/audio only).
• Simulated permission prompts: When using the Mock Device Kit, you can simulate the permission flow as well. The toolkit allows you to programmatically mimic the user granting or denying permissions in tests. Detailed guides on simulating these interactions are available in the SDK documentation. Use this to test how your app reacts (e.g., ensure a helpful message if the “glasses camera” isn’t allowed). Even though it’s simulated, keep your permission handling code the same as it would be for a real user.

3) Events → Actions Pattern

• Events (from glasses): Glasses will generate events that your app can listen for. Examples include a camera frame ready, a photo captured, a button tap on the glasses frame, or state changes (e.g. glasses put on or removed). In the Device Access Toolkit, you subscribe to these events via the SDK. For instance, you might subscribe to a “camera stream started” event or a “user tapped button” event.
• Actions (in app): In response to events, your app performs actions. This could mean navigating to a certain screen, triggering a function, or sending data to a server. Design your glasses integration such that it mostly reacts to what the glasses are doing. For example: “On voice command event → perform a search in the app,” or “On glasses button press → capture a photo and save to gallery.”
• Decoupling logic: Keep the event handling decoupled from hardware specifics. Your app logic should not care whether an event came from a real device or the simulator. This way, your automated tests (which inject simulated events) can use the same code path as a real session. Following this pattern ensures that if your tests pass with the mock device, the app will behave similarly with actual glasses.

Build Your First Glasses-Enabled Workflow

This section is intentionally generic so you can plug in any capability as your first use case.

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

Good first features are ones you can quickly see working and that don’t require a lot of complex setup. They should also be low-risk (not mission-critical) but still meaningful to your app’s context. For example, consider features like:

• “Tap on glasses → open a specific screen in the phone app.” (E.g., user taps the glasses’ frame and your app opens a notification or a particular activity/view.)
• “Voice intent → start a predefined workflow.” (E.g., saying a trigger phrase while wearing the glasses causes your app to perform an action like logging a marker or fetching data.)
• “Capture trigger → send a placeholder payload to the phone app.” (E.g., double-press the glasses to simulate capturing something, and your app receives an event and sends a test notification or log.)

Each of these can be observed immediately (so you know it works), doesn’t require full end-to-end pipelines, but still provides value or at least a proof of concept.

Implementation Template (Pseudo-Code)

// 1) Initialise the SDK (set up your toolkit client)
sdk = MetaWearablesSDK.initialise(appContext)

// 2) Request/verify permissions
if (!sdk.hasRequiredPermissions()) {
    sdk.requestPermissions()  // triggers camera/mic/Bluetooth prompts
}

// 3) Connect to device (real or mock)
sdk.connect(deviceId_or_mock)

// 4) Subscribe to events
sdk.on("glasses_event", (event) => {
    handleGlassesEvent(event)
})

// 5) On event: call an app action (local function)
function handleGlassesEvent(event) {
    if (event.type == "TAP") {
       performAppAction()
    }
}

// 6) Show user feedback (e.g., status & errors)
updateUI(sdk.connectionStatus, sdk.lastError)

// 7) Log key lifecycle states (for debugging/support)
sdk.on("session_state_change", logStateChange)

(The above is a pseudo-code outline. The real SDK will have specific classes and methods, but this illustrates the flow. For example, on iOS you might use a delegate or combine framework to observe events, and on Android you might use listeners or LiveData.)

Minimal UX Requirements (Don’t Skip These)

Even for a quick prototype, make sure to include a few critical user experience elements:

• Clear connection status: Always indicate to the user whether the glasses are Connected, Disconnected, or Reconnecting. For instance, show an icon or text in your app’s UI (green dot for connected, grey for disconnected). This is essential for trust – users need to know if their wearable is linked.
• Error messages with guidance: If something goes wrong (e.g., “Bluetooth permission not granted” or “Glasses disconnected due to timeout”), provide a clear message and a next step. For example: “Glasses disconnected. Tap to retry or check that your glasses are powered on.” Avoid silent failures.
• Fallback path: Ensure the user can complete the primary task without the glasses if needed. Since wearables might not always be available, your app should have a fallback. For example, if the glasses-triggered workflow is “capture a photo”, also allow the user to capture via the phone’s camera as a backup. This way, a missing or offline glasses doesn’t dead-end the user’s experience.

Testing & Troubleshooting

One of the biggest benefits of the Device Access Toolkit is the ability to test thoroughly without needing the physical glasses each time. Meta’s Mock Device Kit enables you to simulate both typical and edge-case scenarios in a controlled way. This means you can write automated tests to cover scenarios like connection drops, permission denials, and even camera feed input variations.

Using the Mock Device Kit, you can simulate devices and their behaviour via code. For example, you can programmatically pair a virtual Ray-Ban glasses, feed a test video file as the camera input, and toggle the glasses state (on head/off head) within a test case. This allows you to assert that your app responds correctly (e.g., starts processing frames, pauses when glasses are “removed”, etc.), all in an automated test environment. Whether you’re writing integration tests or doing manual exploratory testing, leverage this simulation to cover both success and failure cases.

Test Matrix

Below is a suggested test matrix covering important scenarios for a glasses-connected app, and what you should expect in each case:

Common Gotchas

• Forgetting runtime permission requests: It’s easy to include a permission in your app config (Info.plist or AndroidManifest) but forget to request it in code. Ensure your app actually prompts the user for camera, mic, etc., otherwise features will not work (especially on iOS where usage descriptions must be present or the app will crash on access).
• Build signing or provisioning issues (iOS): Running on a real device requires a signing certificate and provisioning profile. If you run into build errors, check that your Xcode project has a valid Team selected and the bundle ID is registered (especially if you created a new App ID for this project).
• Android background limits: Some Android devices aggressively kill background services to save battery. If your app tries to maintain a connection or stream in the background, test on a device (or emulator) with typical battery optimisation settings. You may need to advise users to allow your app to run in background for continuous features.
• Missing reconnection logic: A common mistake is to handle the initial connection but not implement what happens if the glasses disconnect. This leads to demos that only work once. Always implement the onDisconnected handler to allow the user to reconnect without restarting the app.
• Over-reliance on simulation: While the Mock Device Kit is powerful, remember to test on a real device (glasses) when possible. Simulation might not capture real-world factors like Bluetooth latency, Wi-Fi interference on video streaming, or user habits (like putting the glasses in a case, which turns them off). Use simulated tests to cover lots of ground, but treat a real-world test as the final validation.

Privacy, Security, and AU Notes

Building glasses integrations means handling potentially sensitive data (camera and microphone input from a user’s perspective). Here are some practical default practices to protect users and comply with regulations:

Practical Defaults

AU context: If your application will handle personal information (which it likely will, given camera/audio data), ensure you align with Australia’s Privacy Act 1988 principles – especially around consent, data use, and disclosure. Be transparent in your privacy policy about what is captured via the glasses (e.g. photos, audio) and how it’s used. Also, for more regulated industries or enterprise use, consider mapping your security controls to the Australian Essential Eight framework where applicable (this can help in government or corporate adoption by showing you meet a baseline of security practices).

Remember that any live camera or audio usage should respect privacy by design. For example, if your glasses app streams video, perhaps indicate this to the user (the glasses themselves have an LED for others nearby). As a developer, it’s good practice (and builds user trust) to make these features opt-in and clearly signposted.

Production Readiness Checklist

Before you consider your glasses-integrated feature production-ready, make sure you’ve covered the following:

• Robust connect/reconnect: The app handles initial connection and any reconnections seamlessly (including UI feedback during connecting).
• Graceful permission handling: All required permissions are requested, and if the user initially denies, the app guides them to enable it (or disables the glasses features with a message).
• Feature flags or fallbacks: If you used any preview or experimental SDK features, wrap them in feature flags. This way you can disable the glasses integration remotely if something goes wrong, or if the user is not in a supported region. Also have fallbacks for when glasses aren’t present.
• Crash and event logging: Integrate analytics or logging for key events (e.g., connection success/fail, streaming start/stop) and any crashes. This log data (with user consent) will help troubleshoot issues in the field.
• Device/version compatibility: Document which glasses models and phone OS versions you tested with. For instance, note that it’s validated on Ray-Ban Meta (2nd gen) with iOS 17 and Android 13. If any known issues exist on certain devices, handle or communicate them.
• Onboarding UX: Run through the entire first-time user experience with someone new. It should be straightforward enough that a non-developer can get the glasses connected and feature working without confusion. Little touches like in-app help text for each step go a long way.
• Automated test coverage: Where possible, include integration tests that utilise the Mock Device Kit to run through key use cases (connection, an event trigger, etc.) as part of your CI pipeline. This helps catch regressions by simulating the glasses in every build.

Next Steps

• Pick your next glasses feature (perhaps a more advanced one utilising the camera or audio) and apply the same Events → Actions pattern to build it out. Expand gradually, one capability at a time.
• Replace any placeholder or mock actions with real workflows. For example, if your first feature just logged a message on a voice command, now wire it up to a real API call or a meaningful app function.
• Prepare for a small internal beta: if you have colleagues or a test group with access to the glasses (or willing to use the simulator), distribute the app to them via the Wearables Developer Center release channels. Gather feedback on the UX, reliability, and any confusion points in the setup.

Need help hardening the integration or planning a broader rollout? Cybergarden can help you go from prototype → production with expertise in native modules, event-driven architecture, automated testing, and privacy-by-design for wearable integrations. Don’t hesitate to reach out for guidance or development support.

FAQs

Do I need preview access to use the toolkit?

Yes. As of early 2026, the Meta Wearables Device Access Toolkit is in a developer preview. You’ll need to sign up through the official Meta Wearables preview programme to get SDK access. Once you have access, you can download the SDK and sample apps from the official developer portal. Keep in mind that during the preview, you can build and test within your organisation, but only select partners can publish integrations to the public. In short: get the official preview access first, then follow the documentation to set up the SDK in your app.

Can I build with React Native or Flutter?

Absolutely – but with some caveats. The Wearables SDK is native (Java/Kotlin for Android, Swift for iOS). To use it in React Native or Flutter, you’ll need to write a thin native module or plugin that bridges between the SDK and your framework. The good news is that the SDK’s focus (connect, stream, send events) can be isolated in a native layer, while your business logic remains in JavaScript or Dart. In practice, this means you build the core glasses integration natively, expose methods/events to your RN/Flutter app, and keep the rest of your app cross-platform. Many developers use this approach: use the native SDK where necessary, and communicate with the cross-platform layer via events or callbacks.

What’s the fastest path to a working demo?

Use the official sample app as your starting point. Get it running and confirm you can connect to a real or mock device and receive one event (for example, start a camera stream and see frames coming in). This proves your setup is correct. Then, in your own app or a fork of the sample, wire up a single event to a simple action in the app. For instance, take the “glasses button tap” event and make it trigger a notification or change a label in the app – something visibly different. With the Mock Device Kit, you can even automate this: simulate the button press event and see if your app responds as expected. By limiting scope to one event→action loop with clear user feedback, you can get a compelling demo in very little time. Once that’s working, you can iterate and add more complexity.