I was trying to call getsockopt(fd, SOL_LOCAL, LOCAL_PEERCRED, ...), and by mistake passed a wrong value for the second parameter where it should be SOL_LOCAL. But the call still succeeded. Then I did more experiments and passed more random values for the second parameter, all succeeded. It seems there is a lack of parameter check in the implementation of getsockopt() , where it should return errors if people pass invalid parameters instead of succeeding silently. Hope the Apple engineers can help to validate and fix it.

Hi everyone, I’m working with the DNSServiceGetAddrInfo API and came across the following statement in the documentation: If the call succeeds then it initializes the DNSServiceRef, returns kDNSServiceErr_NoError, and the query begins and will last indefinitely until the client terminates the query by passing this DNSServiceRef to DNSServiceRefDeallocate(_) I’m trying to understand exactly what this means in practice. Specifically, after receiving a response with kDNSServiceFlagsMoreComing, being set to 0 does it imply that the OS itself continues querying the DNS periodically or indefinitely, even after we've already received some results? Or does it only continue fetching additional results related to the initial query until we explicitly terminate it? Any clarification on the behavior of this query would be greatly appreciated! Thanks in advance!

Hi all, I’m developing a watchOS app that uses a WebSocket API to process voice audio. However, I keep encountering this error when trying to establish the connection: nw_endpoint_flow_failed_with_error [C1 <server URL>:443 failed parent-flow (unsatisfied (Path was denied by NECP policy), interface: ipsec2, ipv4, ipv6, proxy)] already failing, returning I’ve read Technical Note TN3135, which outlines an exception for audio streaming apps. My app is an audio streaming app, and I’ve already added background audio mode to the app’s capabilities. However, I’m not sure what else is required to meet the exception described in TN3135. Questions How do I meet the exception outlined in TN3135 for WebSocket audio streaming on watchOS? Does NECP enforce additional restrictions even with background audio enabled, and how can I address this? Any guidance or examples of implementing WebSocket audio streaming on watchOS would be greatly appreciated. Thanks!

I am unable to apply for Multicast Entitlement at https://developer.apple.com/contact/request/networking-multicast The reason for this is unclear. I have paid for a developer account and believe I'm up to date with all agreements.

Our company has a VPN client that uses the Packet Tunnel Provider network extension and when 18 came out we noticed that we were no longer seeing DNS requests get sent to the VPNs TUN interface. Do a packet trace, once the VPN becomes active we see requests to _dns.resolver.arpa and 12-courier.push.apple.com, which both get resolved as expected. Also our main app that controls the VPN service and does authentication has to resolve a hostname to get to an authentication service and we see those requests just fine as well. However, when we try to resolve by going to a webpage in Safari we see no DNS request corresponding to that. What are we missing? At first I thought it was the RFC9461 stuff but from the packet traces I don't believe that is the case. I have also tried other networking tools to send the DNS requests and that failed as well.

I added a Content Filter to my app, and when running it in Xcode (Debug/Release), I get the expected permission prompt: "Would like to filter network content (Allow / Don't Allow)". However, when I install the app via TestFlight, this prompt doesn’t appear at all, and the feature doesn’t work. Is there a special configuration required for TestFlight? Has anyone encountered this issue before? Thanks!

We use Boost ***** (1.86.0) for WebSockets in an iOS application using a self-signed certificate. The ***** WebSocket client works fine on iOS 18.1 and every other OS (Windows, Android, Linux, etc...) but not iOS 18.3.1 and possibly versions before 18.3.1 but later than iOS 18.1. Has anyone else ran into this issue and how did you resolve? What could have changed after iOS 18.1 that would prevent a WSS Websocket from connecting that works fine on iOS 18.1?

