This is a bit complicated to explain so bare with me. I am working on building an app that allows you to send real time video/camera captures from one Apple device to another. I am using a custom UDP protocol built on top of NWListener, NWBrowser, and NWConnection APIs. It works fine, but there are a few issues that seems to all be related to awdl:
-
When transmitting via WiFi over the router (not using peer-to-peer), there are periodic interruptions when the wireless card on the device changes channels for awdl polling. This is resolved by changing the 5GHz WiFi channel on the router to channel 149 (or disabling AWDL altogether which is not really feasible).
-
In order to work around number 1, I decided to build in an option to toggle/prefer peer-to-peer transmission in the app thinking that if everything goes over a peer-to-peer connection the jitter caused from the channel switching should go away. This also works, but with an important caveat. The default transmission is extremely choppy until you take an OS action that “elevates” the AWDL connection into “realtime” mode. I am using
includePeerToPeeron the listener, browser, and connection as well as serviceClassinteractiveVideo.
For number 1, you can understand that asking users to change the channel on their router is not a great user experience, but the problem is the peer-to-peer connection workaround is also not great by default.
For number 2, as an example of the behavior, I can send a stream from my Mac to my iPad over a peer-to-peer connection and it works but the video is very choppy until I move my cursor from my Mac to my iPad to trigger Universal Control. I captured the OS logs while doing this and can confirm that something happens to trigger “realtime” mode on the AWDL connection. After that, the streaming is totally smooth with zero latency.
Some log samples:
2026-03-19 12:42:01.277968-0400 0x1ae294c Default 0x0 495 3 rapportd: (CoreUtils) [com.apple.rapport:CLinkD] Update client from UniversalControl:697
2026-03-19 12:42:01.278031-0400 0x1ae294c Default 0x0 495 0 rapportd: (CoreUtils) [com.apple.CoreUtils:AsyncCnx] CLinkCnx-6089: Connect start: 'CLink-ed3b9618b4e0._companion-link._tcp.local.%13'
2026-03-19 12:42:01.278149-0400 0x1ae294c Default 0x0 495 0 rapportd: (CoreUtils) [com.apple.CoreUtils:AsyncCnx] CLinkCnx-6089: Querying SRV CLink-ed3b9618b4e0._companion-link._tcp.local.%13
2026-03-19 12:42:01.279454-0400 0x1ae253a Info 0x0 382 0 wifip2pd: [com.apple.awdl:datapathInitiator] Created AWDLDatapathInitiator clink-ed3b9618b4e0._companion-link._tcp.local <To: 2e:f2:5a:15:76:52>
2026-03-19 12:42:01.279498-0400 0x1ae294c Default 0x0 495 0 rapportd: (CoreUtils) [com.apple.CoreUtils:AsyncCnx] CLinkCnx-6089: Resolving DNS f970afcc-1f1c-47af-a3f3-0236c9f9bbb0.local.%13
2026-03-19 12:42:01.279588-0400 0x1ae253a Default 0x0 382 0 wifip2pd: [com.apple.awdl:datapathInitiator] AWDLDatapathInitiator clink-ed3b9618b4e0._companion-link._tcp.local <To: 2e:f2:5a:15:76:52> was started
2026-03-19 12:42:01.282537-0400 0x1ae294c Default 0x0 495 0 rapportd: (Network) [com.apple.network:path] nw_path_evaluator_start [5C54D967-624D-4269-B080-6C7AE63218C7 IPv6#1e905043%awdl0.49154 generic, attribution: developer]
path: satisfied (Path is satisfied), interface: awdl0[802.11], dns, uses wifi
2026-03-19 12:42:01.596450-0400 0x1ae253a Debug 0x0 382 0 wifip2pd: [com.apple.awdl:driver] Received event realtimeMode
2026-03-19 12:42:01.596589-0400 0x1ae253a Default 0x0 382 0 wifip2pd: [com.apple.awdl:interface] Realtime mode updated true
I noticed that on iOS 26 and iPadOS 26 a realtime mode was added specifically to the Wi-Fi Aware API which I assume does what I want: https://developer.apple.com/documentation/wifiaware/waperformancemode/realtime, but I am looking for a solution that works with the existing network API and also on previous OS versions. I have already tried a lot of things, but is there any way to programmatically trigger “realtime” mode?
For additional context, the goal here is to have extremely low latency that also works for gaming. The actual latency introduced in 1 is approximately 30-50ms around once a second… adding a buffer to the stream makes the video completely smooth, but the extra delay on the receiver end is not acceptable for this use case.
Any help or ideas would be appreciated. I can’t easily share a reproduce case right now, and even if I could, getting multiple devices into the exact state along with the router configuration in order to reproduce is going to be pretty difficult anyway.