Levandor

DIY Continuity Camera / Camo clone — direct-connection phone camera (research)

11 min read

SUPERSEDED — the Wi-Fi Aware architecture in this note is INVALID (2026-08-18)

WiFiAware.framework is @available(macOS, unavailable). It cannot be used for anything involving a Mac — not natively, not via Mac Catalyst. Verified twice, independently, from the SDK headers in Xcode 26.3. Everything below that calls Wi-Fi Aware “the breakthrough” or “the winning path” is wrong, and the recommended architecture built on it is dead.

Also wrong: Wi-Fi Aware is not a DMA/EU-driven replacement for AWDL. AWDL was never removed. On this Mac (macOS 26.5.1) awdl0 is UP and RUNNING with 26.8 MB inbound, and llw0 — same MAC, same radio — has carried 11.5 GB. Wi-Fi Aware ships alongside AWDL, not instead of it.

➡️ Read aposemati-transport-findings instead. Project overview: aposemati.

This note is kept as a record, not deleted — its central thesis was correct and still governs the project: the transport is the product, not the camera pipeline. The reasoning about Camo’s router dependency, the virtual-camera problem, and the “just use Continuity?” gate all still hold.

Research brief and build plan for a self-built phone-as-camera tool — a Reincubate Camo / Apple Continuity Camera clone whose defining feature is a direct device-to-device connection that stays OFF the WiFi router. Source device must be an iPhone. This note is self-contained: a building agent with zero prior context can start from it.

Read this decision FIRST, before building anything

If the real requirement is purely “a flawless wireless iPhone webcam,” Apple Continuity Camera already IS that and a clone cannot beat it — Continuity uses a private transport (AWDL) you cannot legally or technically replicate, so any wireless clone is strictly worse. This project only makes sense if you need something Continuity lacks: high-quality local RECORDING, capture/integration into the homelab (telep-mainframe), custom controls, use inside an app that doesn’t support Continuity, or a non-Apple receiver. Confirm which of these is the goal before writing code. If none apply, the correct answer is “just use Continuity Camera.”

Goal

Build our own phone-as-camera tool with:

  • High image quality
  • Low latency
  • “Fast recording” (quick capture-to-disk)
  • A DIRECT device-to-device connection that does not route through the WiFi access point — this is the whole point of the project.
  • Source device MUST be Apple / iPhone. (“We need Apple.“)

Nice-to-haves:

  • Record into the homelab (telep-mainframe, which already runs go2rtc + Frigate for RTSP recording and has an RTX 3080 for hardware transcode).
  • Expose the stream as a virtual webcam on the receiver so any app (Zoom, OBS, browser) can use it.

Motivation — the key insight

The differentiator is the TRANSPORT, not the camera

  • Reincubate Camo drops the connection when the devices are far from the WiFi AP, because Camo routes its video over the WiFi/LAN: phone → access point → receiver. Both devices are therefore at the mercy of their individual link quality to the router. Walk away from the AP and the stream dies.
  • Apple Continuity Camera works flawlessly at the same range because it does not use the WiFi network at all. It streams over a direct peer-to-peer link (historically AWDL — Apple Wireless Direct Link). Router distance is irrelevant; only the iPhone↔Mac distance matters.
  • Therefore: to rival Continuity, you must get the stream OFF the routed WiFi network — either a wired/USB link or a true peer-to-peer WiFi link. Anything that hairpins through the AP inherits Camo’s failure mode. Camera pipeline quality is secondary; the transport is the product.

The transport options

