Hi Quinn, Yes, there is a macOS client that just connects locally, and this is the iOS companion. This is really an app im designing for mainly the iPad to be used over ethernet, as the server is a DAW extension app (so like on stage). So I have a manual mode that has always worked fine, but Ive been trying to get a zeroconf working. I've been testing usb as well. I've certainly tried to use the result.endpoint, but it leaves me stuck in a .preparing state. Essentially, the server is a local python server running on 0.0.0.0. and is advertised through a swift daemon running NWListener. My (albeit limited) understanding was that since the nil domain is .local that, as long as the port was being correctly read from txt (which it is), that the endpoint should work. but since it wasn't I tried to resolve the hostname which does work but just with the aforementioned issues.

I think that's accurate. It would mostly be used completely disconnected from wifi on all devices, but shouldn't necessarily need it to be turned off to work. That's why I use this in my code, to ensure the only connections accepted are via wired ethernet: let parameters = NWParameters.tcp parameters.requiredInterfaceType = .wiredEthernet // force Ethernet-only let endpoint = NWEndpoint.hostPort(host: NWEndpoint.Host(ip), port: NWEndpoint.Port(rawValue: UInt16(port))!) let connection = NWConnection(to: endpoint, using: parameters) self.connection = connection of course, when I try to use result.endpoint directly I just pass the NWEndpoint in as the parameter directly but this snippet is taken from my net service implementation. Were it not for my desire for zeroconf, manual connection via linked local would be just fine. But I don't want to lean on internet sharing, which is why I used Bonjour. I hope that gives you enough info regarding my topology?

Hi Quinn. Wifi has been off, peer to peer is disabled in the code in a few places. The issue I was having that in my socket connection .preparing state my code case .preparing: let path = connection.currentPath DebugLogger.shared.append("Preparing with path: \(String(describing: path))") if let endpoint = path?.remoteEndpoint { DebugLogger.shared.append("Target endpoint: \(endpoint)") } if let interfaces = path?.availableInterfaces { var counter = 0 for intf in interfaces { DebugLogger.shared.append("🔌 Interface: \(intf.name), type: \(intf.type)") if case intf.type = .wiredEthernet { counter += 1 } } if counter < 0 { self.connection?.cancel() } } else { self.connection?.cancel() } would produce multiple 'path is satisfied', but no valid wired ethernet interface, and continuously fail until it reached a valid one (en1 on my usb and en5 on my ethernet adapter that goes direct from my MBP to my iPhone). Interestingly I had my data roaming on as im abroad and having that enabled caused a Bridge100 ipV4 to correctly connect, but I cant rely on that being enabled for an end user, and regardless it doesn't make a difference for my ethernet-only connection. I've attached some photos of the debugger essentially cycling until en requirement is satisfied. If I try to enforce wired ethernet requirement at the NWMonitor level it simply stalls in a [.cellular] only state. and once again, using a result.endpoint in this same environment (no data roaming, no wifi, no peer to peer etc) it stalls in a .preparing state.

Just wanted to quickly follow up here. Is the general assessment here just that one should not use Bonjour if they cant host an NWListener in the same application as their server is hosted? I made a dummy NWListener in the typical way to test connecting to a service and as expected it worked perfectly in my ecosystem. The struggle to quickly discover the .wiredEthernet interface is only for my hostPort style NWConnection.

Hi Quinn, I didn't show it exactly but I exactly was passing my resolved hostname as the parameter for that 'ip'. I really just called it ip because I use the same function for my 'manual' connection option. you can see in those debug log screenshots above I think it reflects that its using the hostname in its attempted connection. It totally would work, but I think given that it has a live music application I just wanted it to connect faster. if it got unplugged during a show I wouldn't want it to take so much time reconnecting while it sniffs out the scoped interface. I've since changed my architecture such that the local daemon is itself the server client and the iOS app can connect directly to the daemon as a .service endpoint and it is so much faster so I think im happy with this solution. The one thing that I feel like im missing in this scenario is how I would have been able to do that previous approach without possibly resolving. If your server is written in another language (in an implementation that has no access to zeroconf libraries) and you use this additional daemon as a way to advertise a path to that local server(put intended port number in txtRecord), resolving a hostname seems like the only way to me aside from changing the architecture such as I have. Thank you for your help on this!