Hi, I've encountered a strange behavior in the DNS Proxy Provider extension. Our app implements both DNS Proxy Provider and Content Filter Providers extensions, configured via MDM. When the app is uninstalled, the behavior of the providers differs: For Content Filter Providers (both Filter Control and Filter Data Providers), the providers stop as expected with the stop reason: /** @const NEProviderStopReasonProviderDisabled The provider was disabled. */ case providerDisabled = 5 However, for the DNS Proxy Provider, the provider remains in the "Running" state, even though there is no app available to match the provider's bundle ID in the uploaded configuration profile. When the app is reinstalled: The Content Filter Providers start as expected. The DNS Proxy Provider stops with the stop reason: /** @const NEProviderStopReasonAppUpdate The NEProvider is being updated */ @available(iOS 13.0, *) case appUpdate = 16 At this point, the DNS Proxy Provider remains in an 'Invalid' state. Reinstalling the app a second time seems to resolve the issue, with both the DNS Proxy Provider and Content Filter Providers starting as expected. This issue seems to occur only if some time has passed after the DNS Proxy Provider entered the 'Running' state. It appears as though the system retains a stale configuration for the DNS Proxy Provider, even after the app has been removed. Steps to reproduce: Install the app and configure both DNS Proxy Provider and Content Filter Providers using MDM. Uninstall the app. Content Filter Providers are stopped as expected (NEProviderStopReason.providerDisabled = 5). DNS Proxy Provider remains in the 'Running' state. Reinstall the app. Content Filter Providers start as expected. DNS Proxy Provider stops with NEProviderStopReason.appUpdate (16) and remains 'Invalid'. Reinstall the app again. DNS Proxy Provider now starts as expected. This behavior raises concerns about how the system manages the lifecycle of DNS Proxy Provider, because DNS Proxy Provider is matched with provider bundle id in .mobileconfig file. Has anyone else experienced this issue? Any suggestions on how to address or debug this behavior would be highly appreciated. Thank you!

send a request and it returns with timeout Integration Team are Using Fortigate as a firewall and NGINX for some reasons so we use VPN TO Access , requests always succeed but at once it failed with timeout in randomize request not specific one we are using URLSession as a network layer when I retry the same failed request again, it success the request cannot connect apigee Sec Team concern { app session hits the security gateway with lots of SYN step to try to initiate a new session and doesn’t wait for (SYN-ACK / ACK) steps to happen to make sure the connection initiated correctly and gateway consider it flooding attack }

I'm developing a per-app VPN iOS app with Wireguard. For that, I created a configuration file with payload type "com.apple.vpn.managed.applayer". Using the MDM server I installed some apps which need to use the VPN connection. But when I open these apps, I could see the VPN getting enabled in the device. The VPN icon appears on the notification bar but no internet connection. The VPN and internet is working correctly if I change the payload type to "com.apple.vpn.managed" in configuration file.

I've implemented a custom system extension VPN for macOS using Packet Tunnel Provider. The VPN is configured with on-demand, and a rule to always connect whenever there's traffic: onDemandRules = [NEOnDemandRuleConnect()] As expected, if the VPN isn't active, all traffic gets blocked until it is ready. Not expected: In the following scenario, there is some 'traffic leak': Use only WiFi (not wired cable) Connect the VPN Disable the WiFi and wait for the VPN to disconnect Enable the WiFi Some packets are routed outside the VPN, and aren't being blocked Some moments after, all traffic will be blocked, and the VPN will start the 'connecting' process. Is the above scenario a 'known' issue? Can it be a race condition in the OS, where some packets can be sent after the network is brought back before the VPN process starts? Is there any way to fix this problem? P.S: I'm not using flags such as 'capture all network'

While updating our test devices to iOS 26, we noticed that the connection between devices are flaky. Often when connecting to a Peer from a device running iOS 26 we can observe the invite coming through and when accepting said invite, both ends going to .connecting state and a while later going back to .notConnected within the peer(_ peerID: MCPeerID, didChange state: MCSessionState) function. This happens regularly and retrying the invitation process several times usually resolves it. Do anyone have any information or guidance on how to resolve this issue?

