watchOS 27: third-party NWListener application service advertisement is denied by NECP policy, so DeviceDiscoveryUI pairing from tvOS never completes

On watchOS 27, a third-party watch app that advertises an application service with NWListener (default NWParameters.applicationService, service declared in NSApplicationServices → Advertises) is never advertised: the advertiser path is denied by NECP policy. As a result, when a tvOS app presents DDDevicePickerViewController and the user selects the watch and taps Connect on the watch, sharingd finds no listener (listenerID (null)), the pairing times out after ~30 s, and the tvOS picker's endpoint never returns — neither an endpoint nor an error.

Raw lines: watchOS 26.6 (success, pid 267)
16:00:55.891 AppleWatch[267] -[_NWAdvertiser start] [L1] Starting advertiser
16:00:55.891 AppleWatch[267] -[_NWAdvertiser updateFlows:]_block_invoke [L1] Added listener flow ID 667B9945-…
16:00:55.926 rapportd[48] Found registered listener RPNWListener[…][com.fitonapp.fiton.FitOnWorkout]=0A1149F2-… : ageOut=179s agentClient=0x0 { 'kebike' }
16:00:55.927 rapportd[48] Updated RPNWAgentClient[0x176cc550] (LSTNR): < appSvc=com.fitonapp.fiton.FitOnWorkout PID:267 entitled=0 … browseToken=[pid:267,id:667B9945] … >
16:00:55.930 rapportd[48] [pid:267,id:A20E8919] createListenerFramer calling assign with local endpoint=::.51714
16:01:09.956 rapportd[48] [pid:267,id:F7883D0D] ADVERTISE: Start advertise 'FitOnWorkout' request QUIC=NO isTCP=YES params:[tcp, pid: 267, local: ::.51714, …]
16:01:29.352 rapportd[48] Created incoming RPNWConnection[CONN[5BCD2213-…] (IN): … appSvc=com.fitonapp.fiton.FitOnWorkout … EP={kebike:…}]
16:01:29.399 rapportd[48] [pid:267,id:3346E704] assigning connection ::.51714 <-> app_svc: com.fitonapp.fiton.FitOnWorkout, service_id: D2D4D049-…
16:01:29.404 AppleWatch[267] nw_connection_report_state_with_handler_on_nw_queue [C2] reporting state ready

Raw lines: watchOS 27 (failure, 10-21)
16:00:48.761 AppleWatch[556] -[_NWAdvertiser start] [L1] Starting advertiser with descriptor: FitOnWorkout scope:3f …
16:00:48.761 AppleWatch[556] -[_NWAdvertiser updateFlows:] [L1] Listener skipping advertise flows due to unsatisfied path with policy drop
16:00:48.760 rapportd[98] [pid:556,id:C1D4B82D] createListenerFramer: incorrect agent type ← never upgraded to LSTNR afterwards
…
16:05:37.919 sharingd[458] setupDDUIListenerIfNeeded, incoming pairing session … ← TV's pairing request did arrive
16:05:40.538 sharingd[458] Attempting to launch application com.fitonapp.fiton.watchkitapp
16:05:40.688 rapportd[98] Searching for listener agent client with appSvc='com.fitonapp.fiton.FitOnWorkout'
16:05:40.688 rapportd[98] Created new listener RPNWListener[…][com.fitonapp.fiton.FitOnWorkout]=F625EFB1-… : ageOut=180s agentClient=0x0 { }
← no FitOnWorkout ADVERTISE afterwards; the listener never gets the app's agent client

Answered by DTS Engineer in 913068022

Thanks for filing FB25280603.

Your sample (TicTacToe) fails the same way on watchOS 27.2.

Ouch! That’s not good. Clearly this is our bug to fix.

ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Just so we’re clear, this is an existing watch app that worked on watchOS 26 and now fails on watchOS 27, right?

If so, I recommend that you file a bug about that. Make sure to install the Network Diagnostics debug profile on both devices, and then attach sysdiagnose logs from both devices, taken shortly after reproducing the problem.

Once you’re done, please reply here with your bug number.

Oh, and does the tvOS version matter?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Accepted Answer

Thanks for filing FB25280603.

Your sample (TicTacToe) fails the same way on watchOS 27.2.

Ouch! That’s not good. Clearly this is our bug to fix.

ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks Quinn, much appreciated.

I understand you can’t share release plans, but is there any rough indication of when a fix might land, or anything I should watch for in upcoming watchOS betas?

In the meantime, is there a workaround you’d recommend? This affects shipping users of our app, so anything that lets us avoid the issue until the fix is out would help a lot.

I’ll keep FB25280603 updated if I find anything else.

Written by ilabs in 915297022

is there any rough indication of when a fix might land … ?

No, sorry.

Written by ilabs in 915297022

is there a workaround you’d recommend?

I can’t think of anything.

The sticking point here is watchOS, and specifically it’s limited support for low-level networking. DDUI is one way to get through that barrier, per TN3135 Low-level networking on watchOS [1], and there’s not a lot of wiggle room otherwise.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] I was happy to see that Past Quinn™ has done me a solid by updating TN3135 to specifically call that out (-: