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://developer.apple.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://developer.apple.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://developer.apple.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.

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.

Our application has initiated an NSURLSession data task, and we have received an initiation ID. However, Application not received callback on the subsequent activity: the task has not been requested, has not timed out, and no error callback has been received. [06/17 09:29:40:559][ 0x282a7d8c0] Requested TaskIdentifier 120 2025-06-17 09:29:40.623337 +0530 nsurlsessiond SUBMITTING: com.apple.CFNetwork-cc-166-373-Task .<120>:A71666 default 2025-06-17 09:29:40.631280 +0530 dasd Submitted Activity: com.apple.CFNetwork-cc-166-373-Task .<120>:A71666 at priority 10 default Seen couple of rejection with for CPUUsagePolicy and MemoryPressurePolicy 2025-06-17 09:29:40.989360 +0530 dasd com.apple.CFNetwork-cc-166-373-Task .<120>:A71666:[ {name: CPUUsagePolicy, policyWeight: 5.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[Max allowed CPU Usage level]: Required:90.00, Observed:95.00},]}} {name: MemoryPressurePolicy, policyWeight: 5.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[memoryPressure]: Required:1.00, Observed:2.00},]}} ], FinalDecision: Must Not Proceed} default 2025-06-17 10:55:22.500277 +0530 dasd com.apple.CFNetwork-cc-166-373-Task .<120>:A71666:[ {name: MemoryPressurePolicy, policyWeight: 5.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[memoryPressure]: Required:1.00, Observed:2.00},]}} ], FinalDecision: Must Not Proceed} default And more an hour later then it throws with an error BUT NEVER indicated the same to client 2025-06-17 10:55:27.426549 +0530 WAVE PTX Task .<120> is for <>.<>.<120> default 2025-06-17 10:55:27.776951 +0530 nsurlsessiond Task .<120> summary for task failure {transaction_duration_ms=5147145, response_status=-1, connection=0, reused=1, request_start_ms=0, request_duration_ms=0, response_start_ms=0, response_duration_ms=0, request_bytes=0, response_bytes=0, cache_hit=false} default 2025-06-17 10:55:27.777096 +0530 nsurlsessiond NDSession <714296D7-20F9-4A0A-8C31-71FB67F39A56> Task .<120> for client will be retried after error Error Domain=_nsurlsessiondErrorDomain Code=6 UserInfo={NSErrorFailingURLStringKey=, NSErrorFailingURLKey=, _NSURLErrorRelatedURLSessionTaskErrorKey=, _NSURLErrorFailingURLSessionTaskErrorKey=} - code: 6 default Then It got resumed and says successful but never got any callback on the same to client 2025-06-17 10:55:28.877245 +0530 nsurlsessiond NDSession <714296D7-20F9-4A0A-8C31-71FB67F39A56> Task .<120> resuming default 2025-06-17 10:55:55.225456 +0530 nsurlsessiond Task .<120> received response, status 401 content K default 2025-06-17 10:55:55.250371 +0530 nsurlsessiond Task .<120> finished successfully default Please refer feedback for diagnose logs: https://feedbackassistant.apple.com/feedback/18173303

When I try to implement the new Background Task options in the same way as they show in the WWDC video (on watchOS) likes this: let config = URLSessionConfiguration.background(withIdentifier: "SESSION_ID") config.sessionSendsLaunchEvents = true let session = URLSession(configuration: config) let response = await withTaskCancellationHandler {       try? await session.data(for: request) } onCancel: {       let task = session.downloadTask(with: request))       task.resume() } I'm receiving the following error: Terminating app due to uncaught exception 'NSGenericException', reason: 'Completion handler blocks are not supported in background sessions. Use a delegate instead.' Did I forget something?

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?

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

Our application uses NEFilterPacketProvider to filter network traffic and we sometimes get a wired crash when removing/updating the network extension. It only happens on MacOS 11-12 . The crashing thread is always this one and it shows up after I call the completionHandler from the stopFilter func Application Specific Information: BUG IN CLIENT OF LIBDISPATCH: Release of a suspended object Thread 6 Crashed:: Dispatch queue: com.apple.network.connections 0 libdispatch.dylib 0x00007fff2039cc35 _dispatch_queue_xref_dispose.cold.1 + 24 1 libdispatch.dylib 0x00007fff20373808 _dispatch_queue_xref_dispose + 50 2 libdispatch.dylib 0x00007fff2036e2eb -[OS_dispatch_source _xref_dispose] + 17 3 libnetwork.dylib 0x00007fff242b5999 __nw_queue_context_create_source_block_invoke + 41 4 libdispatch.dylib 0x00007fff2036d623 _dispatch_call_block_and_release + 12 5 libdispatch.dylib 0x00007fff2036e806 _dispatch_client_callout + 8 6 libdispatch.dylib 0x00007fff203711b0 _dispatch_continuation_pop + 423 7 libdispatch.dylib 0x00007fff203811f4 _dispatch_source_invoke + 1181 8 libdispatch.dylib 0x00007fff20376318 _dispatch_workloop_invoke + 1784 9 libdispatch.dylib 0x00007fff2037ec0d _dispatch_workloop_worker_thread + 811 10 libsystem_pthread.dylib 0x00007fff2051545d _pthread_wqthread + 314 11 libsystem_pthread.dylib 0x00007fff2051442f start_wqthread + 15 I do have a DispatchSourceTimer but I cancel it in the stop func. Any ideas on how to tackle this?