On macOS Tahoe26.0, iOS 26.0 (23A5287g), Xcode 26.0 beta 3 (17A5276g) 1、Follow this tutorial Downloading asset packs hosted by Apple When i download a background asset packs hosted by Apple, Xcode callback "Download failed: The helper received an invalid server response with the status code “400”." Before downloading, I uploaded the three aar files to the Apple server using the Transporter app. Three Manifest.json content is： {"assetPackID":"bdassets2","downloadPolicy":{"onDemand":{}},"fileSelectors":[{"file":"1.jpg"},{"file":"2.pag"},{"file":"3.mp4"}],"platforms":["iOS"]} and {"assetPackID":"bdassets1","downloadPolicy":{"prefetch":{"installationEventTypes":["firstInstallation","subsequentUpdate"]}},"fileSelectors":[{"file":"1.jpg"},{"file":"2.pag"},{"file":"3.mp4"},{"directory":"a1"}],"platforms":["iOS"]} and {"assetPackID":"bdassets0","downloadPolicy":{"essential":{"installationEventTypes":["firstInstallation","subsequentUpdate"]}},"fileSelectors":[{"file":"1.jpg"},{"file":"2.pag"},{"file":"3.mp4"},{"directory":"a1"}],"platforms":["iOS"]} The same error was reported when the three aar files were obtained. I obtained it using the following code: do {       let assetPack = try await AssetPackManager.shared.assetPack(withID: "bdassets2")       try await AssetPackManager.shared.ensureLocalAvailability(of: assetPack)     } catch {       print("Download failed:", error)     } 2、Follow this tutorial Testing your asset packs locally I use this command line to start the test server：xcrun ba-serve --host 172.17.9.62 bdassets2.aar, The content displayed on the terminal is： Loading asset packs… Loading the asset pack at “bdassets2.aar”… Choose an identity in the panel to continue. Listening on port 56061… When running the project, Xcode reports an error:Download failed: Could not connect to the server. I use iPhone directly visit this website: https://172.17.9.62:56061, on the page display "Hello, world!" There are too few error messages in both of the above questions. I have no idea what the specific reasons are.I hope someone can offer some guidance. Best Regards.

We have an iPad application that utilizes Multipeer Connectivity to enable local communication between devices running a copy of our app. Until recently, we were able to test this functionality in the Xcode simulator without any issues. We could easily set up multiple simulators and have them all communicate with each other. However, recently, either due to an upgrade to Xcode or MacOS, this functionality ceased working in the simulator. Surprisingly, it still functions perfectly on physical devices. If we reboot the development computer and launch the simulator immediately after the reboot (without building and sending from Xcode, but running the existing code on the device), the issue resolves. However, the moment we generate a new build and send it to the simulator from Xcode, the multipeer functionality stops working again in the simulator. The simulators won’t reconnect until a reboot of the physical Mac hardware hosting the simulator. We’ve tried the usual troubleshooting steps, such as downgrading Xcode, deleting simulators and recreating them, cleaning the build folder, and deleting derived data, but unfortunately, none of these solutions have worked. The next step is to attempt to use a previous version of MacOS (15.3) and see if that helps, but I’d prefer to avoid this if possible. Does anyone have any obvious suggestions or troubleshooting steps that might help us identify the cause of this issue?

Hi! My project has the Local Push Connectivity entitlement for a feature we have requiring us to send low-latency critical notifications over a local, private Wi-Fi network. We have our NEAppPushProvider creating a SSE connection using the Network framework with our hardware running a server. The server sends a keep-alive message every second. On an iPhone 16 with iOS 18+, the connection is reliable and remains stable for hours, regardless of whether the iOS app is in the foreground, background, or killed. One of our QA engineers has been testing on an iPhone 13 running iOS 16, and has notice shortly after locking the phone, specifically when not connected to power the device seems to turn off the Wi-Fi radio. So when the server sends a notification, it is not received. About 30s later, it seems to be back on. This happens on regular intervals. When looking at our log data, the provider does seem to be getting stopped, then restarted shortly after. The reason code is NEProviderStopReasonNoNetworkAvailable, which further validates that the network is getting dropped by the device in regular intervals. My questions are: Were there possibly silent changes to the framework between iOS versions that could be the reason we're seeing inconsistent behavior? Is there a connection type we could use, instead of SSE, that would prevent the device from disconnecting and reconnecting to the Wi-Fi network? Is there an alternative approach to allow us to maintain a persistent network connection with the extension or app?

