Commit activity
Last 12 weeks · 2 commits
Community health
4 of 6 standards met
75
✓README✓License✓Contributing✓Code of Conduct○Issue Template○PR Template
Recent PRs & issues
Active · Last activity 3w ago
See all on GitHub →
Session starts successfully and reaches .started state. Adding a camera and starting the stream reaches .starting then hangs indefinitely at waitingForDevice - never transitions to .streaming. Also intermittently seeing: "Device is not connected: [UUID]" "Internal error, the operation could not be completed" "permissionRequestExceededTimeLimit" Steps tried without resolving it: Confirmed on latest SDK (0.9.0, "Up to Next Major Version" resolved, no newer version available) Developer Mode confirmed enabled in Meta AI app (Settings > App Info > tap version 5x) Glasses firmware confirmed up to date Full app uninstall/reinstall Full phone power cycle Tested with Wi-Fi off and Wi-Fi on Confirmed camera/Bluetooth/local-network permissions all granted Mock Device Kit also fails with "device is not connected" when attempting to pair a mock device Device: iPhone 17 Pro, iOS (current) Glasses: Ray-Ban Meta Gen 2 SDK: 0.9.0 (meta-wearables-dat-ios)
DAT iOS 0.8.0 CameraAccess fails with StreamError.deviceNotConnected Summary The official CameraAccess sample from Meta Wearables DAT iOS SDK 0.8.0 discovers compatible glasses and starts DeviceSession successfully, but the camera Stream remains waitingForDevice for about 31 seconds and then fails with StreamError.deviceNotConnected. The same failure occurs in a separate application using the same SDK. This report is based on the unmodified official session and stream lifecycle, with observation-only diagnostics added. Environment SDK: Meta Wearables DAT iOS 0.8.0 SDK revision: 2e30f1253ab76ee3c448a29dce39114ab09763c3 Sample: official CameraAccess sample Device: iPhone 17 Pro iOS: 26.5.1, build 23F81 Physical Meta glasses in Developer Mode Glasses-side DAT app update completed Registration state: registered Camera permission: granted Device compatibility: compatible Device link state before session creation: connected Reproduction steps 1. Launch the official CameraAccess sample. 2. Wait for the glasses to be selected as compatible and connected. 3. Confirm camera permission is granted. 4. Tap Start streaming. 5. Observe DeviceSession and Stream state publishers. Actual result 1. DeviceSession is created in idle. 2. DeviceSession.start() changes state from starting to started. 3. addStream() is called only after DeviceSession is started. 4. Stream listeners are attached. 5. Stream.start() is called. 6. Stream changes to waitingForDevice. 7. After approximately 31 seconds, Stream changes to stopping. 8. Stream emits: StreamError.deviceNotConnected("c16f0f2b16017ccdc0d0cab516c355de") 9. Stream changes to stopped. 10. No video-frame callback arrives. Expected result The Stream should transition from waitingForDevice or starting to streaming and deliver video frames because DeviceSession is started and the selected device reports compatible and connected. Notes Restarting the app, iPhone, glasses, and Meta AI did not resolve the problem. Registration and camera permission remain valid. The attached log contains the complete official-sample lifecycle. The attached xcresult contains the physical-device automated reproduction. Meta-DAT-camera-bug-report.zip
Summary If the app is suspended or killed by the OS while a camera stream session is active, the glasses are left holding a broadcast state from the unclean teardown. After that, every subsequent fails almost instantly with — the session goes , never reaches , and no stream configuration is ever attempted. The SDK provides no programmatic way to detect this state or to clear it; the only reliable recovery is physical (glasses in the charging case, lid closed, wait 30–60 s). Symptoms Every → within ~1 s. Retries do not help — we retry 3× at 2 s intervals and every attempt fails identically. Misleading detail: the HFP microphone path may keep working in parallel, which falsely suggests the Bluetooth link is healthy. The Meta AI app shows "broadcast in progress" for the phantom session, confirming the glasses (not the phone) are holding the state. Steps to reproduce 1. Start a camera stream session ( → → stream running, frames flowing). 2. Let iOS suspend or terminate the app mid-stream without the app getting a chance to await / (e.g. memory-pressure kill, or force-quit from the app switcher while backgrounded). 3. Relaunch the app and attempt . 4. Observe the persistent loop described above. Recovery (what actually works today) In order of increasing severity — usually one of these clears it: 1. In the Meta AI app, tap Stop/End next to the "broadcast in progress" message (when the button is shown). 2. Hold the capture button on the glasses for 8–10 s. 3. Put the glasses in the charging case, close the lid, wait 30–60 s, take them out — the most reliable reset. 4. Force-quit the Meta AI app + toggle phone Bluetooth off/on. 5. Last resort: forget the device in Settings → Bluetooth and re-register. Asking end users to do any of this is not a shippable UX. What we already do app-side (prevention, insufficient by design) We layered every prevention we could find: awaited + on every user-driven exit path (no fire-and-forget ), an awaited stop in , stopping the stream on , and a observer for best-effort cleanup. This made the state much rarer — but app-side hooks fundamentally cannot cover memory-pressure kills or hard OS suspensions, which is exactly when the state develops. Requested Any one of these would unblock us, in order of preference: 1. A recovery API — e.g. (or having clear a stale device-side broadcast owned by the same app). 2. A way to detect the state — a diagnostic flag / distinct error case so the app can show targeted recovery instructions instead of a generic failure (today the error is an opaque ). 3. At minimum, documentation of this failure mode and the recovery steps in the SDK README. Related: #175 (first-class device availability/readiness state) — a along those lines with a -style case would cover the detection half of this request. This is distinct from #214 (mid-stream ghost stop on an otherwise healthy device). Environment meta-wearables-dat-ios 0.7.0 (0.8.0 changelog does not mention changes in this area) iPhone 13, iOS 26.4.x Ray-Ban Meta (Gen 2), post-June-2026 firmware
Recent fixes
Hi, Since adopting SDK 0.7.0 across our native and Flutter apps (through our own wrapper), I've been seeing an error when calling register, which never sends us the deep link callback to the Meta AI app. This is affecting both new apps as well as existing apps, regardless of the DAT version which I believe is down to the Display Glasses or the firmware on them. A restart solves this each time. Since I've not encountered this issue before, was there a backend change or is it a known bug with the latest glasses firmware? I haven't been able to test the Gen 1's yet.
MFi Product Plan / PPID authorization for com.meta.ar.wearable and App Store distributionClosedIssue
Hi Meta Wearables team, We're developing Glutt, an iOS cooking assistant that uses Meta Ray-Ban glasses to provide live visual context while a user is cooking. We've successfully implemented camera streaming using Meta Wearables DAT iOS 0.8.0 over Bluetooth Classic, using the ExternalAccessory protocol: com.meta.ar.wearable We specifically need the Bluetooth Classic transport because our use case involves maintaining a long-running camera session while the iPhone remains connected to its normal Wi-Fi network for our real-time voice assistant. The integration is now working successfully in development, and we're preparing for public App Store distribution. From our understanding of Apple's MFi / ExternalAccessory requirements, our app may need to be authorized by Meta under the appropriate MFi Product Plan, and Apple may require the associated PPID during App Review. Could you please help us understand the process for: Authorizing our app/bundle ID for use with com.meta.ar.wearable Adding our app to the appropriate MFi Product Plan, if required Providing the relevant PPID or other information we should supply to Apple during App Review Confirming whether Bluetooth Classic camera transport through DAT 0.8.0 remains supported for third-party App Store applications Our details: App: Glutt Company: CielPM, Inc. Primary bundle ID: com.omarlahmimi.glutt Share extension bundle ID: com.omarlahmimi.glutt.share Apple Team ID: Q7ZLXMG4SB ExternalAccessory protocol: com.meta.ar.wearable DAT SDK: iOS 0.8.0 Transport: Bluetooth Classic We're currently testing through DAT Developer Mode, so we do not yet have a production Meta App ID, Client Token, or Meta Team ID. We're also beginning the Wearables Developer Center registration/configuration process for production distribution. Please let us know if we should provide any additional identifiers or submit this request through a different Meta/MFi channel. Thank you!
Environment SDK: 0.9.0 Device: Ray-Ban Meta (Gen 2) Firmware: V127 (the same firmware/Developer-Mode-reinstall issue from #265, now resolved) Platform: iOS 17+, physical device via wireless debugging What's happening never leaves , indefinitely (tested up to 20s timeout), when calling → → waiting for before — following the exact pattern in your own skill doc. What's already ruled out, with evidence, not assumption: 1. state — confirmed , no thrown error, no event. 2. — confirmed (after fixing an app-side bug where our own code never re-observed after a session restart — unrelated to this report, just noting the base link itself is healthy). 3. Camera permission — confirmed via a fresh check immediately before . 4. Developer Mode — confirmed ON (green) in the Meta AI app for this specific glasses pair, immediately before testing. 5. Stale state from repeated testing — ruled out via a fully clean restart (force-quit Meta AI app + our app, relaunch, single first-attempt capture — same result). 6. Explicit — switched from the default (opaque) to explicitly passing , matching your own sample exactly. No change. 7. Active frame consumer — added a before/during the wait, in case the pipeline needs an active consumer to start flowing. No change. 8. — actively listened throughout; never fires. No of any kind is ever reported, the stream simply never transitions past . Minimal repro (structure, not literal file) Question** Is there a known cause for persisting indefinitely when every app-visible signal (session, link, permission, Developer Mode) reports healthy? Is there a camera-specific provisioning/pairing step distinct from the base DAT session that we're missing — something not covered in the or skill docs? Happy to provide device logs if there's a way to capture them from this side, or try the local DAT Inspector MCP tooling if there's a lightweight way to get it running against a real device via .
Structured data for AI agents
Repository: facebook/meta-wearables-dat-ios. Description: Meta Wearables Device Access Toolkit for iOS Stars: 517, Forks: 118. Primary language: Shell. Languages: Shell (100%). Open PRs: 3, open issues: 26. Last activity: 3w ago. Community health: 75%. Top contributors: facebook-github-bot.