My application (using a nested framework for networking) was working correctly on iPadOS 18, but failed to perform a UDP broadcast operation after upgrading the device to iPadOS 28. The low-level console logs consistently show a "Permission denied" error. Symptoms & Error Message: When attempting to send a UDP broadcast packet using NWConnection (or a similar low-level socket call within the framework), the connection fails immediately with the following error logged in the console: nw_socket_service_writes_block_invoke [C2:1] sendmsg(fd 6, 124 bytes) [13: Permission denied] (Error code 13 corresponds to EACCES). Verification Steps (What I have checked): Multicast Networking Entitlement is Approved and Applied: The necessary entitlement (com.apple.developer.networking.multicast) was granted by Apple. The Provisioning Profile used for signing the Host App Target has been regenerated and explicitly includes "Multicast Networking" capability (see attached screenshot). I confirmed that Entitlements cannot be added directly to the Framework Target, only the Host App Target, which is the expected behavior. Local Network Privacy is Configured: The Host App's Info.plist contains the NSLocalNetworkUsageDescription key with a clear usage string. Crucially, the Local Network Access alert does not reliably appear when the Broadcast function is first called (despite a full reinstall after OS upgrade). Even when Local Network Access is manually enabled in Settings, the Broadcast still fails with EACCES. Code Implementation: The Broadcast is attempted using NWConnection to the host 255.255.255.255 on a specific port. Request: Since all required entitlements and profiles are correct, and the failure is a low-level EACCES on a newly updated OS version, I suspect this may be a regression bug in the iPadOS 28 security sandbox when validating the Multicast Networking Entitlement against a low-level socket call (like sendmsg). Has anyone else encountered this specific Permission denied error on iPadOS 28 with a valid Multicast Entitlement, and is there a known workaround aside from switching to mDNS/Bonjour?

My application (using a nested framework for networking) was working correctly on iPadOS 18, but failed to perform a UDP broadcast operation after upgrading the device to iPadOS 26. The low-level console logs consistently show a "Permission denied" error. Symptoms & Error Message: When attempting to send a UDP broadcast packet using NWConnection (or a similar low-level socket call within the framework), the connection fails immediately with the following error logged in the console: nw_socket_service_writes_block_invoke [C2:1] sendmsg(fd 6, 124 bytes) [13: Permission denied] (Error code 13 corresponds to EACCES). Verification Steps (What I have checked): Multicast Networking Entitlement is Approved and Applied: The necessary entitlement (com.apple.developer.networking.multicast) was granted by Apple. The Provisioning Profile used for signing the Host App Target has been regenerated and explicitly includes "Multicast Networking" capability (see attached screenshot). I confirmed that Entitlements cannot be added directly to the Framework Target, only the Host App Target, which is the expected behavior. Local Network Privacy is Configured: The Host App's Info.plist contains the NSLocalNetworkUsageDescription key with a clear usage string. Crucially, the Local Network Access alert does not reliably appear when the Broadcast function is first called (despite a full reinstall after OS upgrade). Even when Local Network Access is manually enabled in Settings, the Broadcast still fails with EACCES. Code Implementation: The Broadcast is attempted using NWConnection to the host 255.255.255.255 on a specific port. Request: Since all required entitlements and profiles are correct, and the failure is a low-level EACCES on a newly updated OS version, I suspect this may be a regression bug in the iPadOS 26 security sandbox when validating the Multicast Networking Entitlement against a low-level socket call (like sendmsg). Has anyone else encountered this specific Permission denied error on iPadOS 26 with a valid Multicast Entitlement, and is there a known workaround aside from switching to mDNS/Bonjour?

Hello, I have a peer to peer networking setup in my app that uses Network Framework with Bonjour and QUIC via NWBrowser, NWListener, NWConnection, and NWEndpoint and all works as expected. I watched the videos about the new iOS 26 Networking stuff (NetworkBrowser, NetworkListener, NetworkConnection) and wanted to try and migrate all my code to use the the new APIs (still use Bonjour and NOT use Wi-Fi Aware) but hit some issues. I was following how the Wi-Fi Aware example app was receiving messages for try await messageData in connection.messages { but when I got things setup with QUIC in a similar fashion I got the following compile error Requirement from conditional conformance of '(content: QUIC.ContentType, metadata: QUIC.Metadata)' to 'Copyable' Requirement from conditional conformance of '(content: QUIC.ContentType, metadata: QUIC.Metadata)' to 'Escapable' Requirement from conditional conformance of '(content: QUIC.ContentType, metadata: QUIC.Metadata)' to 'Copyable' Requirement from conditional conformance of '(content: QUIC.ContentType, metadata: QUIC.Metadata)' to 'Escapable' When I asked Cursor about what I was facing its response was as follows: "The connection.messages stream changed in the new Network APIs: it now yields typed (content, metadata) tuples. Iterating with for try await incoming in connection.messages asks the compiler to conform that tuple to Copyable/Escapable; for QUIC the tuple isn’t copyable, so you hit the conditional-conformance error." I am curious if you've been able to use the new iOS 26 network APIs with QUIC? Thank you, Captadoh

Hello, I have an app that was using the iOS 18 Network Framework APIs. It used Peer to Peer, QUIC and Bonjour. It was all working as expected. I wanted to upgrade to the new iOS 26 Network Framework APIs (NetworkBrowser, NetworkListener, NetworkConnection...). I have things working (multiple devices can discover each other, connection to each other and send messages to each other) but my app crashes when I go to toggle of all the networking stuff. In the iOS 18 Network Framework API NWConnection had a .cancel() function I could use to tell the other side the connection was done. I dont see a cancel function for NetworkConnection. My question is - how do I properly close down a NetworkConnection and also properly tell the other side the connection is done.

Hello, I am studying the Building peer-to-peer apps codebase https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps and am wondering why no connection is ever started? I searched the codebase and didn't find .start() be called once. Start function I'm referencing https://developer.apple.com/documentation/network/networkconnection/start() Are NetworkConnections started automatically? Note that I am using QUIC NetworkConnections (NetworkConnection) in what I'm trying to do.

Hello, I have an app that is using iOS 26 Network Framework APIs. It is using QUIC, TLS 1.3 and Bonjour. For TLS I am using a PKCS#12 identity. All works well and as expected if the devices (iPhone with no cellular, iPhone with cellular, and iPad no cellular) are all on the same wifi network. If I turn off my router (ie no more wifi network) and leave on the wifi toggle on the iOS devices - only the non cellular iPhone and iPad are able to discovery and connect to each other. My iPhone with cellular is not able to. By sharing my logs with Cursor AI it was determined that the connection between the two problematic peers (iPad with no cellular and iPhone with cellular) never even makes it to the TLS step because I never see the logs where I print out the certs I compare. I tried doing "builder.requiredInterfaceType(.wifi)" but doing that blocked the two non cellular devices from working. I also tried "builder.prohibitedInterfaceTypes([.cellular])" but that also did not work. Is AWDL on it's way out? Should I focus my energy on Wi-Fi Aware? Regards, Captadoh

Hi team, I’m having an issue with my iOS app related to local network communication and connecting to a Wi-Fi speaker. My app works similar to the “4Stream” application. The speaker and the mobile device must be on the same Wi-Fi network so the app can discover and connect to the speaker. What’s happening: When I run the app directly from Xcode in debug mode, everything works perfectly. The speaker gets discovered. The speaker gets connected successfully. The connection flow completes without any problem. But when I upload the same build to TestFlight, the behaviour changes completely. The app gets stuck on the “Connecting…” screen. The speaker is not discovered. But the same code is working fine on Android It never moves forward from that state. So basically: Debug Mode: Speaker is detected and connected properly TestFlight: Stuck at “Connecting…”, speaker does NOT get connected This makes me believe something related to local network access, multicast, Wi-Fi info permissions, or Bonjour discovery is not being applied correctly in the release/TestFlight environment. Below is my current Info.plist and Entitlements file, which already include Local Network Usage, Bonjour services, Location usage for SSID, multicast entitlements, wifi-info, etc. My Info.plist <key>CADisableMinimumFrameDurationOnPhone</key> <true/> <key>CFBundleDevelopmentRegion</key> <string>en</string> <key>CFBundleDisplayName</key> <string>Wanwun</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleShortVersionString</key> <string>$(MARKETING_VERSION)</string> <key>CFBundleSignature</key> <string>????</string> <key>CFBundleVersion</key> <string>$(CURRENT_PROJECT_VERSION)</string> <key>LSRequiresIPhoneOS</key> <true/> <!-- Allow HTTP to devices on LAN --> <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> <key>NSExceptionDomains</key> <dict> <key>local</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <key>NSIncludesSubdomains</key> <true/> </dict> <key>localhost</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <key>NSIncludesSubdomains</key> <true/> </dict> </dict> </dict> <!-- Local Network Usage --> <key>NSLocalNetworkUsageDescription</key> <string>This app needs local network access to discover and control your sound system device over Wi-Fi.</string> <!-- Bonjour services for discovery --> <key>NSBonjourServices</key> <array> <string>_http._tcp.</string> <string>_wrtn._tcp.</string> <string>_services._dns-sd._udp.</string> </array> <!-- Location for SSID Permission --> <key>NSLocationWhenInUseUsageDescription</key> <string>This app requires location access to read the connected Wi-Fi information.</string> <!-- Camera / Photos --> <key>NSCameraUsageDescription</key> <string>This app needs camera access to capture attendance photos.</string> <key>NSPhotoLibraryAddUsageDescription</key> <string>This app saves captured photos to your gallery.</string> <key>NSPhotoLibraryUsageDescription</key> <string>This app needs access to your gallery to upload existing images.</string> <!-- Bluetooth --> <key>NSBluetoothAlwaysUsageDescription</key> <string>This app uses Bluetooth to discover nearby sound system devices.</string> <key>NSBluetoothPeripheralUsageDescription</key> <string>This app uses Bluetooth to connect with your sound system.</string> <!-- Launch screen --> <key>UILaunchStoryboardName</key> <string>LaunchScreen</string> <!-- Device Capabilities --> <key>UIRequiredDeviceCapabilities</key> <array> <string>arm64</string> </array> <!-- Orientation --> <key>UISupportedInterfaceOrientations</key> <array> <string>UIInterfaceOrientationPortrait</string> <string>UIInterfaceOrientationLandscapeLeft</string> <string>UIInterfaceOrientationLandscapeRight</string> </array> <key>UIViewControllerBasedStatusBarAppearance</key> <false/> My Entitlements What I need help with: I want to understand why the app behaves correctly in debug mode (where the speaker connects without issues), but the same functionality fails in TestFlight. Is there something additional required for: Local network discovery on TestFlight? Multicast networking? Reading the Wi-Fi SSID? Bonjour, service scanning? Release build / TestFlight network permissions? If any extra entitlement approval, configuration, or specific service type is needed for TestFlight builds, please guide me. Thank you for your help.

Hello, I’m reviewing the open-source mDNSResponder repository and have a question regarding licensing/provenance in mDNSCore/DNSDigest.c file. That file contains an embedded notice stating that parts of the MD5/digest implementation were derived from older OpenSSL sources and therefore include the legacy OpenSSL/SSLeay license text, even though OpenSSL itself is now Apache-2.0 starting from version 3.0. The legacy OpenSSL/SSLeay license is widely understood to impose additional attribution and notice requirements compared to Apache-2.0, and some downstream projects prefer to avoid it when a permissively licensed alternative is available. Repository: https://github.com/apple-oss-distributions/mDNSResponder File: https://github.com/apple-oss-distributions/mDNSResponder/blob/main/mDNSCore/DNSDigest.c#L66 I’d like to clarify a few points: Is the MD5/digest code in DNSDigest.c still based on pre–OpenSSL-3.0 sources, such that retaining the legacy OpenSSL/SSLeay license block is intentional and required? If the goal were to simplify licensing (Apache-2.0 only), would Apple consider replacing this MD5 implementation with an Apache-2.0–licensed alternative (for example, code derived from OpenSSL 3.x or another permissive implementation)? Are there any technical or policy reasons (compatibility, crypto policy, platform APIs) that make such a replacement undesirable? Since GitHub issues and PRs are restricted for this repository, I’m asking here for guidance. If maintainers agree that such an update would be useful, I’d be happy to help by preparing a PR for review. I've also created a feedback report for this topic, the reference ID is FB21269078. Thanks for any clarification.

I've been working through some issues here attempting to migrate away from the MultiPeer Connectivity following the guidance in here, Moving from Multipeer Connectivity to Network Framework, and implementing a home-grown solution using NWBrowser and NWListener and NWConnections. I feel like I am 95% of the way there, but am experiencing an issue where my connection attempts seem to fail about 50% of the time. If I have two nodes say, one a physical iPad, and one a simulator on my Mac. I can start them both up, and they are both discovered with Bounjour no problem. Sometimes the "connect" no problem. Othertimes however when I attempt to "connect" from one device to the other, I get failures. I'd say it's about 50/50 success - fail at this point. The "dialing" device state enters "preparing" but never progesses past that, and on the "receiving end" I see receive error: POSIXErrorCode(rawValue: 61): Connection refused I'm at my wits end here with this, everything else in my migration I think is done...just need some insights maybe on potential causes for that error...

TL;DR: How does one use DNSServiceReconfirmRecord() to invalidate mDNS state of a device that's gone offline? I'm using the DNSServiceDiscovery API (dns_sd.h) for a local P2P service. The problem I'm trying to solve is how to deal with a peer that abruptly loses connectivity, i.e. by turning off WiFi or simply by moving out of range or otherwise losing connectivity. In this situation there is of course no notification that the peer device has gone offline; it simply stops sending any packets. After my own timeout mechanism determines the peer is not responding, I mark it as offline in my own data structures. The problem is how to discover when/if it comes back online later. My DNSServiceBrowse callback won't be invoked because mDNS doesn't know the device went offline in the first place. I am trying to use DNSServiceReconfirmRecord, which appears to be for exactly this use case -- "Instruct the daemon to verify the validity of a resource record that appears to be out of date (e.g. because TCP connection to a service's target failed.)" However my attempts always return a BadReference error (-65541). The function requires me to pass a DNS record, and the only one I know is the TXT record; perhaps it needs a different one? Which, and how would I get it? Thanks!

Hello and Good day! We are conducting Bonjour Conformance Test (BCT) for Printer device. BCT result is PASSED but with warning in Multicast DNS, specifically, WARNING: SHARED REPLY TIMING - UNIFORM RANDOM REPLY TIME DISTRIBUTION Other Shared Reply Timing is passed: PASSED: MULTIPLE QUESTIONS - SHARED REPLY TIMING - UNIFORM RANDOM REPLY TIME DISTRIBUTION Environment: BCT Tool Version: 1.5.4 (15400) MacOS Sequioa 15.5 DUT Firmware : Linux Debian 9 Apple mDNSResponder 1790.80.10 Service types: _ipps._tcp, _uscans._tcp, _ipp._tcp, _uscan._tcp Router : NEC AtermWR8370N Setup: 1-to-1 [Mac->Router<-DUT connection] Based on debug.log, this is where WARNING occurs: NOTICE 2026-03-04 10:51:06.870187+0900 _shared_reply_timing 04103: Shared reply response times: min = 26ms, max = 114ms, avg = 65.50ms WARNING 2026-03-04 10:51:06.870361+0900 _shared_reply_timing 04136: 50 percent of the replies within the correct range fell in the interval 20ms and 46ms (should be close to 25%). PASSED (SHARED REPLY TIMING) In the same debug.log for MULTIPLE QUESTIONS - SHARED REPLY TIMING is PASSED: NOTICE 2026-03-04 10:52:29.912334+0900 _shared_reply_timing 04103: Shared reply response times: min = 22ms, max = 112ms, avg = 78.00ms DEBUG_2 2026-03-04 10:52:29.912849+0900 recv_packet 01997: received packet (558 bytes) PASSED (MULTIPLE QUESTIONS - SHARED REPLY TIMING) [Details] Looking at Bonjour_Conformance_Guideline.pdf https://download.developer.apple.com/Documentation/Bonjour_Conformance_Test_Guideline/Bonjour_Conformance_Guideline.pdf there were some differences: In 1.6.2 Expected Result: Test Result File of Test that All Tests Passed, this is not displayed: PASSED: SHARED REPLY TIMING - UNIFORM RANDOM REPLY TIME DISTRIBUTION And in II.8 Shared Reply Timing: (Ideally, 25% of the answers should fall in each 21ms quadrant of the range 20ms - 125ms.) and comparing to the debug.log, there was a discrepancy of the interval, because 20ms and 46ms is 26ms interval. From RFC6762 6. Responding, Ideal range is from 20ms-120ms Because of this, please advise on the questions below: I would like to know on the possible cause and resolution for these WARNINGS. And since in current BCT result, (Test result integrity signature is generated), I would like to know if this is acceptable for BCT certification. Thank you.

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 includePeerToPeer on the listener, browser, and connection as well as serviceClass interactiveVideo. 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.

Hello, I am experiencing a specific authorization error on macOS Tahoe when trying to discover all available service types on the local network. While the implementation works perfectly on iOS and macOS Sonoma, it fails on Tahoe with a specific error code. The Issue When calling DNSServiceBrowse with the meta-query string _services._dns-sd._udp, the function immediately returns kDNSServiceErr_NoAuth (-65555). // This call fails on macOS Tahoe DNSServiceErrorType err = DNSServiceBrowse( &ref, 0, kDNSServiceInterfaceIndexAny, "_services._dns-sd._udp", // Meta-query for all services domc, probe_browse_reply, (__bridge void *)self ); Important Findings & Observations Specific Services Work: If I change the service type to a specific one (e.g., _http._tcp or _ssh._tcp) using NWBrowser, it works correctly and returns results. The error only occurs when browsing for _services._dns-sd._udp using DNSServiceBrowse. Local Network Permission: I have confirmed that the Local Network toggle is ON for my app in System Settings > Privacy & Security > Local Network. Entitlements: My app has the com.apple.developer.networking.multicast entitlement. Info.plist: Both NSLocalNetworkUsageDescription and NSBonjourServices (including _services._dns-sd._udp) are properly configured. Sandbox: The issue persists regardless of whether the App Sandbox is enabled (with incoming/outgoing connections) or disabled. Environment Not Working OS: macOS Tahoe 26 Working OS: macOS Sonoma, iOS 26 Question It seems macOS Tahoe has introduced a stricter policy regarding Network Reconnaissance or meta-service browsing. Is there a new requirement or a specific entitlement needed in macOS Tahoe to browse for _services._dns-sd._udp? Any guidance on how to restore this functionality for network utility apps on macOS Tahoe would be greatly appreciated. Best regards.

