dat-conventions

Patrones de Swift, async/await, convenciones de nomenclatura, tipos clave para el desarrollo de DAT SDK en iOS

npx skills add https://github.com/facebook/meta-wearables-dat-ios --skill dat-conventions

DAT SDK Conventions (iOS)

Architecture

The public SDK is organized into these modules:

  • MWDATCore: Device discovery, registration, permissions, device selectors, DeviceSession
  • MWDATCamera: Camera, Stream, VideoFrame, photo capture
  • MWDATDisplay: Display capability, display UI components, icons, images, buttons, video
  • MWDATMockDevice: MockDeviceKit for testing without hardware
  • MWDATMockDeviceTestClient: MockDeviceTestClient for driving MockDeviceKit over HTTP from a UI-test process

Swift Patterns

  • Use async/await for all SDK operations — the SDK is fully async
  • Use AsyncSequence / publisher .listen {} for observing streams
  • Annotate UI-updating code with @MainActor
  • Never block the main thread with frame processing
  • Handle errors with do/catch — the SDK throws typed errors

Naming Conventions

TypeConventionExample
Entry pointWearables.sharedWearables.shared.startRegistration()
Device sessions*SessionDeviceSession
CapabilitiesNamed by functionStream
Selectors*DeviceSelectorAutoDeviceSelector, SpecificDeviceSelector
Config*ConfigurationStreamConfiguration
Publishers*PublisherstatePublisher, videoFramePublisher

Imports

import MWDATCore    // Registration, devices, permissions
import MWDATCamera  // Stream, VideoFrame, photo capture
import MWDATDisplay // Display, FlexBox, Text, Button, Image, Icon, VideoPlayer

For testing:

import MWDATMockDevice  // MockDeviceKit, MockGlasses, MockCameraKit

Key Types

  • Wearables — SDK entry point. Call Wearables.configure() at launch, then use Wearables.shared (an any WearablesInterface)
  • DeviceSession — The connection to a selected device. Create with createSession(deviceSelector:), then attach capabilities
  • Camera — Camera capability from session.addCamera(config:); owns camera.stream
  • Stream — Camera stream: start(), stop(), capturePhoto(format:), and the frame/state/photo/error publishers
  • Display — Display capability from session.addDisplay()
  • VideoFrame — Individual video frame with .makeUIImage() and .sampleBuffer
  • Device / DeviceIdentifier — DeviceIdentifier is a String; resolve a Device with deviceForIdentifier(_:)
  • AutoDeviceSelector — Selects the best available device, optionally filtered (filter: { $0.supportsDisplay() })
  • SpecificDeviceSelector — Selects a specific device by DeviceIdentifier
  • StreamConfiguration — Configure video codec, resolution, frame rate
  • ListenerTokenBag / AnyListenerToken — Keep .listen {} subscriptions alive; dropping a token cancels it
  • MockDeviceKit — Factory for creating simulated devices in tests

Error Handling

do {
    try Wearables.configure()
} catch {
    // Handle configuration error
}

do {
    try await Wearables.shared.startRegistration()
} catch {
    // Handle registration error
}

Build and Test

# Install dependencies via Swift Package Manager
# In Xcode: File > Add Package Dependencies > enter repo URL

# Build from command line
xcodebuild -scheme MWDATCore -destination 'platform=iOS Simulator,name=iPhone 16'

# Run tests
xcodebuild test -scheme MWDATCoreTests -destination 'platform=iOS Simulator,name=iPhone 16'

For sample apps:

# Open the sample app workspace
open ExternalSampleApps/CameraAccess/CameraAccess.xcodeproj

# Build and run on simulator (uses MockDeviceKit - no glasses needed)
xcodebuild -scheme CameraAccess -destination 'platform=iOS Simulator,name=iPhone 16'

Development Workflow

  1. Add SDK via Swift Package Manager (SPM) in Xcode
  2. Import modules (MWDATCore, MWDATCamera, MWDATDisplay when rendering Display content)
  3. Configure at app launch: try Wearables.configure()
  4. Build with Xcode or xcodebuild
  5. Test with MockDeviceKit - no physical glasses required
  6. Debug using Xcode console for SDK logs

Live docs search

If your editor supports remote MCP servers, connect https://mcp.developer.meta.com/wearables and use search_dat_docs for current DAT setup, session lifecycle, camera streaming, MockDeviceKit, permissions, and exact API symbols. This public docs server does not require authentication; do not configure tokens, OAuth, or custom authorization headers for it.

See the dat-docs-mcp skill for Claude Code, Cursor, and MCP Inspector setup and troubleshooting.

Use llms.txt when your tool only supports static reference context.

Links

Más skills de facebook

gc-safe-coding
facebook
Para la explicación completa y el fundamento, consulta doc/GCSafeCoding.md.
app-review-prep
facebook
Prepara una app de Meta para App Review: comprueba el estado actual, los requisitos pendientes, los privilegios concedidos y el historial de envíos. Úsalo antes de enviar una app…
api-health
facebook
Monitorea la salud de la API para una app de Meta: verifica límites de tasa, volumen de llamadas y deprecaciones de API. Úsalo para diagnosticar limitaciones, planificar capacidad o prepararse para versiones de API…
debug-webhooks
facebook
Soluciona problemas de webhooks para una aplicación de Meta — inspecciona las suscripciones activas, identifica configuraciones incorrectas y envía cargas de prueba para verificar la entrega. Usa cuando…
api-integration
facebook
Guía a un desarrollador para configurar una integración de la API de Meta desde cero: descubre las APIs adecuadas, obtiene guías de configuración, requisitos de autenticación,…
webhook-setup
facebook
Configura webhooks para una app de Meta de principio a fin: descubre los temas disponibles, suscríbete a campos y verifica con una carga de prueba. Úsalo al configurar webhooks para…
test-ui
facebook
Prueba el sistema de UI (PanelUI, ScreenSpace) contra el ejemplo de poke usando la CLI de iwsdk.
flags
facebook
We need to translate the given text from English to Spanish. The text describes a skill for inspecting and comparing feature flag states across React release channels. We must preserve product names, protocol names, URLs, numbers, and technical terms. The name "flags" is not in the text, so we don't include it. We translate only the text inside <text>. No extra commentary, labels, etc. The text: "Inspect and compare feature flag states across React release channels. View all flags across channels (www, www-modern, canary, next, experimental, rn variants) or compare specific channels with --diff Output formats include default table view, CSV export, and cleanup status grouping Flag states indicated by symbols: enabled (✅), disabled (❌), variant testing (🧪), profiling-only (📊) Common pitfall: __VARIANT__ flags are tested in both states on www; use --diff to spot meaningful..." We need to translate to Spanish. Keep technical terms like "React", "www", "www-modern", "canary",