I was excited about the new APIs added to Network.framework in iOS 26 that offer structure concurrency support out of the box and a more modern API design in general. However I have been unable to use them to create a device-to-device QUIC connection. The blocker I ran into is that NetworkListener's run method requires the network protocol to conform to OneToOneProtocol, whereas QUIC conforms to MultiplexProtocol. And there doesn't seem to be any way to accept an incoming MultiplexProtocol connection? Nor does it seem possible to turn a UDP connection into a QUIC connection using NetworkConnection.prependProtocols() as that also only works for network protocols conforming to OneToOneProtocol. I suspect this is an accidental omission in the API design (?), and already filed a Feedback (FB18620438). But maybe I am missing something and there is a workaround or a different way to listen for incoming QUIC connections using the new NetworkListener? QUIC.TLS has methods peerAuthenticationRequired(Bool) and peerAuthenticationOptional(Bool), which makes me think that peer to peer QUIC connections are intended to be supported? I would also love to see documentation for those methods. For example I wonder what exact effect peerAuthenticationRequired(false) and peerAuthenticationOptional(false) would have and how they differ.

My laptop (M1 Pro, macOS 15.3.2) is connected to a dual stack network via Wi-Fi. The home.arpa. domain is supplied as a search domain via both DHCPv4 (options 15 and 119) and DHCPv6 (option 24). "Details…" for the network connection in System Settings show this domain under the DNS tab. The laptop uses a Forwarding DNS Resolver of my router, which in turn forwards requests for home.arpa. (including subdomains) to a local DNS server (CoreDNS) which is authoritative for this zone. The DNS server is configured via the following zone file: $ORIGIN home.arpa. $TTL 3600 @ IN SOA @ nobody.invalid. (1 3600 1200 604800 3600) @ NS @ @ AAAA ….1 gateway A ….1 gateway AAAA …::1 b._dns-sd._udp PTR @ lb._dns-sd._udp PTR @ db._dns-sd._udp PTR @ _services._dns-sd._udp PTR _smb._tcp _smb._tcp PTR Media._smb._tcp Media._smb._tcp SRV 0 0 445 gateway Media._smb._tcp TXT ("path=/media" "u=guest") Output of dig(1) looks like: $ dig @….1 -t PTR lb._dns-sd._udp.home.arpa. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43291 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;lb._dns-sd._udp.home.arpa. IN PTR ;; ANSWER SECTION: lb._dns-sd._udp.home.arpa. 1993 IN PTR home.arpa. ;; AUTHORITY SECTION: home.arpa. 2771 IN NS home.arpa. $ dig @….1 -t PTR _services._dns-sd._udp.home.arpa. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9057 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;_services._dns-sd._udp.home.arpa. IN PTR ;; ANSWER SECTION: _services._dns-sd._udp.home.arpa. 3600 IN PTR _smb._tcp.home.arpa. ;; AUTHORITY SECTION: home.arpa. 3600 IN NS home.arpa. $ dig @….1 -t PTR _smb._tcp.home.arpa. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44220 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;_smb._tcp.home.arpa. IN PTR ;; ANSWER SECTION: _smb._tcp.home.arpa. 3599 IN PTR Media._smb._tcp.home.arpa. ;; AUTHORITY SECTION: home.arpa. 3599 IN NS home.arpa. $ dig @….1 -t SRV Media._smb._tcp.home.arpa. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45878 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;Media._smb._tcp.home.arpa. IN SRV ;; ANSWER SECTION: media._smb._tcp.home.arpa. 3600 IN SRV 0 0 445 gateway.home.arpa. ;; AUTHORITY SECTION: home.arpa. 3600 IN NS home.arpa. $ dig @….1 -t A gateway.home.arpa. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2782 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;gateway.home.arpa. IN A ;; ANSWER SECTION: gateway.home.arpa. 86400 IN A 192.168.99.1 ;; AUTHORITY SECTION: home.arpa. 3578 IN NS home.arpa. $ dig @….1 -t AAAA gateway.home.arpa. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17297 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;gateway.home.arpa. IN AAAA ;; ANSWER SECTION: gateway.home.arpa. 3600 IN AAAA fd6f:9784:5753::1 ;; AUTHORITY SECTION: home.arpa. 3600 IN NS home.arpa. Output of dns-sd(1): /usr/bin/dns-sd -test … Testing for error returns when various strings are > 63 bytes: PASSED Running basic API input range tests with various pointer parameters set to NULL: Basic API input range tests: PASSED $ dns-sd -m -F Looking for recommended browsing domains: DATE: ---Fri 11 Apr 2025--- 8:50:17.846 ...STARTING... Timestamp Recommended Browsing domain 8:50:17.847 Added (More) local 8:50:17.847 Added arpa - > home $ dns-sd -B _smb._tcp home.arpa. Browsing for _smb._tcp.home.arpa. DATE: ---Fri 11 Apr 2025--- 8:59:10.044 ...STARTING... $ dns-sd -L Media _smb._tcp home.arpa. Lookup Media._smb._tcp.home.arpa. DATE: ---Fri 11 Apr 2025--- 9:15:53.328 ...STARTING... $ dns-sd -Q _smb._tcp.home.arpa. PTR IN DATE: ---Fri 11 Apr 2025--- 9:16:52.208 ...STARTING... Timestamp A/R Flags IF Name Type Class Rdata 9:16:52.210 Add 40000002 0 _smb._tcp.home.arpa. PTR IN 0.0.0.0 No Such Record 9:16:52.222 Add 2 0 _smb._tcp.home.arpa. PTR IN 0.0.0.0 No Such Record Similarly, when I open Finder->Network I see home.arpa but it's empty. Of interest is that on the DNS server side I see the following requests being made: 2025-04-11 09:03:15 container,info,debug [INFO] […]:56541 - 21555 "SOA IN _afpovertcp._tcp.home.arpa. udp 44 false 512" NXDOMAIN qr,aa,rd 112 0.000755089s 2025-04-11 09:03:15 container,info,debug [INFO] […]:56077 - 58266 "SOA IN _smb._tcp.home.arpa. udp 37 false 512" NOERROR qr,aa,rd 105 0.001012632s 2025-04-11 09:03:15 container,info,debug [INFO] […]:45274 - 45976 "SOA IN _rfb._tcp.home.arpa. udp 37 false 512" NXDOMAIN qr,aa,rd 105 0.000762339s 2025-04-11 09:03:15 container,info,debug [INFO] […]:54387 - 32090 "SOA IN _adisk._tcp.home.arpa. udp 39 false 512" NXDOMAIN qr,aa,rd 107 0.001058132s 2025-04-11 09:03:15 container,info,debug [INFO] […]:35855 - 51155 "SOA IN _tcp.home.arpa. udp 32 false 512" NOERROR qr,aa,rd 100 0.000664963s I suppose that an attempt to locate services is made but it's unsuccessful and I'm not sure why. What further debugging can I attempt?

