Have you tried escalating that with the app’s author? Working around their limitations is tricky, and it’s not going to get less tricky over time. I already tried this approach but it didn't work unfortunately. As to how you might work around this, the DNS-SD API (<dns_sd.h>) has a DNSServiceRegisterRecord routine that lets you register arbitrary records. I believe that you’ll be able to use this to register A and AAAA records for your device. Yes it's what I tried 2 days ago but the Domain on iOS never been registered. The API itself returns ok without error. This is the code: DNSServiceErrorType err; char txtMac[255]; TXTRecordRef recordMac; TXTRecordCreate(&recordMac, 255, &txtMac); err = TXTRecordSetValue(&recordMac, "mac-address", mac.toUtf8().length(), mac.toUtf8()); err = TXTRecordSetValue(&recordMac, "serial-number", serialN.toUtf8().length(), serialN.toUtf8()); err = TXTRecordSetValue(&recordMac, "ble-service-uuids", ble_uuids.toUtf8().length(), ble_uuids.toUtf8()); DNSRecordRef recordRef; const char *hostname = "WAHOO KICKR 0000H" DNSServiceErrorType error; DNSServiceRef dnsRef; struct in_addr *addr = atoaddr("192.168.0.46"); error = DNSServiceCreateConnection(&dnsRef); error = DNSServiceRegisterRecord(dnsRef, &recordRef, kDNSServiceFlagsUnique | kDNSServiceFlagsShareConnection, 0, hostname, kDNSServiceType_A, kDNSServiceClass_IN, sizeof(struct in_addr), addr, 240, TXTRegisterCallback, NULL); err = DNSServiceRegister(&ref1, 0, 0, serverName.toUtf8().constData(), "_wahoo-fitness-tnp._tcp", "local", serverName.toUtf8().constData(), htons(serverPort), strlen(txtMac) /* txtLen */, txtMac /* txtRecord */, register_reply_callback, NULL); DNSServiceProcessResult(ref1); I can see everything correct using the Discovery app, for example, but the domain is not registered. Is this API requires some special entitlement or something on iOS? I don’t know if any of this requires the multicasts entitlement. It’s pretty obscure stuff. Yes it's my fear too. Also if I can access to the entitlement, I can directly use the code that was working since iOS 16.1

My advice is that you try it on the Mac, just for testing purposes. macOS does not implement local network privacy, so there’s no potential for that to get in the way. And you can do your initial prototype with the dns-sd tool. Are you sure about this? All this problem started when iOS 16.1 and Ventura released in the same day. So I guess there is the same limitation. The issue is not present in iOS < 16.1 and on MacOS < Ventura.

Thanks @eskimo Apple gave me finally the entitlment so now everything works again as expected! Thanks for your support :)

The previous one, without modifying. Now with the entitlement everything is working again. This sounds to me like a confirmation that something has changed in the 16.1 version

feedback opened https://feedbackassistant.apple.com/feedback/12303532 without help Now i also opened a TSI but I can't understand why i have to open a TSI and spend a TSI "coin" for a beta bug!

I fixed it by myself. In the xcode 15 beta 1 releases notes there is a point about testflight where they said that there is an open bug about the watchapp that have deployment target to less than 6.0 Mine has 5.0 So i put it to 6.0 and now it works (of course it's only a workaround)

also I'm adding (and already reported in the Feedback app) that Apple Vision Pro (Rosetta) is not available in the simulator. Probably this will fix my issue since it's the only device not available for Rosetta.

same issue here. Did you fix it?

Same happening here as well

I sent a support email to apple, I suggest to do the same Let me know how it goes