Commit activity
Last 12 weeks · 3 commits
Community health
4 of 6 standards met
75
✓README✓License✓Contributing✓Code of Conduct○Issue Template○PR Template
Recent PRs & issues
Active · 3 in progress · Last activity 6d ago
See all on GitHub →
Folding the glasses mid-session intermittently crashes the app with a (null pointer + offset) entirely inside the SDK — there are zero application frames on the crashing thread. The crashing thread is the SDK's own WARP , which is attempting to open a datax channel against a connection whose internal channel map has already been torn down by the fold (or is not yet built). Environment SDK: Meta Wearables DAT iOS 0.7.0 (revision ) Glasses: Ray-Ban Meta (Gen 2) iPhone / iOS: iPhone 17 (iPhone18,3) / iOS 26.5 Trigger: physically folding the glasses while a video stream session is live Frequency: intermittent — a timing race, not deterministic (folds 0/2 → 2/2 across rebuilds of identical source; see "Not a layout/duplicate-symbol issue" below) Symbolicated crashing stack Symbolicated via against the vendored / arm64 slices ( vmaddr = 0). Bottom → top: Two on-device MetricKit reports captured byte-identical crashing threads. Diagnosis This looks like a lifecycle race in MWDATCore's datax connection layer*: the autonomous WARP event thread races a channel- against the connection teardown that the fold triggers. The hash-table lookup dereferences a null/freed connection channel map. It is the same family as the SDK's known fragility around abrupt link loss (a back-to-back / after an error wedges the SDK until a fold/unfold — we never auto-retry because of it). Not a layout / duplicate-symbol issue We initially suspected our own off-actor frame closure (a Swift-6 concurrency refactor appeared to "cause" it, 2/2 crash). It does not — a fresh rebuild of the same source folded 0/2. The refactor only shifted the race window* via closure timing. The SwiftProtobuf double-embed warning is not in this stack, and the earlier "duplicate-symbol clash" lead is refuted by the crash data. We don't call anywhere — every frame on the crashing thread is SDK-owned. Question 1. Can explicit session/connection teardown on fold (e.g. on / a watchdog path) stop the WARP from attempting a channel- after the connection's channel map is gone? 2. Is there an app-side ordering we can adopt to close this window, or is this a vendor-side fix in the datax connection lifecycle? Happy to provide the full MetricKit payloads.
Hi team, used AI to write a thorough description of what I'm seeing with iPhone 17e (I can't even connect the official CameraAccess sample): Summary I’m seeing a persistent Meta AI registration failure on one specific iPhone. I can reproduce it with the official CameraAccess sample app, so this does not appear to be app-specific. Error shown In Meta AI app during registration approval: _Internal error The operation could not be completed_ What I tested My own app: fails on this device Official sample: samples/CameraAccess also fails on this device Same glasses + same account + same flow works on another iPhone A/B result Fails: iPhone 17e (iPhone18,5), iOS 26.5.1 Works: iPhone 16 Pro Max (iPhone17,2), iOS 26.5 Both tested with current Xcode toolchain and same developer team/signing approach Environment on failing device iPhone model: iPhone 17e iOS: 26.5.1 Meta AI app: latest available from App Store at test time Glasses: Ray-Ban Meta (same unit that works on other iPhone) DAT SDK sample: CameraAccess from official repo Developer Mode: enabled on iPhone and Meta AI app flow completed Device reset: full reset performed; issue persists Supervision: removed (device reset and configured as normal) Repro steps Build/install official CameraAccess sample on failing iPhone. Open app and tap connect/register. Meta AI opens. During app-to-glasses approval, Meta AI shows: Internal error The operation could not be completed Registration does not complete; app returns to non-registered state. Expected result Meta AI should complete approval and return control to the app with successful registration. Actual result Meta AI shows internal error and registration aborts. Additional notes I also see the log: unable to make sandbox extension: [2: No such file or directory] (I understand from prior maintainer comments this is non-blocking and likely not the root cause.) Because the same sample works on another iPhone with the same account/glasses, this looks device/model-specific or companion-app-flow specific. Related thread Discussion #195: https://github.com/facebook/meta-wearables-dat-ios/discussions/195 Happy to provide screen recordings and sysdiagnose/logs if useful.
Two small developer-experience gaps in the permission API. Both are trivial to fix and cost real time to discover. 1. does not conform to For a simple enum-like status type this is surprising — the natural first attempt () fails to compile, and the reason isn't obvious from the diagnostic. Adding conformance would make the API behave the way every caller expects. 2. raw values are undocumented When a permission call fails, logs and crash reports often carry only the raw value, and there is no table anywhere in the docs to map them back. We had to reverse-engineer them: (Observed on 0.7.0; please correct if any are wrong — which is itself the argument for documenting them.) Requested: either document the raw values, or add a conformance so the case name appears in string interpolation and logs. The new unified protocol in 0.8.0 looks like a natural place for the latter. Environment meta-wearables-dat-ios 0.7.0 iPhone 13, iOS 26.4.x, Ray-Ban Meta (Gen 2)
Recent fixes
I realize that the SDK doesn't provide IMU data access at the moment, curious if this is on the roadmap.
Hi my understanding is that for the iOS sdk the only events are tap. I need additional event listeners around focus to handle user inputs of left right up down to perform custom focus around the ui. I also want to be able to focus different flexboxes or buttons in the ui.
Following up on #32 and #49, where a maintainer said button handling "may change in future" but isn't in the SDK yet. Filing this as a concrete request to prioritize it, since it keeps coming up. Right now the physical capture button does nothing while a DAT app owns the device, so the only way to trigger is a software call driven from the phone. For a hands free app that's the one thing you don't want: the user has to stop and tap the phone instead of just pressing the button on the glasses they're already wearing. What I'd like: while my app has an active session/stream it owns, deliver the capture button press to the app so I can handle it myself (call , start/stop a clip, mark a moment, whatever). Single vs long press distinguishable would be great. When no DAT app owns the device, the button keeps its normal native behavior, so nothing changes for everyone else. Since we already hold the session open, the press is really the only missing piece. A stream scoped publisher matching the existing ones would fit cleanly: It only fires while the app owns the session, so there's no background button snooping concern, and a capability flag keeps it non breaking. This is the most requested gap for hands free capture apps (see the comments on #32 and #49). Happy to beta test whatever you build. SDK 0.8.0, Ray-Ban Meta Gen 2 and Oakley Meta Vanguard, iOS.
Structured data for AI agents
Repository: facebook/meta-wearables-dat-ios. Description: Meta Wearables Device Access Toolkit for iOS Stars: 461, Forks: 111. Primary language: Shell. Languages: Shell (100%). Open PRs: 3, open issues: 18. Last activity: 6d ago. Community health: 75%. Top contributors: facebook-github-bot.