Hi, I have been reviewing some previous discussions around networking in macOS, and I’d like to clarify my understanding of the differences between the kernel-space network stack and user-space network stack and validate this understanding based on the information shared in earlier threads. I’m also curious about how these differences impact macOS applications, particularly those requiring maintaining many simultaneous network connections. Understanding Kernel-Space vs User-Space Network Stack Kernel-Space Network Stack (BSD Sockets): The kernel-space networking stack refers to the traditional networking layer that runs in the kernel and handles network communication via BSD sockets. This stack is lower-level and interacts directly with the operating system's networking drivers and hardware. All network connections managed through this stack require a socket (essentially a file descriptor) to be opened, which places limits on the number of file descriptors that can be used (for example, the default 64K limit for sockets). The kernel network stack is traditionally used on macOS (and other UNIX-based systems) for networking tasks, such as when you use system APIs like BSD sockets. User-Space Network Stack (Network Framework): The user-space network stack in macOS (via the Network framework) allows applications to handle networking tasks without directly using the kernel. This provides more flexibility and performance benefits for certain types of network operations, as the networking stack is managed in user space rather than kernel space. This approach reduces overhead and allows more control over networking configurations. In theory, with user-space networking, the application wouldn't be bound by kernel-level socket limits, and it could handle many more simultaneous connections efficiently. In previous posts on that thread, Quinn mentioned that the Network framework in macOS can rely on the user-space stack (by default) for network operations, but there are still cases where macOS falls back to using the kernel stack (i.e., BSD sockets) under certain conditions. One key example is when the built-in firewall is enabled. This prevents user-space networking from functioning as expected, and the system defaults to using the kernel's BSD sockets for network communication. In the same discussion, it was also highlighted that NECP (Network Extension Control Plane) could place further limitations on user-space networking, and eventually, systems may run into issues like ENOSPC errors due to excessive simultaneous network flows. This suggests that while user-space networking can offer more flexibility, it's not immune to limits imposed by other system resources or configurations. Given the information above, I wanted to confirm: Is the above understanding correct and does the macOS Network framework still use the user-space networking stack in macOS 14 and beyond? Under what conditions would the system fall back to using the kernel stack (BSD sockets) instead of the user-space stack? For example, does enabling the firewall still disable user-space networking? What is the practical impact of this fallback on applications that require many simultaneous network connections? Specifically, are there any limitations like the 64K socket limit that developers should be aware of when the system uses the user space stack, and what are the best practices to manage large numbers of connections?

The Download is not Working in the background mode even if i entitled all the necessary permission for the application it only works when the app is connected to xcode due to xcode keep the session alive but if try after removing the connection from the xcode the app not able to keep the download after 45 sec what may be the reason my code var request = URLRequest(url: url) request.httpMethod = "GET" let bearerToken = SyncManager.accessToken request.setValue("Bearer \(bearerToken)", forHTTPHeaderField: "Authorization") let uniqueIdentifier = "\(self.vdmsId)_\(UUID().uuidString)" backgroundTaskID = UIApplication.shared.beginBackgroundTask { [weak self] in if let taskID = self?.backgroundTaskID { UIApplication.shared.endBackgroundTask(taskID) self?.backgroundTaskID = .invalid } } let CursessionConfig = URLSessionConfiguration.background(withIdentifier: uniqueIdentifier) CursessionConfig.isDiscretionary = false CursessionConfig.sessionSendsLaunchEvents = true CursessionConfig.shouldUseExtendedBackgroundIdleMode = true // Set timeout intervals CursessionConfig.timeoutIntervalForResource = 24 * 60 * 60 // 24 hours CursessionConfig.timeoutIntervalForRequest = 60 * 60 // 1 hour let Cursession = URLSession(configuration: CursessionConfig, delegate: self, delegateQueue: nil) self.CurInstanceSession = Cursession self.session = Cursession if SyncManager.activeSessions == nil { SyncManager.activeSessions = [URLSession]() } SyncManager.activeSessions?.append(Cursession) self.downloadCompletionHandler = completion let CurdownloadTask = Cursession.downloadTask(with: request) CurdownloadTask.resume() is there any solutions and i have entitled all the neccessary permisssions like background fetch, process and i also tries with the UIApplication.shared.beginBackgroundTask but after 45 sec it gets terminated all of the suden what may be the issue

Hi, We are working on an app that communicates over a UDP connection on the local network. In our testing, we have a Python UDP client running on the same network, which responds when we send a message to a broadcast IP (255.255.255.255). This setup works as expected on an iOS 15 device. However, when we test the same scenario on an iOS 18 device, the UDP communication doesn't seem to reach the Python UDP client. We've verified that the UDP client and the iOS device are on the same network, and the Python client is responding correctly. Has Apple introduced any restrictions or changes regarding UDP broadcast behavior in iOS 18? Is broadcasting to 255.255.255.255 still supported, or has this functionality been limited in recent iOS versions?