We use as content filter in our app to monitor flows, we gather data about the flow and block flows deemed suspicious. Our content filter is activated/deactivated by a UI app but the flows are reported via XPC to a separate daemon process for analysis. As of macOS 15, we are seeing cases where flows are missing or flows are not received at all by the content filter. The behaviour is not consistent, some devices seem to receive flows normally but others don't. It appears Intel devices are much less prone to showing the problem, whereas Arm devices routinely exhibit missing flows. On macOS 14 or earlier, there is no sign of missing flows. Testing on earlier beta versions of macOS 15 did not appear to show the problem, however I can't rule out if issue was present but it wasn't spotted. Experimenting with simple examples of using a content filter (e.g. QNE2FilterMac) does not appear to reproduce the issue. Questions, What has changed between macOS 14 and 15 that could be the cause of the lack of flows? Is our approach to using an app activated content filter reporting to a daemon connected via XPC unsupported?

There is no available API that allows you to connect to Android. The current APIs that are provided are not compatible outside of the Apple Ecosystem. For example, Android requires you to set a service name and a password where iOS sets a service and a PIN authentication strategy in a specific format that’s not compatible. It looks like the implementation is not following the Wifi Aware Specifications. To enable cross platform interoperability while providing security, could you adopt the same strategy as with Bluetooth and enable iOS users to enable the sharing and subscription of services with Everyone.

Hi, My app uses the NetworkExtension framework to connect to an access point. For some reason, my app occasionally fails to find and/or connect to my AP (which I know is online and beaconing on a given frequency). This roughly happens 1/10 times. I am using an iPhone 17, running iOS 26.0.1. I am connecting to a WPA2-Personal network. In the iPhone system logs, I see the following: Oct 10 10:34:10 wifid(WiFiPolicy)[54] <Notice>: Dequeuing command type: "Scan" pending commands: 0 Oct 10 10:34:10 wifid(WiFiPolicy)[54] <Notice>: __WiFiDeviceCopyPreparedScanResults: network records count: 0 Oct 10 10:34:10 kernel()[0] <Notice>: wlan0:com.apple.p2p: WiFi infra associated, NAN DISABLED, , DFS state Off, IR INACTIVE, llwLink ACTIVE, RTM-DP 0, allowing scans Oct 10 10:34:10 kernel()[0] <Notice>: wlan0:com.apple.p2p: isScanDisallowedByAwdl[1148] : InfraScanAllowed 1 (RTModeScan 0 NonSteering 0 assistDisc 0 HTMode 0 RTModeNeeded 0 Immin 0 ScanType 1 Flags 0 ScanOn2GOnly 0 DevAllows2G 1) Oct 10 10:34:10 kernel()[0] <Notice>: wlan0:com.apple.p2p: IO80211PeerManager::setScanningState:5756:_scanningState:0x2(oldState 0) on:1, source:ScanManagerFamily, err:0 Oct 10 10:34:10 kernel()[0] <Notice>: wlan0:com.apple.p2p: setScanningState:: Scan request from ScanManagerFamily. Time since last scan(1.732 s) Number of channels(0), 2.4 only(no), isDFSScan 0, airplaying 0, scanningState 0x2 Oct 10 10:34:10 kernel()[0] <Notice>: wlan0:com.apple.p2p: IO80211PeerManager::setScanningState:5756:_scanningState:0x2(oldState 0) on:1, source:ScanManagerFamily, err:0 Oct 10 10:34:10 kernel()[0] <Notice>: wlan0:com.apple.p2p: Controller Scan Started, scan state 0 -> 2 Oct 10 10:34:10 kernel()[0] <Notice>: wlan0:com.apple.p2p: IO80211PeerManager::setScanningState:5756:_scanningState:0x0(oldState 2) on:0, source:ScanError, err:3766617154 Oct 10 10:34:10 kernel()[0] <Notice>: wlan0:com.apple.p2p: setScanningState[23946]:: Scan complete for source(8)ScanError. Time(0.000 s), airplaying 0, scanningState 0x0 oldState 0x2 rtModeActive 0 (ProxSetup 0 curSchedState 3) Oct 10 10:34:10 kernel()[0] <Notice>: wlan0:com.apple.p2p: IO80211PeerManager::setScanningState:5756:_scanningState:0x0(oldState 2) on:0, source:ScanError, err:3766617154 Oct 10 10:34:10 kernel()[0] <Notice>: wlan0:com.apple.p2p: Controller Scan Done, scan state 2 -> 0 Oct 10 10:34:10 wifid(IO80211)[54] <Notice>: Apple80211IOCTLSetWrapper:6536 @[35563.366221] ifname['en0'] IOUC type 10/'APPLE80211_IOC_SCAN_REQ', len[5528] return -528350142/0xe0820442 Oct 10 10:34:10 wifid[54] <Notice>: [WiFiPolicy] {SCAN-} Completed Apple80211ScanAsync on en0 (0xe0820442) with 0 networks Oct 10 10:34:10 wifid(WiFiPolicy)[54] <Error>: __WiFiDeviceCreateFilteredScanResults: null scanResults Oct 10 10:34:10 wifid(WiFiPolicy)[54] <Notice>: __WiFiDeviceCreateFilteredScanResults: rssiThresh 0, doTrimming 0, scanResultsCount: 0, trimmedScanResultsCount: 0, filteredScanResultsCount: 0, nullNetworksCount: 0 Oct 10 10:34:10 wifid(WiFiPolicy)[54] <Notice>: __WiFiDeviceManagerDispatchUserForcedAssociationCallback: result 1 Oct 10 10:34:10 wifid(WiFiPolicy)[54] <Error>: __WiFiDeviceManagerForcedAssociationCallback: failed to association error 1 Oct 10 10:34:10 wifid(WiFiPolicy)[54] <Notice>: WiFiLocalizationGetLocalizedString: lang='en_GB' key='WIFI_JOIN_NETWORK_FAILURE_TITLE' value='Unable to join the network \M-b\M^@\M^\%@\M-b\M^@\M^]' Oct 10 10:34:10 wifid(WiFiPolicy)[54] <Notice>: WiFiLocalizationGetLocalizedString: lang='en_GB' key='WIFI_FAILURE_OK' value='OK' Oct 10 10:34:10 wifid(WiFiPolicy)[54] <Notice>: __WiFiDeviceManagerUserForcedAssociationScanCallback: scan results were empty It looks like there is a scan error, and I see the error: failed to association error 1. I have also seen the iOS device find the SSID but fail to associate (associated error 2): Oct 8 12:25:52 wifid(WiFiPolicy)[54] <Notice>: __WiFiMetricsManagerCopyLinkChangeNetworkParams: updating AccessPointInfo: { DeviceNameElement = testssid; ManufacturerElement = " "; ModelName = " "; ModelNumber = " "; } Oct 8 12:25:52 wifid(WiFiPolicy)[54] <Notice>: __WiFiMetricsManagerCopyLinkChangeNetworkParams: minSupportDataRate 6, maxSupportDataRate 54 Oct 8 12:25:52 wifid(WiFiPolicy)[54] <Error>: Disassociated. Oct 8 12:25:52 wifid(WiFiPolicy)[54] <Error>: __WiFiMetricsManagerUpdateDBAndSubmitAssociationFailure: Failed to append deauthSourceOUI to CA event Oct 8 12:25:52 wifid(WiFiPolicy)[54] <Error>: __WiFiMetricsManagerUpdateDBAndSubmitAssociationFailure: Failed to append bssidOUI to CA event ..... <log omitted> ..... <log omitted> Oct 8 12:25:52 wifid(CoreWiFi)[54] <Notice>: [corewifi] END REQ [GET SSID] took 0.005530542s (pid=260 proc=mediaplaybackd bundleID=com.apple.mediaplaybackd codesignID=com.apple.mediaplaybackd service=com.apple.private.corewifi-xpc qos=21 intf=(null) uuid=D67EF err=-528342013 reply=(null) Oct 8 12:25:52 SpringBoard(SpringBoard)[244] <Notice>: Presenting a CFUserNotification with reply port: 259427 on behalf of: wifid.54 Oct 8 12:25:52 SpringBoard(SpringBoard)[244] <Notice>: Received request to activate alertItem: <SBUserNotificationAlert: 0xc20a49b80; title: Unable to join the network \M-b\M^@\M^\\134^Htestssid\134^?\M-b\M^@\M^]; source: wifid; pid: 54> Oct 8 12:25:52 wifid(WiFiPolicy)[54] <Notice>: __WiFiDeviceManagerUserForcedAssociationCallback: failed forced association Oct 8 12:25:52 SpringBoard(SpringBoard)[244] <Notice>: Activation - Presenting <SBUserNotificationAlert: 0xc20a49b80; title: Unable to join the network \M-b\M^@\M^\\134^Htestssid\134^?\M-b\M^@\M^]; source: wifid; pid: 54> with presenter: <SBUnlockedAlertItemPresenter: 0xc1d9f6530> Oct 8 12:25:52 wifid(WiFiPolicy)[54] <Notice>: __WiFiDeviceManagerDispatchUserForcedAssociationCallback: result 2 Oct 8 12:25:52 SpringBoard(SpringBoard)[244] <Notice>: Activation - Presenter:<SBUnlockedAlertItemPresenter: 0xc1d9f6530> will present presentation: <SBAlertItemPresentation: 0xc1cd40820; alertItem: <SBUserNotificationAlert: 0xc20a49b80; presented: NO>; presenter: <SBUnlockedAlertItemPresenter: 0xc1d9f6530>> Oct 8 12:25:52 wifid(WiFiPolicy)[54] <Error>: __WiFiDeviceManagerForcedAssociationCallback: failed to association error 2 Anyone able to help with this?

I have an app that has been using the following code to down load audio files: if let url = URL(string: episode.fetchPath()) { var request = URLRequest(url: url) request.httpMethod = "get" let task = session.downloadTask(with: request) And then the following completionHandler code: func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didFinishDownloadingTo location: URL) { try FileManager.default.moveItem(at: location, to: localUrl) In the spirit of modernization, I'm trying to update this code to use async await: var request = URLRequest(url: url) request.httpMethod = "get" let (data, response) = try await URLSession.shared.data(for: request) try data.write(to: localUrl, options: [.atomicWrite, .completeFileProtection]) Both these code paths use the same url value. Both return the same Data blobs (they return the same hash value) Unfortunately the second code path (using await) introduces a problem. When the audio is playing and the iPhone goes to sleep, after 15 seconds, the audio stops. This problem does not occur when running the first code (using the didFinish completion handler) Same data, stored in the same URL, but using different URLSession calls. I would like to use async/await and not have to experience the audio ending after just 15 seconds of the device screen being asleep. any guidance greatly appreciated.

When installing a new version the app while a tunnel is connected, seemingly the old packet tunnel process gets stopped but the new one does not come back up. Reportedly, a path monitor is reporting that the device has no connectivity. Is this the expected behavior? When installing an update from TestFlight or the App store, the packet tunnel instance from the old tunnel is stopped, but, due to the profile being on-demand and incldueAllNetworks, the path monitoring believes the device has no connectivity - so the new app is never downloaded. Is this the expected behavior? During development, the old packet tunnel gets stopped, the new app is installed, but the new packet tunnel is never started. To start it, the user has to toggle the VPN twice from the Settings app. The tunnel could be started from the VPN app too, if we chose to not take the path monitor into account, but then the user still needs to attempt to start the tunnel twice - it only works on the second try. As far as we can tell, the first time around, the packet tunnel never gets started, the app receives an update about NEVPNStatus being set to disconnecting yet NEVPNConnection does not throw. The behavior I was naively expecting was that the packet tunnel process would be stopped only when the new app is fully downloaded and when the update is installed, Are we doing something horribly wrong here?

We are developing an iOS application that is interacting with HTTP APIs that requires us to put a unique UUID (a nonce) as an header on every request (obviously there's more than that, but that's irrilevant to the question here). If the same nonce is sent on two subsequent requests the server returns a 412 error. We should avoid generating this kind of errors as, if repeated, they may be flagged as a malicious activity by the HTTP APIs. We are using URLSession.shared.dataTaskPublisher(for: request) to call the HTTP APIs with request being generated with the unique nonce as an header. On our field tests we are seeing a few cases of the same HTTP request (same nonce) being repeated a few seconds on after the other. Our code has some retry logic only on 401 errors, but that involves a token refresh, and this is not what we are seeing from logs. We were able to replicate this behaviour on our own device using Network Link Conditioner with very bad performance, with XCode's Network inspector attached we can be certain that two HTTP requests with identical headers are actually made automatically, the first request has an "End Reason" of "Retry", the second is "Success" with Status 412. Our questions are: can we disable this behaviour? can we provide a new request for the retry (so that we can update headers)? Thanks, Francesco

I'm implementing a NEDNSProxyProvider on macOS 15.x and macOS 26.x. The flow works correctly up to the last step — returning the DNS response to the client via writeDatagrams. Environment: macOS 15.x, 26.x Xcode 26.x NEDNSProxyProvider with NEAppProxyUDPFlow What I'm doing: override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool { guard let udpFlow = flow as? NEAppProxyUDPFlow else { return false } udpFlow.readDatagrams { datagrams, endpoints, error in // 1. Read DNS request from client // 2. Forward to upstream DNS server via TCP // 3. Receive response from upstream // 4. Try to return response to client: udpFlow.writeDatagrams([responseData], sentBy: [endpoints.first!]) { error in // Always fails: "The datagram was too large" // responseData is 50-200 bytes — well within UDP limits } } return true } Investigation: I added logging to check the type of endpoints.first : // On macOS 15.0 and 26.3.1: // type(of: endpoints.first) → NWAddressEndpoint // Not NWHostEndpoint as expected On both macOS 15.4 and 26.3.1, readDatagrams returns [NWEndpoint] where each endpoint appears to be NWAddressEndpoint — a type that is not publicly documented. When I try to create NWHostEndpoint manually from hostname and port, and pass it to writeDatagrams, the error "The datagram was too large" still occurs in some cases. Questions: What is the correct endpoint type to pass to writeDatagrams on macOS 15.x, 26.x? Should we pass the exact same NWEndpoint objects returned by readDatagrams, or create new ones? NWEndpoint, NWHostEndpoint, and writeDatagrams are all deprecated in macOS 15. Is there a replacement API for NEAppProxyUDPFlow that works with nw_endpoint_t from the Network framework? Is the error "The datagram was too large" actually about the endpoint type rather than the data size? Any guidance would be appreciated. :-))

I want to configure one aspect of my networking configuration (the QUIC keepalive interval). This only seems to be configurable via Network.framework’s nw_quic_set_keepalive_interval. Is there any way to apply this to a URLSession? Or do I need to implement the whole connection management myself using Network.framework?

Our product (rockhawk.ca) uses the Multipeer Connectivity framework for peer-to-peer communication between multiple iOS/iPadOS devices. My understanding is that MC framework communicates via three methods: 1) infrastructure wifi (i.e. multiple iOS/iPadOS devices are connected to the same wifi network), 2) peer-to-peer wifi, or 3) Bluetooth. In my experience, I don't believe I've seen MC use Bluetooth. With wifi turned off on the devices, and Bluetooth turned on, no connection is established. With wifi on and Bluetooth off, MC works and I presume either infrastructure wifi (if available) or peer-to-peer wifi are used. I'm trying to overcome two issues: Over time (since iOS 9.x), the radio transmit strength for MC over peer-to-peer wifi has decreased to the point that range is unacceptable for our use case. We need at least 150 feet range. We would like to extend this support to watchOS and the MC framework is not available. Regarding #1, I'd like to confirm that if infrastructure wifi is available, MC uses it. If infrastructure wifi is not available, MC uses peer-to-peer wifi. If this is true, then we can assure our customers that if infrastructure wifi is available at the venue, then with all devices connected to it, range will be adequate. If infrastructure wifi is not available at the venue, perhaps a mobile wifi router (battery operated) could be set up, devices connected to it, then range would be adequate. We are about to test this. Reasonable? Can we be assured that if infrastructure wifi is available, MC uses it? Regarding #2, given we are targeting minimum watchOS 7.0, would the available networking APIs and frameworks be adequate to implement our own equivalent of the MC framework so our app on iOS/iPadOS and watchOS devices could communicate? How much work? Where would I start? I'm new to implementing networking but experienced in using the MC framework. I'm assuming that I would write the networking code to use infrastructure wifi to achieve acceptable range. Many thanks! Tim