OptionHow it worksFeasibility on iOSNotes
USBiPhone exposes its camera/video over the USB connection; grab it on the host as a capture device.Available. Apple exposes iPhone video over USB — this is how QuickTime screen-records an iPhone and how Camo’s USB mode works. On macOS, a plugged-in iPhone appears as an AVFoundation capture device: ffmpeg -f avfoundation -i "iPhone Camera".Lowest latency, most reliable “direct” link, ~20–40 ms. Wired (tethered). Best fallback / max-reliability path. Android equivalent for reference: scrcpy v2+ camera mode over USB → v4l2loopback/OBS — but source must be Apple here.
AWDL (Apple Wireless Direct Link)The private peer-to-peer radio protocol that makes Continuity “magic.”Impossible to build on. Proprietary, Apple-only, no public API.You cannot construct a clone on AWDL. Any AWDL-free wireless clone is strictly worse than Continuity. Listed only to explain why Continuity works and to close the door on copying it.
Wi-Fi Aware (NAN) ⭐Apple’s public Wi-Fi Aware framework (developer.apple.com/documentation/wifiaware), introduced WWDC 2025 (iOS/macOS 26 era) as the standardized, DMA/EU-interoperability-driven replacement for AWDL ⛔ (FALSE — AWDL was never replaced). Built on the Wi-Fi Alliance Wi-Fi Aware standard (NAN — Neighbor Awareness Networking). Provides a public API for device-to-device discovery + secure pairing + a direct socket-style DATA PATH with no access point in the middle.Buildable — this is the breakthrough. ⛔ NOT buildable with a Mac — @available(macOS, unavailable). For the first time this gives exactly the off-router direct connection we want, with a supported public API.Because it is the industry NAN standard, it is interoperable: the receiver need not be Apple. Mac via the framework, Android via NAN (supported since Android 8), or Linux if the WiFi adapter supports NAN — Linux NAN support is spotty/experimental. New, so validate throughput/latency before committing.
Dedicated-hotspot / WiFi-Direct fallbackPut phone + receiver on their own isolated link (phone hotspot, or a spare 5 GHz radio) to escape the congested main router.Simple, works today.Not truly peer-to-peer and worse than Wi-Fi Aware, but at least gets off the shared/congested main AP. Reasonable stopgap if Wi-Fi Aware support isn’t present on the hardware.

The winning path

Wi-Fi Aware is the wireless answer (public API + off-router direct data path + cross-platform via NAN). USB is the wired fallback for maximum reliability and lowest latency. Everything else is either impossible (AWDL) or inferior (hotspot).

CORRECTION (2026-08-18) — the "winning path" above is void

Wi-Fi Aware is iOS/iPadOS only. Five independent proofs, all agreeing:

  1. Every public declaration carries @available(macOS, unavailable).
  2. Mac Catalyst fails with no such module 'WiFiAware' — and there is no -macabi swiftinterface. Network.framework has one, so this is not a packaging quirk.
  3. It is absent from the SDK’s System/iOSSupport tree, which holds 118 other Catalyst frameworks.
  4. Xcode’s WIFI_AWARE provisioning capability record lists "supportedSDKs": [{"name": "IOS"}].
  5. DeviceDiscoveryUI (required for its pairing flow) is also absent from the macOS SDK.

The dylib does exist in the macOS 26.5 dyld shared cache with 739 exports — Apple laid groundwork — but every public API is gated off and there is no NAN interface on macOS. Do not read hope into it.

On AWDL: “the EU killed AWDL” is FALSE. awdl0 and llw0 are live and busy; sharingd, rapportd and wifip2pd are all running. There is still no public API to AWDL (NWInterface.InterfaceSubtype.wifiAWDL is SPI and will not compile) — but Multipeer Connectivity is not deprecated (deprecated: null on all six platforms) and NWParameters.includePeerToPeer is public, undeprecated, macOS 10.14+. That is now the primary candidate.

Full evidence: aposemati-transport-findings.

flowchart LR
    subgraph iPhone [iPhone — publisher]
        A[AVFoundation capture] --> B[VideoToolbox HW encode<br/>HEVC / H.264]
        B --> C[Wi-Fi Aware data path<br/>publisher role]
    end
    C -. direct P2P, no AP .-> D
    subgraph Receiver [Receiver — subscriber]
        D[Wi-Fi Aware subscriber] --> E[Decode]
        E --> F1[Virtual camera device]
        E --> F2[Record to disk]
        E --> F3[Stream into homelab]
    end
    F3 -. RTSP / go2rtc .-> G[[telep-mainframe<br/>Frigate + RTX 3080]]

iPhone app (publisher)

  1. Capture the camera via AVFoundation.
  2. Hardware-encode to HEVC or H.264 via VideoToolbox — this is what delivers quality + low CPU + low latency. Do not software-encode.
  3. Send the encoded stream over the Wi-Fi Aware data path in the publisher role. Discover + pair + connect directly, off the router.