I am trying to connect an iPhone 16 (iOS 18.3) to a Wi-Fi device with the SSID "DIRECT-DR_6930_KP201128", but every time, without being able to enter the Wi-Fi password, the message "Unable to join the network 'DIRECT-DR_6930_KP201128'" is displayed. Below are the system logs from the connection failure. Could you please tell me the cause of the connection failure? By the way, an iPhone SE 2nd (iOS 18.2.1) can connect to the same Wi-Fi device without any issues. System Logs: ・Jan 31 19:18:14 900-iPhone-16-docomo Preferences(WiFiKit)[351] : {ASSOC-} association finished for DIRECT-DR_6930_KP201128 - success 0 ・Jan 31 19:18:14 900-iPhone-16-docomo runningboardd(RunningBoard)[33] : Assertion 33-351-4412 (target:[app<com.apple.Preferences(DE1AB487-615D-473C-A8D6-EAEF07337B18)>:351]) will be created as inactive as start-time-defining assertions exist ・Jan 31 19:18:14 900-iPhone-16-docomo Preferences(WiFiKit)[351] : association failure: (error Error Domain=com.apple.wifikit.error Code=12 "Unknown Error" UserInfo={NSDebugDescription=Unknown Error, NSUnderlyingError=0x303307660 {Error　Domain=com.apple.corewifi.error.wifid Code=-3938 "(null)"}}) ・Jan 31 19:18:14 900-iPhone-16-docomo Preferences(WiFiKit)[351] : dismissing credentials view controller for DIRECT-DR_6930_KP201128

Hi we want to use CONNECT-IP extension within the MASQUE protocol suite. we want to be able to reroute ICMP packets from our machine and redirect them to our MASQUE proxy. we want to avoid a creation of virtual interface or modifying the routing tables. is it possible, if so, how can it be achieved. thanks

Feedback Ticket: FB13812251 Problem Statement: We are currently facing internet connectivity issue with our VPN application where we try to disconnect the VPN from the Packet Tunnel Network Extension using - (void)cancelTunnelWithError:(nullable NSError *)error. Which API to use to disconnect the VPN from Packet Tunnel as VPN app is not running such that device retains its internet connectivity as soon as VPN disconnects. Configuration: We have configured PacketTunnelProvider with the following settings: (NETunnelProviderManager *)tunnelProvider.protocolConfiguration.includeAllNetworks = YES; (NETunnelProviderManager *)tunnelProvider.protocolConfiguration.excludeLocalNetworks = NO; (NETunnelProviderManager *)tunnelProvider.protocolConfiguration.enforceRoutes = NO; These settings are applied from the VPN app and allow us to successfully establish a VPN connection, with all traffic being routed through the tunnel as expected.We are setting above properties to address local net attack. Issue we are facing: However, we encounter a problem when we attempt to disconnect the VPN from. When we call the following method from PacketTunnel network extension: (void)cancelTunnelWithError:(nullable NSError *)error Upon calling this method, the VPN disconnects as expected, but the device loses all internet connectivity and is unable to access any resources. This is not the desired behavior. Observation : Interestingly, when we call the following method from the app side. The VPN disconnects and the device retains its internet connectivity. [enabledConfig.connection stopVPNTunnel]; We would like to achieve the same behavior when disconnecting the VPN from the Network Extension. So we are looking for an API that could be called from NE without causing any internet connectivity issue. Any guidance on how to resolve this issue would be greatly appreciated.

Hi, I am working on a use case where I want to read the wifi signal strength data in the terms of RSSI (Received Signal Strength Indicator) values (or) any other way of representation. when my iPhone is connected to the wifi and Move around the house. Is this use case possible ? If yes, what are all the entitlements that I have to obtain?

I have some concerns related to shortening the lifetime of certificates, as per https://support.apple.com/en-gb/102028 Does this apply to Private CA root certificates? And if yes: does it apply if I use ATS and higher level API like URLSession does it apply it I carry my root CA cert in my app payload and use low level libraries without ATS support?

I recently encountered an issue with incorrect progress reporting and timeout behavior when using NSURLSession to upload small data buffers. Background In my app, I split a large video file into smaller 1MB chunk files for upload. This approach facilitates error retries and concurrent uploads. Additionally, I monitor the upload speed for each request, and if the speed is too slow, I switch CDNs to re-upload the chunk. Issue Description When using NSURLSessionUploadTask or NSURLSessionDataTask to upload a 1MB HTTP body, I noticed that the progress callbacks are not accurate. I rely on the following callback to track progress: - (void)URLSession:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend: Even when using Network Link Conditioner to restrict bandwidth to a very low level, this callback reports identical values for totalBytesSent and totalBytesExpectedToSend right at the start of the request, indicating 100% upload progress. However, through network traffic inspection, I observed that the upload continues slowly and is far from complete. Additionally, I noticed that even though the upload is still ongoing, the request times out after the duration specified in - NSURLSessionConfiguration.timeoutIntervalForRequest. According to the documentation: "The request timeout interval controls how long (in seconds) a task should wait for additional data to arrive before giving up. The timer associated with this value is reset whenever new data arrives." This behavior suggests that the timeout timer is not reset as the document says during slow uploads, likely because didSendBodyData is not updating as expected. Consequently, the timer expires prematurely, causing 1MB chunks to frequently timeout under slow network conditions. This also prevents me from accurately calculating the real-time upload speed, making it impossible to implement my CDN switching strategy. Some Investigation I have found discussions on this forum regarding similar issues. Apple engineers mentioned that upload progress is reported based on the size of data written to the local buffer rather than the actual amount of data transmitted over the network. This can indeed explain the behaviour mentioned above: https://developer.apple.com/forums/thread/63548 https://developer.apple.com/forums/thread/746523 Interestingly, I also noticed that progress reporting works correctly when uploading to some certain servers, which I suspect is related to the TCP receive window size configured on those servers. For example: Accurate progress: https://www.w3schools.com Inaccurate progress: Most servers, like https://developer.apple.com I created a sample project to demostrate the progress & timeout issues and different behaviours when uploading to some servers: https://github.com/Naituw/NSURLSessionUploadProgressTest Questions Is there any way to resolve or workaround this issue? Like adjusting the size of the local send buffer? or configuring NSURLSession to report progress based on acknowledged TCP packets instead of buffer writes? Or are there any alternative solutions for implementing more accurate timeout mechanisms and monitoring real-time upload speed?