Hello, I am working to integrate the new com.apple.developer.networking.carrier-constrained.app-optimized entitlement in my iOS 26 app so that my app can use a carrier-provided satellite network, and want to confirm my understanding of how to detect and optimize for satellite network conditions. (Ref: https://aninterestingwebsite.com/documentation/bundleresources/entitlements/com.apple.developer.networking.carrier-constrained.app-optimized ) My current approach: I plan to set the entitlement to true once my app is optimized for satellite networks. To detect if the device is connected to a satellite network, I intend to use the Network framework’s NWPath properties: isUltraConstrained — I understand this should be set to true when the device is connected to a satellite network. (Ref: https://aninterestingwebsite.com/documentation/network/nwpath/isultraconstrained ) linkQuality == .minimal — I believe this will also be set in satellite scenarios, though it may not be exclusive to satellite connections. (Ref: https://aninterestingwebsite.com/documentation/network/nwpath/linkquality-swift.enum/minimal ) Questions: Is it correct that isUltraConstrained will reliably indicate a satellite connection? Should I also check for linkQuality == .minimal, or is isUltraConstrained sufficient? Are there any additional APIs or best practices for detecting and optimizing for satellite connectivity that I should be aware of? Thank you for confirming whether my understanding and approach are correct, and for any additional guidance.

I’m using Network Framework with UDP and calling: connection.receive(minimumIncompleteLength: 1, maximumLength: 1500) { data, context, isComplete, error in ... // Some Logic } Is it possible for this completion handler to be called with data==nil if I haven't received any kind of error, i.e., error==nil and the connection is still in the .ready state?

I'm trying to use ThreadNetwork API to manage TheradNetworks on device (following this documentation: https://aninterestingwebsite.com/documentation/threadnetwork/), but while some functions on THClient work (such as getPreferedNetwork), most don't (storeCredentials, retrieveAllCredentials). When calling these functions I get the following warning/error: Client: -[THClient getConnectionEntitlementValidity]_block_invoke - Error: -[THClient storeCredentialsForBorderAgent:activeOperationalDataSet:completion:]_block_invoke:701: - Error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service with pid 414 named com.apple.ThreadNetwork.xpc was invalidated from this process." UserInfo={NSDebugDescription=The connection to service with pid 414 named com.apple.ThreadNetwork.xpc was invalidated from this process.} Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service with pid 414 named com.apple.ThreadNetwork.xpc was invalidated from this process." UserInfo={NSDebugDescription=The connection to service with pid 414 named com.apple.ThreadNetwork.xpc was invalidated from this process.} Failed to store Thread credentials: Couldn’t communicate with a helper application. STEPS TO REPRODUCE Create new project Add Thread Network capability via Xcode UI (com.apple.developer.networking.manage-thread-network-credentials) Trigger storeCredentials let extendedMacData = "9483C451DC3E".hexadecimal let tlvHex = "0e080000000000010000000300001035060004001fffe002083c66f0dc9ef53f1c0708fdb360c72874da9905104094dce45388fd3d3426e992cbf0697b030d474c2d5332302d6e65773030310102250b04106c9f919a4da9b213764fc83f849381080c0402a0f7f8".hexadecimal // Initialize the THClient let thClient = THClient() // Store the credentials await thClient.storeCredentials(forBorderAgent: extendedMacData!, activeOperationalDataSet: tlvHex!) { error in if let error = error { print(error) print("Failed to store Thread credentials: \(error.localizedDescription)") } else { print("Successfully stored Thread credentials") } } NOTES: I tried with first calling getPreferedNetwork to initiate network permission dialog Tried adding meshcop to bojur services Tried with different release and debug build configurations

Hi, I am having a ton of issues with the new multicast/network entitlements requirements on MacOS. Basically, since my app didn't request these new entitlements until recently, if the app had been installed without these permissions enabled, it will not pick up the new permissions once they are enabled. The only options I had were to create a new user, and install the app under the new user, which works, but is not a real solution for users. This is really problematic, as there is no way currently to remove or change these network permissions once they are established. Is there a way to fix this? Or some other workarounds I am missing? Thanks Also via the documentation: TN3179: Understanding local network privacy | Apple Developer Documentation "There's no guarantee that it'll actually trigger the alert” And "On macOS there’s no way to reset your program’s Local Network privilege to the undetermined state (FB14944392). One alternative is to run your program in a virtual machine (VM). To retest, restore the VM from a snapshot taken before you installed your program.”

(iOS 17.3) I'm using the Apple supplied iOS sample project "ConfiguringAWiFiAccessoryToJoinTheUsersNetwork" as a base to write an App to configure an existing WiFi device using the NEHotspotConfiguration API's. I have almost everything working, and can join the network and send a packet to the device to configure it. I know that it is working as the device responds properly to what I send it. But I am not able to receive the response back from the device to the packet sent. (Only need 1 packet sent and 1 packet received) However. If I run a packet sniffer on the phone before running my test App, then I do get a response. No packet sniffer running, no response. When I do a debugDescription on the NWConnection after it reaches ".ready", I notice that when the sniffer is running I'm using loopback lo0: [C1 connected 192.168.4.1:80 tcp, url: http://192.168.4.1:80, attribution: developer, path satisfied (Path is satisfied), viable, interface: lo0] and I get a packet response in the NWConnection receiveMessage callback. But with no sniffer running, I get interface en0: [C1 connected 192.168.4.1:80 tcp, url: http://192.168.4.1:80, attribution: developer, path satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, dns, uses wifi] and there is no callback to the receiveMessage handler and the NWconnection eventually times out. The interface used seems to be the only difference that I can see when I have a sniffer running. Any ideas as to why I can't see a response in "normal" operation?

we use the api as NEHotspotConfigurationManager.shared.apply(hotspotConfig) to join a wifi, but we find that in in iphone 17+, some user report the time to join wifi is very slow the full code as let hotspotConfig = NEHotspotConfiguration(ssid: sSSID, passphrase: sPassword, isWEP: false) hotspotConfig.joinOnce = bJoinOnce if #available(iOS 13.0, *) { hotspotConfig.hidden = true } NEHotspotConfigurationManager.shared.apply(hotspotConfig) { [weak self] (error) in guard let self else { return } if let error = error { log.i("connectSSID Error while configuring WiFi: \(error.localizedDescription)") if error.localizedDescription.contains("already associated") { log.i("connectSSID Already connected to this WiFi.") result(["status": 0]) } else { result(["status": 0]) } } else { log.i("connectSSID Successfully connected to WiFi network \(sSSID)") result(["status": 1]) } } Normally it might only take 5-10 seconds, but on the iPhone 17+ it might take 20-30 seconds.

On my iPhone 16 Pro and iPhone 16 Pro Max devices, running iOS 26.0, 26.0.1, and 26.1, Wi-Fi raw socket communication works flawlessly. Even after keeping the connection active for over 40 minutes, there are no disconnections during data transmission. However, on the iPhone 17 and iPhone 17 Pro, the raw socket connection drops within 20 seconds. Once it disconnects, the socket cannot reconnect unless the Wi-Fi module itself is reset. I believe this issue is caused by a bug in the iPhone 17 series’ communication module. I have looked into many cases, and it appears to be related to a bug in the N1 chipset. Are there any possible solutions or workarounds for this issue?

Description Enterprise users are experiencing VPN resource access failures after upgrading to macOS Tahoe. Investigation indicates that configd (specifically IPMonitor) is incorrectly re-ranking network interfaces after a connectivity failure with probe server. This results in DNS queries routing through the physical network adapter (en0) instead of the VPN virtual adapter, even while the tunnel is active. This behaviour is not seen in previous macOS versions. Steps to Reproduce: Connect to an enterprise VPN (e.g., Ivanti Secure Access). Trigger a transient network condition where the Apple probe server is unreachable. For example make the DNS server down for 30 sec. Observe the system routing DNS queries for internal resources to the physical adapter. Expected Results The: VPN virtual interface should maintain its primary rank for enterprise DNS queries regardless of the physical adapter's probe status. Actual Results: IPMonitor detects an UplinkIssue, deprioritizes the VPN interface, and elevates the physical adapter to a higher priority rank. Technical Root Cause & Logs: The system logs show IPMonitor identifying an issue and modifying the interface priority at 16:03:54: IPMonitor Detection: The process identifies an inability to reach the Apple probe server and marks en0 with an advisory: Log snippet 2026-01-06 16:03:53.956399+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] configd[594] SetInterfaceAdvisory(en0) = UplinkIssue (2) reason='unable to reach probe server' Interface Re-ranking: Immediately following, IPMonitor recalculates the rank, placing the physical service ID at a higher priority (lower numerical rank) than the VPN service ID (net.pulsesecure...): Log snippet 2026-01-06 16:03:53.967935+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 0. en0 serviceID=50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 addr=192.168.0.128 rank=0x200000d 2026-01-06 16:03:53.967947+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 1. en0 serviceID=net.pulsesecure.pulse.nc.main addr=192.168.0.128 rank=0x2ffffff 3.Physical adapter Is selected as Primary Interface: 2026-01-06 16:03:53.968145+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 is the new primary IPv4 configd[594]: 50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 is the new primary DNS Packet Trace Evidence Wireshark confirms that DNS queries for enterprise-specific DNS servers are being originated from the physical IP (192.168.0.128) instead of the virtual adapter: Time: 16:03:54.084 Source: 192.168.0.128 (Physical Adapter) Destination: 172.29.155.115 (Internal VPN DNS Server) Result: Connectivity Failure (Queries sent outside the tunnel)

I have an Xcode app where currently txt files in the project display text data as a list. I can search through the lists and have buttons that will swap between different lists of information that you can look through. The next task is I have URL connections to docx files on a SharePoint site. I am trying to use an URLsession function to connect to the URL links to download the documents to the document directory then have the application read the doc information to then be displayed as the txt info would. The idea is that the docx files are a type of online update version of the data. So when the app is used and on wifi, the app can update the list data with the docx files. I have code set up that should access the URL files but I am struggling to figure out how to read the data and access from this Documents directory. I have been looking online and so far I am at a loss on where to go here. If anyone can help or provide some insight I would greatly appreciate it. I can try and provide code samples to help explain things if that is needed.