Receiver app (subscriber)

  1. Wi-Fi Aware subscriber → receive the stream.
  2. Decode.
  3. Then one or more of:
    • Expose as a VIRTUAL CAMERA so any app can consume it. This is the fiddly, OS-specific piece — the same problem OBS Virtual Cam solves:
      • macOS: CoreMediaIO Camera Extension / CMIO system extension.
      • Windows: Media Foundation / DirectShow virtual camera.
      • Linux: v4l2loopback.
    • Record to disk (“fast recording”).
    • Stream into the homelab (telep-mainframe) for recording via go2rtc/Frigate.

USB path (fallback / max reliability)

  • iPhone → USB → ffmpeg / AVFoundation on the Mac → virtual cam or record.
  • Or pipe that into the mainframe (which already runs go2rtc/Frigate for RTSP recording, RTX 3080 for HW transcode).
  • Lowest latency and most robust; use when wireless is unnecessary or Wi-Fi Aware hardware support is missing.

Caveats / open questions for the building agent

Validate these before committing to the Wi-Fi Aware design

  • OS + hardware requirements: Wi-Fi Aware needs recent iOS/macOS (26+) AND Wi-Fi-Aware-capable hardware on BOTH ends. Verify against the Apple doc and the specific device specs — do not assume.
  • Receiver support is the real risk: the receiver must also support Wi-Fi Aware. Mac (framework) or Android (NAN) are fine. A Linux / mainframe receiver depends on the WiFi adapter’s NAN support, which is limited/experimental — this is a genuine open question if the goal is to use telep-mainframe as the direct receiver. If the mainframe must be the direct endpoint, resolve NAN adapter support early or fall back to USB / hotspot + RTSP into go2rtc.
  • Wi-Fi Aware is NEW: throughput and latency for a live encoded video stream are unproven for this use. Bandwidth/latency-test early — build a proof-of-concept before committing the whole pipeline.
  • The virtual-camera device is the known-finicky part: the CMIO Camera Extension on macOS is fiddly (signing, system extension approval, lifecycle). Reference how OBS Virtual Cam / obs-mac-virtualcam does it rather than reinventing.
  • The requirement question (repeat of the top callout): decide the real need. If it’s purely “flawless wireless iPhone webcam,” Continuity already is that and a clone can’t beat it. The project only justifies itself for high-quality RECORDING, homelab capture/integration, custom controls, use in a non-supported app, or a non-Apple receiver. Flag this decision prominently before building.

Existing things to reuse (don’t reinvent)

  • scrcpy — Android USB camera path (reference implementation of phone-over-USB → virtual cam; not the Apple path but instructive).
  • OBS + OBS Virtual Camera — the canonical virtual-webcam sink on all three OSes.
  • v4l2loopback — Linux virtual camera device.
  • obs-mac-virtualcam / CMIO Camera Extension sample code — reference for the macOS virtual camera extension.
  • ffmpeg avfoundation input — ffmpeg -f avfoundation -i "iPhone Camera" for the USB capture path on macOS.
  • WebRTC — if a non-Wi-Fi-Aware wireless fallback is ever needed (e.g. over the dedicated-hotspot link), WebRTC gives a mature low-latency encoded-media transport with NAT traversal.

References

For the building agent — suggested first steps

  1. Confirm the actual requirement vs just using Continuity. If the need is only “flawless wireless iPhone webcam,” stop — use Continuity Camera. Proceed only if you need recording, homelab capture, custom control, an unsupported app, or a non-Apple receiver.
  2. Verify Wi-Fi Aware OS + hardware support on the specific iPhone AND the intended receiver (Mac / Android / Linux adapter). Check iOS/macOS ≥ 26 and Wi-Fi-Aware-capable radios on both ends. If the receiver is telep-mainframe, settle the Linux NAN adapter question here.
  3. Build a minimal Wi-Fi Aware data-path PoC (publisher ↔ subscriber, discovery + pairing + a socket) and measure throughput and latency with a dummy stream before building any video pipeline. Kill the design early if the numbers can’t carry an encoded video feed.
  4. Then build the two halves: capture → VideoToolbox encode → Wi-Fi Aware send (iPhone), and Wi-Fi Aware receive → decode → virtual cam / record (receiver). Keep the USB + ffmpeg/AVFoundation path as a parallel fallback for max reliability.

Graph View

Backlinks