I am looking for a lightweight server that can run inside an app. The key requirement is that it must support local IP communication over HTTPS. I have searched Google and found several frameworks, but as far as I know, support for HTTPS in this environment has been discontinued or is no longer available. If anyone knows a solution that meets these criteria, I would greatly appreciate your guidance. Thank you in advance!😀

We have an app which is using CTSubscriber.simInserted (using the carrier entitlement com.apple.CommCenter.fine-grained). In iOS 18, simInserted returns false for every sim (where it should instead be returning true). Presumably this just is a temporary bug in 18 beta?

Hi, I am working on a case in our organisation where hundreds if not a thousand wireless network clients are affected by regular, usually 30 sometimes 60 minute sometime they are unnoticeable but often people having meetings notice that a lot. We excluded wireless network configuration issue since disconnections happens to clients both connected to Cisco and Ubiquiti Access Points. WLC logs mostly show EAP timeout errors - clients are getting disauthenticated and authenticated back - usually without any action needed - but the meeting is being interrupted. What I found in Macbook logs with sudo log show [options] is the main reason of network disconnection: 2025-02-04 14:16:31.219192+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine updateTimeSincePreviousTriggerForStudy:msgKey:dictKey:]::913:msgkey:WFAAWDWASDS_symptomsDnsTimeSincePreviousTriggerMinutes dictKey:dps_lastSymptomsDpsTrigger previous_TS:(null) current_TS:Tue Feb 4 14:16:31 2025 difference:0 2025-02-04 14:16:31.219704+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine updateScreenState]::198:DPS Fast Reset Recommendation Engine: (screenON & foreGrnd traffic) is DETECTED 2025-02-04 14:16:31.219713+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine recommendSymptomsDpsRecovery:symptomsDnsStats:awdlState:currentSymptomsCondition:isLANPingSuccessful:appUsage:averageCCA:]::966:PeerDiagnostics: Data not received from peerDiagnostics 2025-02-04 14:16:31.219714+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine checkForPriorityNetwork]::256:Priority Network Check Disabled: NO IsPriorityNetwork: YES 2025-02-04 14:16:31.219732+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine isResetAllowedForKey:forPrefSelector:]::330:key:symptomsDps_lastScreenOnRecoveryWD previousWD_TS:(null) currentWD_TS:Tue Feb 4 14:16:31 2025 recommendation:YES 2025-02-04 14:16:31.219735+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine updateSymptomsDPSRecoveryWDStatsForKey:]::210:Added key: symptomsDps_numRecommendedScreenOnRecoveryWD value:1 dict:(null) 2025-02-04 14:16:31.219737+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine recommendSymptomsDpsRecovery:symptomsDnsStats:awdlState:currentSymptomsCondition:isLANPingSuccessful:appUsage:averageCCA:]::1023:PeerDiagnostics: Recommendation for DNS Symptoms Recovery: Reassoc Do you guys have any idea where can I see that DNS symptoms? I can also see some reading like: 2025-02-04 14:16:31.219169+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[WAEngine gatherConsecutiveDatapathReadings:forProcessToken:andReply:]_block_invoke::4235:DNS Symptoms pre-decision check:: Associated:YES Primary:YES isCaptive:NO isValidDnsConfig:YES 2025-02-04 14:16:31.219169+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[WAEngine gatherConsecutiveDatapathReadings:forProcessToken:andReply:]_block_invoke::4238:SDNS: WiFi Not Primary - setting suppressedReason kSymptomsDnsWiFiInterfaceNotPrimary WiFi Not Primary - how if this is my only interface? - I removed all other Killing and disabling wifianalyticsd does not help - the process is being spawned by launchd on airportd request: 2025-02-04 08:54:11.903825+0100 0xb85274 Default 0x0 627 0 airportd: (WiFiAnalytics) [com.apple.wifi.analytics:Default] -[WAClient _establishDaemonConnection]_block_invoke::1057:XPC: establishing connection to daemon with token ending in: <private>... 2025-02-04 08:54:11.907779+0100 0xb8504a Default 0x0 627 0 airportd: (IO80211) [com.apple.WiFiManager:] Info: <airport[627]> -[dpsManager submitDpsSymptom:isCriticalApp:]_block_invoke: 2025-02-04 08:54:11.907943+0100 0xb8504a Default 0x0 627 0 airportd: (IO80211) -[dpsManager submitDpsSymptom:isCriticalApp:]_block_invoke: Error preparing DPSNotification for submission: Error Domain=com.apple.wifi.analytics.errordomain Code=9014 "WAErrorCodeDaemonContactTimeout" UserInfo={NSLocalizedFailureReason=WAErrorCodeDaemonContactTimeout}, or null WAMessageAWD 2025-02-04 08:54:11.908055+0100 0xb8504a Default 0x0 627 0 airportd: (IO80211) [com.apple.WiFiManager:] <airport[627]> -[dpsManager submitDpsSymptom:isCriticalApp:]_block_invoke: Error preparing DPSNotification for submission: Error Domain=com.apple.wifi.analytics.errordomain Code=9014 "WAErrorCodeDaemonContactTimeout" UserInfo={NSLocalizedFailureReason=WAErrorCodeDaemonContactTimeout}, or null WAMessageAWD 2025-02-04 08:54:11.910453+0100 0xb85274 Default 0x0 627 0 airportd: (libxpc.dylib) [com.apple.xpc:connection] [0x80fe64640] activating connection: mach=true listener=false peer=false name=com.apple.wifianalyticsd 2025-02-04 08:54:11.911105+0100 0xb85382 Default 0x0 1 0 launchd: [system/com.apple.wifianalyticsd:] internal event: WILL_SPAWN, code = 0 2025-02-04 08:54:11.911229+0100 0xb85382 Default 0x0 1 0 launchd: [system/com.apple.wifianalyticsd:] service state: spawn scheduled 2025-02-04 08:54:11.911233+0100 0xb85382 Default 0x0 1 0 launchd: [system/com.apple.wifianalyticsd:] service state: spawning 2025-02-04 08:54:11.911384+0100 0xb85382 Default 0x0 1 0 launchd: [system/com.apple.wifianalyticsd:] launching: ipc (mach) 2025-02-04 08:54:11.920272+0100 0xb85382 Default 0x0 1 0 launchd: [system/com.apple.wifianalyticsd [86459]:] xpcproxy spawned with pid 86459 Do you guys have any idea what is the cause of this behaviour? Or how to disable wifianalyticsd process for good?