All of our uses of CFSockets have started causing crashes in iOS 16. They seem to be deprecated so we are trying to transition over to using the Network framework and NWConnection to try to fix the crashes. One of our uses of them is to ping a device on the local network to make sure it is there and online and provide a heartbeat status in logs as well as put the application into a disabled state if it is not available as it is critical to the functionality of the app. I know it is discouraged to disable any functionality based on the reachability of a resource but this is in an enterprise environment where the reachability of this device is mission critical. I've seen other people ask about the ability to ping with the Network framework and the answers I've found have said that this is not possible and pointed people to the SimplePing sample code but it turns out our existing ping code is already using this technique and it is crashing just like our other CFSocket usages, inside CFSocketInvalidate with the error BUG IN CLIENT OF LIBPLATFORM: Trying to recursively lock an os_unfair_lock. Is there any updated way to perform a ping without using the CFSocket APIs that now seem to be broken/unsupported on iOS 16?

(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 have an old iOS app and an old camera that connects using Wi-Fi either using an access point or Ad Hoc network, e.g., iPhone/iPad connects to the camera's Wi-Fi directly... How it works (old legacy app/system, which cannot be redesigned): Camera is configured to Ad Hoc Wi-Fi network (insecure TCP). iPhone connects to this insecure Wi-Fi. Camera uses Bonjour service to broadcast its IP address. App reads in IP address and begin to send messages to the camera using NSMutableURLRequest, etc. All this works fine for iOS 17. But in iOS 18 step 4 stopped working. App simply doesn't get any responses! We believe we have configured ATS properly (App Store version): In panic we have also tried this in Test Flight version: The latter actually seemed to make a difference when running the app on macOS Apple Silicon. But on iOS it didn't seem to make any difference. Occasionally, I was lucky to get connection on on iPhone 16 Pro with iOS 18. But for the 'many' iPads I have tried I couldn't. I also tried to install CFNetwork profile and look at the logs but I believe I just got timeout on the requests. Questions: Why it iOS 18 different? Bonjour works fine, but NSSURLRequests doesn't Do we configure ATS correctly for this scenario? What should I look for in the Console log when CFNetwork profile is installed? Should I file a TSI? Thanks! :)

With my UDP Flow Copier working as demonstrated by the fact that it is proxying DNS traffic successfully, I am finally writing tests to verify UDP packet filtering. I'm sending packets to a public UDP echo server and reading the response successfully. In my initial testing however the TransparentProxyProvider System Extension is not intercepting my UDP traffic. handleNewUDPFlow() is being called for DNS but not for my test case UDP echo sends and receives. I've tried sending UDP with both GCDAsyncSocket and NWConnection as: connection = NWConnection(host: host, port: port, using: .udp) Is there some other criteria for UDP datagrams to be intercepted? Google search suggests this might be a known issue for connected or async UDP sockets.

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?

Hello, Recently I am trying to add stub dns server to my Network Extension (a VPN app), after some research on this forum, and since my language is C, I have the following plan: create a udp socket which use setsockopt(IP_BOUND_IF) to bound the socket to the utun if index obtained, and also bind to the address of the utun address I set(let's say 192.168.99.2), then listen on the udp port 53 which is ready to handle dns request. configure the dns server to 192.168.99.2 in the provider's Network Settings, thus iOS system will send udp query to the udp socket created in step 1, and it can then do some split dns function such as resolve using local interface (cellular or wifi), or some nameserve which will be routed to the VPN tunnel (will create new UDP socket and do IP_BOUND_IF to ensure the traffic will enter the VPN tunnel), and the result should be return to the system and then the non VPP apps. But I observer weird issue, indeed I can get the system send the dns request to the listening udp socket and I can get the result write to the system(address like 192.168.99.2:56144, the port should be allocated by the iOS system's DNS component) without any failure(I did get some error before due to I using the wrong utun if index, but fixed it later), but it seems non VPN app like browser can't get the resolved ip for domains. I want to ask is this limited by the sandbox? or any special sock opt I need to do. Thanks. PS: in the provider's network settings, all the system's traffic will be point to the utun, which means the VPN process will process all the traffic. the reason I do not set the dns server to utun peers side which is my userspace networking stack's ip (192.168.99.1) is the stack is not be able to leverage some dns libraries due to architecture issue. (it's fd.io vpp which we ported to apple platform).

When the machine connects to the network cable through the Thunderbolt interface using the docking station, if the Network Extension shown in the following code is running at this time, after unplugging and reinserting the docking station, the machine will not be able to obtain a valid IP address through DHCP until the system is restarted. @interface MyTransparentProxyProvider : NETransparentProxyProvider @end @implementation MyTransparentProxyProvider - (void)startProxyWithOptions:(NSDictionary *)options completionHandler:(void (^)(NSError *))completionHandler { NETransparentProxyNetworkSettings *objSettings = [[NETransparentProxyNetworkSettings alloc] initWithTunnelRemoteAddress:@"127.0.0.1"]; // included rules NENetworkRule *objIncludedNetworkRule = [[NENetworkRule alloc] initWithRemoteNetwork:nil remotePrefix:0 localNetwork:nil localPrefix:0 protocol:NENetworkRuleProtocolAny direction:NETrafficDirectionOutbound]; NSMutableArray<NENetworkRule *> *arrIncludedNetworkRules = [NSMutableArray array]; [arrIncludedNetworkRules addObject:objIncludedNetworkRule]; objSettings.includedNetworkRules = arrIncludedNetworkRules; // apply [self setTunnelNetworkSettings:objSettings completionHandler: ^(NSError * _Nullable error) { // TODO } ]; if (completionHandler != nil) completionHandler(nil); } - (BOOL)handleNewFlow:(NEAppProxyFlow *)flow { return NO; } @end This problem will not occur if the IP of the DNS server or all UDP ports 53 are excluded in the Network Extension. @interface MyTransparentProxyProvider : NETransparentProxyProvider @end @implementation MyTransparentProxyProvider - (void)startProxyWithOptions:(NSDictionary *)options completionHandler:(void (^)(NSError *))completionHandler { NETransparentProxyNetworkSettings *objSettings = [[NETransparentProxyNetworkSettings alloc] initWithTunnelRemoteAddress:@"127.0.0.1"]; // included rules NENetworkRule *objIncludedNetworkRule = [[NENetworkRule alloc] initWithRemoteNetwork:nil remotePrefix:0 localNetwork:nil localPrefix:0 protocol:NENetworkRuleProtocolAny direction:NETrafficDirectionOutbound]; NSMutableArray<NENetworkRule *> *arrIncludedNetworkRules = [NSMutableArray array]; [arrIncludedNetworkRules addObject:objIncludedNetworkRule]; // excluded rules NENetworkRule *objExcludedNetworkRule = [[NENetworkRule alloc] initWithRemoteNetwork:[NWHostEndpoint endpointWithHostname:@"" port:@(53).stringValue] remotePrefix:0 localNetwork:nil localPrefix:0 protocol:NENetworkRuleProtocolUDP direction:NETrafficDirectionOutbound]; NSMutableArray<NENetworkRule *> *arrExcludedNetworkRules = [NSMutableArray array]; [arrExcludedNetworkRules addObject:objExcludedNetworkRule]; objSettings.includedNetworkRules = arrIncludedNetworkRules; objSettings.excludedNetworkRules = arrExcludedNetworkRules; // apply [self setTunnelNetworkSettings:objSettings completionHandler: ^(NSError * _Nullable error) { // TODO } ]; if (completionHandler != nil) completionHandler(nil); } - (BOOL)handleNewFlow:(NEAppProxyFlow *)flow { return NO; } @end Is MyTransparentProxyProvider in what place do wrong? To handle the connection on port 53, it is necessary to add the implementation of NEDNSProxyProvider? In -[MyTransparentProxyProvider handleNewFlow:] how to reverse DNS? getnameinfo() doesn't work, it returns EAI_NONAME.

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!

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

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?

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?

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.

Case-ID: 17935956 In the NetworkExtension framework, for the NETransparentProxyProvider and NEDNSProxyProvider classes: when calling the open func writeDatagrams(_ datagrams: [Data], sentBy remoteEndpoints: [NWEndpoint]) async throwsin the NEDNSProxyProvider class, and the open func write(_ data: Data, withCompletionHandler completionHandler: @escaping @Sendable ((any Error)?) -> Void)in the NETransparentProxyProvider class, errors such as "The operation could not be completed because the flow is not connected" and "Error Domain=NEAppProxyFlowErrorDomain Code=1 "The operation could not be completed because the flow is not connected"" occur. Once this issue arises, if it occurs in the NEDNSProxyProvider, the entire system's DNS will fail to function properly; if it occurs in the NETransparentProxyProvider, the entire network will become unavailable.