Goal : Block all outbound connections to a static list of hosts (both In-app requests and WKWebView/Safari). App & both extensions have Network Extension entitlement with content-filter-provider and filter-control-provider What’s working: Safari and WKWebView requests matching the block list are dropped. What’s broken: In-app traffic never reaches the Data Provider—those requests always succeed. Setup: • NEFilterProviderConfiguration with both Data & Control providers, filterBrowsers = true, filterSockets = true • Data Provider implements handleNewFlow for socket/browser flows • Control Provider implements handleNewFlow for browser flows • Enabled via saveToPreferences() and toggled ON in Settings

Hi,I am trying to create an NAT64 Network with Sharing options to test my Apps.I did follow the guide provided here https://forums.developer.apple.com/thread/14213But even with the option key pressed the "Create NAT64 Network" check box is still missing.I am using a OS X 10.11Any ideas?!

I did watch WWDC 2019 Session 716 and understand that an active audio session is key to unlocking low‑level networking on watchOS. I’m configuring my audio session and engine as follows: private func configureAudioSession(completion: @escaping (Bool) -> Void) { let audioSession = AVAudioSession.sharedInstance() do { try audioSession.setCategory(.playAndRecord, mode: .voiceChat, options: []) try audioSession.setActive(true, options: .notifyOthersOnDeactivation) // Retrieve sample rate and configure the audio format. let sampleRate = audioSession.sampleRate print("Active hardware sample rate: \(sampleRate)") audioFormat = AVAudioFormat(standardFormatWithSampleRate: sampleRate, channels: 1) // Configure the audio engine. audioInputNode = audioEngine.inputNode audioEngine.attach(audioPlayerNode) audioEngine.connect(audioPlayerNode, to: audioEngine.mainMixerNode, format: audioFormat) try audioEngine.start() completion(true) } catch { print("Error configuring audio session: \(error.localizedDescription)") completion(false) } } private func setupUDPConnection() { let parameters = NWParameters.udp parameters.includePeerToPeer = true connection = NWConnection(host: "***.***.xxxxx.***", port: 0000, using: parameters) setupNWConnectionHandlers() } private func setupTCPConnection() { let parameters = NWParameters.tcp connection = NWConnection(host: "***.***.xxxxx.***", port: 0000, using: parameters) setupNWConnectionHandlers() } private func setupWebSocketConnection() { guard let url = URL(string: "ws://***.***.xxxxx.***:0000") else { print("Invalid WebSocket URL") return } let session = URLSession(configuration: .default) webSocketTask = session.webSocketTask(with: url) webSocketTask?.resume() print("WebSocket connection initiated") sendAudioToServer() receiveDataFromServer() sendWebSocketPing(after: 0.6) } private func setupNWConnectionHandlers() { connection?.stateUpdateHandler = { [weak self] state in DispatchQueue.main.async { switch state { case .ready: print("Connected (NWConnection)") self?.isConnected = true self?.failToConnect = false self?.receiveDataFromServer() self?.sendAudioToServer() case .waiting(let error), .failed(let error): print("Connection error: \(error.localizedDescription)") DispatchQueue.main.asyncAfter(deadline: .now() + 2) { self?.setupNetwork() } case .cancelled: print("NWConnection cancelled") self?.isConnected = false default: break } } } connection?.start(queue: .main) } I am reaching out to seek further assistance regarding the challenges I've been experiencing with establishing a UDP, TCP & web socket connection on watchOS using NWConnection for duplex audio streaming. Despite implementing the recommendations provided earlier, I am still encountering difficulties. Or duplex audio streaming not possible on apple watch?

Hi, I’m trying out my app with Xcode 26, running on an iOS 26 simulator. I'm having issues with URLSessions, it crashes when I set the URLSessionConfiguration to default, and if I don’t use the URLSessionConfiguration, it crashes if I use URLSession.shared. When running in a real device, it doesn't crash, but any network request will hang and time out after a while. Is it a known issue in the latest beta versions?

When handleNewUDPFlow in NETransparentProxyProvider is used to handle UDP data from port 53, at the same time, run the script continuously to execute nslookup or dig, about tens of thousands of times later, the nslookup shows the error "isc_socket_bind: address not available". So I check the system port status, and find all of the ports from 49152 to 65535 are occupied. The number of net.inet.udp.pcbcount is also very high. net.inet.udp.pcbcount: 91433 Then I made the following attempts: handleNewUDPFlow function return false directly, the nslookup script runs with no problems. I write a simple network extension that use handleNewUDPFlow to reply the mock data directly, and only hijack the UDP data from my test program (HelloWorld-5555). My network exntension code: override func handleNewUDPFlow(_ flow: NEAppProxyUDPFlow, initialRemoteEndpoint remoteEndpoint: NWEndpoint) -> Bool { guard let tokenData = flow.metaData.sourceAppAuditToken, tokenData.count == MemoryLayout<audit_token_t>.size else { return false } let audit_token = tokenData.withUnsafeBytes { buf in buf.baseAddress?.assumingMemoryBound(to: audit_token_t.self).pointee } let pid = audit_token_to_pid(audit_token ?? audit_token_t()) if (!flow.metaData.sourceAppSigningIdentifier.starts(with: "HelloWorld-5555")) { return false } Logger.statistics.log("handleNewUDPFlow \(remoteEndpoint.debugDescription, privacy: .public) \(flow.hash), pid:\(pid), \(flow.metaData.sourceAppSigningIdentifier, privacy: .public)") flow.open(withLocalEndpoint: nil) { error in if let error { os_log("flow open error: %@", error.localizedDescription) return } flow.readDatagrams { data_grams, remote_endpoints, read_err in guard let read_data_grams = data_grams, let read_endpoints = remote_endpoints, read_err == nil else { os_log("readDatagrams failed") flow.closeReadWithError(nil) flow.closeWriteWithError(nil) return } let mockData = Data([0x01,0x02,0x03]) let datagrams = [ mockData ] guard let remoteEnd = remoteEndpoint as? NWHostEndpoint else { os_log("Not the NWHostENdpoint") flow.closeReadWithError(nil) flow.closeWriteWithError(nil) return } let endpoints = [ NWHostEndpoint(hostname: remoteEnd.hostname, port: remoteEnd.port) ] flow.writeDatagrams(datagrams, sentBy: endpoints) { error in if let error { os_log("writeDatagrams error: %@", error.localizedDescription) } os_log("writeDatagrams close") flow.closeReadWithError(nil) flow.closeWriteWithError(nil) } } } return true } My test program code: void send_udp() { int sockfd; struct sockaddr_in server_addr; char buffer[BUFFER_SIZE]; int bytes_sent; // create socket if ((sockfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { perror("socket create failed"); exit(EXIT_FAILURE); } struct sockaddr_in local_addr; memset(&local_addr, 0, sizeof(local_addr)); local_addr.sin_family = AF_INET; local_addr.sin_addr.s_addr = htonl(INADDR_ANY); local_addr.sin_port = htonl(0); // bind if (bind(sockfd, (struct sockaddr*)&local_addr, sizeof(local_addr)) < 0) { printf("IPV4 bind errno:%d\n", errno); close(sockfd); return; } // server addr memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_port = htons(SERVER_PORT); server_addr.sin_addr.s_addr = inet_addr(SERVER_IP); // send & recv strcpy(buffer, "Hello, UDP server!"); bytes_sent = sendto(sockfd, buffer, strlen(buffer), 0, (struct sockaddr *)&server_addr, sizeof(server_addr)); if (bytes_sent < 0) { perror("sendto failed"); close(sockfd); exit(EXIT_FAILURE); } printf("sendto ok\n"); char recvbuf[128] = {0}; socklen_t len = sizeof(server_addr); int sz = recvfrom(sockfd, recvbuf, sizeof(recvbuf), MSG_WAITALL, (struct sockaddr *) &server_addr, &len); printf("recv sz: %d\n", sz); close(sockfd); return; } int main() { send_udp(); return 0; } 2.1 When I use bind in my program, after the program running tens of thousands of times, the ports are exhausted, and nslookup return the error "isc_socket_bind: address not available". The case looks like running the nslookup script, because the nslookup will call the bind. 2.2 When I remove the bind from my program, all the tests are go. I have made the above experiments on different systems: 13.x, 14.x, 15.x, and read the kernel source code about bind and port assignment, bsd/netinet/in_pcb.c bsd/netinet/udp_usrreq.c and find kernel will do different action for network extension by call necp_socket_should_use_flow_divert I have checked my network extension process by lsof and netstat, its sockets or flows are all closed properly. I don't know how I can avoid this problem to ensure my network extension to work long time properly. Apparently, the port exhaustion is related to the use of bind function and network extension. I doubt there is a port leak problem in system when use network extension. Hope for your help.

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! :)

Hi, Our project is a MacOS SwiftUI GUI application that bundles a System Network Extension, signed with a Developer ID certificate for distribution outside of the app store. The system network extension is used to write a packet tunnel provider. The signing of the app & network extension is handled by XCode (v16.0.0), we do not run codesign ourselves. We have no issues with XPC or the system network extension during normal usage, nor when the application is installed on a user's device for the first time. The problem only arises when the user upgrades the application. I have experienced this issue myself, as have our users. It's been reported on Apple Silicon macbooks running at least macOS 15.3.2. Much like the SimpleFirewall example (which we used as a reference), we use XPC for basic communication of state between the app and NE. These XPC connections stop working when the user installs a new version of the app, with OS logs from the process indicating that the connection is immediately invalidated. Subsequent connection attempts are also immediately invalidated. Toggling the VPN in system settings (or via the app) does not resolve the problem, nor does restarting the app, nor does deleting and reinstalling the app, nor does restarting the device. The only reliable workaround is to delete the system extension in Login Items & Extensions, under Network Extensions. No device restart is necessary to garbage collect the old extension - once the extension is reapproved by the user, the XPC issue resolves itself. This would be an acceptable workaround were it possible to automate the deleting of the system extension, but that appears deliberately not possible, and requiring our users to do this each time they update is unreasonable. When the upgraded app is opened for the first time, the OSSystemExtensionRequest request is sent, and the outcome is that the previously installed system network extension is replaced, as both the CFBundleVersion and CFBundleShortVersionString differ. When this issue is encountered, the output of systemextensionsctl list shows the later version is installed and activated. I've been able to reproduce this bug on my personal laptop, with SIP on and systemextensionsctl developer off, but on my work laptop with SIP off and systemextensionsctl developer on (where the network extension is replaced on each activation request, instead of only when the version strings differ), I do not encounter this issue, which leads me to believe it has something to do with the notarization process. We notarize the pkg using xcrun notarytool, and then staple to the pkg. This is actually the same issue described in: https://developer.apple.com/forums/thread/711713 https://developer.apple.com/forums/thread/667597 https://developer.apple.com/forums/thread/742992 https://developer.apple.com/forums/thread/728063 but it's been a while since any of these threads were updated, and we've made attempts to address it off the suggestions in the threads to no avail. Those suggestions are: Switching to a .pkg installer from a .dmg As part of the .pkg preinstall, doing all of the following: Stopping the VPN (scutil --nc stop), shutting down the app (using osascript 'quit app id'), and deleting the app (which claims to delete the network extension, but not the approval in Login Items & Extensions remains??), by running rm -rf on the bundle in /Applications As part of the .pkg postinstall: Forcing macOS to ingest the App bundle's notarization ticket using spctl --assess. Ensuring NSXPCListener.resume() is called after autoreleasepool { NEProvider.startSystemExtensionMode() } (mentioned in a forum thread above as a fix, did not help.) One thing I'm particularly interested in is the outcome of this feedback assistant ticket, as I can't view it: FB11086599. It was shared on this forum in the first thread above, and supposedly describes the same issue. I almost find it hard to believe that this issue has been around for this many years without a workaround (there's system network extension apps out there that appear to work fine when updating, are they not using XPC?), so I wonder if there's a fix described in that FB ticket. Since I can't view that above feedback ticket, I've created my own: FB17032197

I am looking for inputs to better understand MacOS entitlements. I ask this in context of OpenJDK project, which builds and ships the JDK. The build process makes uses of make tool and thus doesn't involving building through the XCode product. The JDK itself is a Java language platform providing applications a set of standard APIs. The implementation of these standard APIs internally involves calling platform specific native library functions. In this discussion, I would like to focus on the networking functions that the implementation uses. Almost all of these networking functions and syscalls that the internal implementation uses are BSD socket related. Imagine calls to socket(), connect(), getsockopt(), setsockopt(), getaddrinfo(), sendto(), listen(), accept() and several such. The JDK that's built through make is then packaged and made available for installation. The packaging itself varies, but for this discussion, I'll focus on the .tar.gz archived packaging. Within this archive there are several executables (for example: java, javac and others) and several libraries. My understanding, based on what I have read of MacOS entitlements is that, the entitlements are set on the executable and any libraries that would be loaded and used by that executable will be evaluated against the entitlements of the executable (please correct me if I misunderstand). Reading through the list of entitlements noted here https://developer.apple.com/documentation/bundleresources/entitlements, the relevant entitlements that an executable (like "java") which internally invokes BSD socket related syscalls and library functions, appear to be: com.apple.security.network.client - https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.network.client com.apple.security.network.server - https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.network.server com.apple.developer.networking.multicast - https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.networking.multicast Is my understanding correct that these are the relevant ones for MacOS? Are there any more entitlements that are of interest? Would it then mean that the executables (java for example) would have to enroll for these entitlements to be allowed to invoke those functions at runtime? Reading through https://developer.apple.com/documentation/bundleresources/entitlements, I believe that even when an executable is configured with these entitlements, when the application is running if that executable makes use of any operations for which it has an entitlement, the user is still prompted (through a UI notification) whether or not to allow the operation. Did I understand it right? The part that isn't clear from that documentation is, if the executable hasn't been configured with a relevant entitlement, what happens when the executable invokes on such operation. Will the user see a UI notification asking permission to allow the operation (just like if an entitlement was configured)? Or does that operation just fail in some behind the scenes way? Coming back to the networking specific entitlements, I found a couple of places in the MacOS documentation where it is claimed that the com.apple.developer.networking.multicast entitlement is only applicable on iOS. In fact, the entitlement definition page for it https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.networking.multicast says: "Your app must have this entitlement to send or receive IP multicast or broadcast on iOS. It also allows your app to browse and advertise arbitrary Bonjour service types." Yet, that same page, a few lines above, shows "macOS 10.0+". So, is com.apple.developer.networking.multicast entitlement necessary for an executable running on MacOS which deals with multicasting using BSD sockets? As a more general comment about the documentation, I see that the main entitlements page here https://developer.apple.com/documentation/bundleresources/entitlements categorizes some of these entitlements under specific categories, for example, notice how some entitlements are categorized under "App Clips". I think it would be useful if there was a category for "BSD sockets" and under that it would list all relevant entitlements that are applicable, even if it means repeating the entitlement names across different categories. I think that will make it easier to identify the relevant entitlements. Finally, more as a long term question, how does one watch or keep track of these required entitlements for these operations. What I mean is, is it expected that application developers keep visiting the macos documentation, like these pages, to know that a new entitlement is now required in a new macos (update) release? Or are there other ways to keep track of it? For example, if a newer macos requires a new entitlement, then when (an already built) executable is run on that version of macos, perhaps generate a notification or some kind of explicit error which makes it clear what entitlement is missing? I have read through https://developer.apple.com/documentation/bundleresources/diagnosing-issues-with-entitlements but that page focuses on identifying such issues when a executable is being built and doesn't explain the case where an executable has already been shipped with X entitlements and a new Y entitlement is now required to run on a newer version of macos.

when i set the flag false to the usesClassicLoadingMode, then the application is getting crashed Ex: let config = URLSessionConfiguration.default if #available(iOS 18.4, *) { config.usesClassicLoadingMode = false } Crash log : *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFBoolean objectForKeyedSubscript:]: unrecognized selector sent to instance 0x1f655c390' *** First throw call stack: (0x188ae52ec 0x185f69a7c 0x188b4f67c 0x1889fcb84 0x1889fc4f0 0x191393bc8 0x1889ec8a0 0x1889ec6e4 0x191393ad0 0x191344dac 0x191344b58 0x107cfa064 0x107ce36d0 0x191343fcc 0x1891b3b18 0x1892dae58 0x189235c60 0x18921e270 0x18921d77c 0x18921a8ac 0x107ce0584 0x107cfa064 0x107ce891c 0x107ce95d8 0x107ceabcc 0x107cf5894 0x107cf4eb0 0x212f51660 0x212f4e9f8) terminating due to uncaught exception of type NSException

I don't understand what permissions need to be given for this code to operate. I cannot seem to work out why I'm not able to see a BSSID. I think I've given sandbox the appropriate permissions AND I've added some to the Target Properties for good measure. Yet, cannot get BSSID. import SwiftUI import CoreWLAN import CoreLocation struct ContentView: View { @State private var currentBSSID: String = "Loading..." var body: some View { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Current BSSID:") Text(currentBSSID) } .padding() .onAppear(perform: fetchBSSID) } func fetchBSSID() { if let iface2 = CWWiFiClient.shared().interface() { print("✅ Found Wi-Fi interface: \(iface2.interfaceName ?? "nil")") } else { print("❌ No Wi-Fi interface found") } if let iface = CWWiFiClient.shared().interface(), let bssid = iface.bssid() { currentBSSID = bssid } else { currentBSSID = "Not connected" print("✅ BSSID: \(currentBSSID)") } } } #Preview { ContentView() } Output - WifI interface is found but BSSID is not found.

Did iOS 18.4 ( and 18.5) with iPhone 14 or 15 introduce new network connectivity or battery optimization policies that would break Local Push Connectivity? (suspend PushProvider in a new way that prevents it from listening and reponding to incoming messages from private network server)? We have a private app using local push connectivity for real time local alerts on a local private network & server. The current application version works on prev devices including iPhone 12, iOS 14-18.1 that we know of. A new(er) installation with iPhone 14s & 15s on iOS 18.4 is having new connectivity problems that seem to occur along with sleep. Previously NEAppPushProvider could listen and reply to incoming messages from server for local notifications, incoming sip invites, and connection health messages. We'll be performing addtional testing to narrow the issue in the meantime, but it would be VERY helpful to have clarification regarding any iOS minor patches since 18.1 that are now breaking existing Local Push Connectivity applications. If so what are the recommendations or remedies. Are known issues with Network Extensions patched in 18.5? Are existing applications expected to redesign their networking solutions for 18.3 & 18.4? Did iOS18 versions later than 18.1 begin requiring new entitlements or exceptions for private apps in app store?

Hello, I'm trying to get a list of all network devices (device audit for DLP system). CFMutableDictionaryRef matchingDictionary = IOServiceMatching(kIONetworkControllerClass); if (matchingDictionary == nullptr) { std::cerr << "IOServiceMatching() returned empty matching dictionary" << std::endl; return 1; } io_iterator_t iter; if (kern_return_t kr = IOServiceGetMatchingServices(kIOMasterPortDefault, matchingDictionary, &iter); kr != KERN_SUCCESS) { std::cerr << "IOServiceGetMatchingServices() failed" << std::endl; return 1; } io_service_t networkController; while ((networkController = IOIteratorNext(iter)) != IO_OBJECT_NULL) { std::cout << "network device: "; if (CFDataRef cfIOMACAddress = (CFDataRef) IORegistryEntryCreateCFProperty(networkController, CFSTR(kIOMACAddress), kCFAllocatorDefault, kNilOptions); cfIOMACAddress != nullptr) { std::vector<uint8_t> data(CFDataGetLength(cfIOMACAddress)); CFDataGetBytes(cfIOMACAddress, CFRangeMake(0, data.size()), data.data()); std::cout << std::hex << std::setfill('0') << std::setw(2) << (short)data[0] << ":" << std::hex << std::setfill('0') << std::setw(2) << (short) data[1] << ":" << std::hex << std::setfill('0') << std::setw(2) << (short) data[2] << ":" << std::hex << std::setfill('0') << std::setw(2) << (short) data[3] << ":" << std::hex << std::setfill('0') << std::setw(2) << (short) data[4] << ":" << std::hex << std::setfill('0') << std::setw(2) << (short) data[5]; CFRelease(cfIOMACAddress); } std::cout << std::endl; IOObjectRelease(networkController); } IOObjectRelease(iter); The Wi-Fi controller shows up in I/O Registry Explorer, but IOServiceGetMatchingServices() does not return any information about it. Any way to retrieve Wi-Fi controller info in daemon code? Thank you in advance!