I am writing to seek clarification on two technical issues related to iOS frameworks (CoreBluetooth and NetworkExtension). These observations are critical for optimizing our app's performance, and I would appreciate any official guidance or documentation references. CoreBluetooth Scanning Frequency and Cycle Issue: We noticed inconsistent BLE device discovery times (ranging from 0.5s to 1.5s) despite the peripheral advertising at 2Hz (500ms interval). Questions: Does iOS regulate the BLE scan interval or duty cycle internally? If yes, what factors affect this behavior (e.g., foreground/background state, connected devices)? Are there recommended practices to reduce discovery latency for peripherals with fixed advertising intervals? Is there a way to configure scan parameters (e.g., scan window/interval) programmatically, similar to Android's BluetoothLeScanner? Test Context: Device: iPhone 13 mini (iOS 17.6.1) Code: CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) NEHotspotConfigurationManager Workflow and Latency Issue: Using NEHotspotConfigurationManager.shared.apply(_:) to connect to Wi-Fi occasionally takes up to 8 seconds to complete. Questions: What is the internal workflow of the apply method? Does it include user permission checks, SSID scanning, authentication, or IP assignment steps? Are there known scenarios where this method would block for extended periods (e.g., waiting for user interaction, network timeouts)? Is the latency related to system-level retries or radio coexistence with other wireless activities (e.g., Bluetooth)? Test Context: Configuration: NEHotspotConfiguration(ssid: "TestSSID") Behavior: Delay occurs even when the Wi-Fi network is in range and credentials are correct.