Hi everyone, We are working on an app that requires access to devices on the local network (Bonjour / LAN discovery + direct socket communication). We are currently struggling with the Local Network privacy permission flow introduced by Apple. From our understanding, there is no dedicated public API to explicitly request Local Network permission or to reliably determine the current authorization state before attempting network activity. We have tried several commonly suggested approaches to trigger the permission dialog, including: Bonjour browsing via NWBrowser Publishing/listening with NetService UDP/TCP socket attempts on local subnet NWConnection / NWListener Triggering discovery after app launch and after foreground transitions We already added the required entries in: NSLocalNetworkUsageDescription NSBonjourServices However, the behavior is inconsistent across devices and OS versions: Sometimes the popup appears immediately Sometimes it never appears Sometimes network operations silently fail without callback clarity In some cases callbacks are delayed or ambiguous Reinstalling/resetting permissions changes behavior unpredictably Our main challenges are: What is currently considered the most reliable Apple-approved method to trigger the Local Network permission prompt? Is there any officially recommended way to determine whether permission is: not determined denied granted Is there any reliable callback or state transition API developers should use? Are there known differences between: NWBrowser NetService BSD sockets NWConnection when it comes to triggering the permission dialog? Are there recommended retry/timing patterns to avoid race conditions during app launch? Is Apple planning to introduce a dedicated authorization API similar to: AVAuthorizationStatus CLAuthorizationStatus PHPhotoLibrary.authorizationStatus() Right now it feels difficult to provide a reliable UX because there is no deterministic way to: proactively request access observe authorization state recover gracefully when the prompt does not appear Any guidance, DTS references, WWDC sessions, or recommended implementation patterns would be greatly appreciated. Thanks!

Is there any current documentation of Wide-Area Bonjour support in macOS? While the system-level defaults still seem to be the same, in the past there were bugs in the various HMAC and other authentication mechanisms for dynamic updates. Is there a source for current documentation?