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

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

We're encountering an issue with our Network Extension (utilizing NEPacketTunnelProvider and NETransparentProxy) on macOS 14.5 (23F79). On some systems, the VPN fails to automatically start after a reboot despite calling startVPNTunnel(). There are no error messages. Our code attempts to start the tunnel: ....... do { try manager.connection.startVPNTunnel() Logger.default("Started tunnel successfully") } catch { Logger.error("Failed to launch tunnel") } ...... System log analysis reveals the tunnel stopping due to userLogout (NEProviderStopReason(rawValue: 12)) during reboot. However, the Transparent Proxy stops due to userInitiated (NEProviderStopReason(rawValue: 1)) for the same reboot. We need to understand: Why the VPNTunnel isn't starting automatically. Why the userLogout reason is triggered during reboot. Additional Context: We have manually started the VPN from System Settings before reboot.

Our app server is having some TLS related issue with the new iOS 26 (It works with iOS 18 and below). When opening the domain url in iPhone Safari browser with iOS 26, it showing the error as below: We followed the instructions from this link (https://support.apple.com/en-sg/122756), to run the following command: nscurl --tls-diagnostics https://test.example in Terminal app. It shows TLS failed with error: -9808 Could anyone please help explain what exactly the issue is with our server certificate, and how we should fix it? Thanks so much!

Hi everyone, I’m encountering what appears to be a system-level issue with NEAppPushProvider extensions being unable to communicate with other devices on the local network, even when the main app has already been granted Local Network permission by the user. Context The following problem occurs in an iPad app running iOS 18.5. The main app successfully requests and is granted Local Network access via NSLocalNetworkUsageDescription in its Info.plist configuration. It can connect to a WebSocket server hosted on the local network without any issues, resolving its address by name. The extension (NEAppPushProvider) uses the same networking code as the app, extended via target membership of a controller class. It attempts to connect to the same hostname and port but consistently fails to establish a connection. The system log shows it properly resolving DNS but being stopped due to "local network prohibited". An extract of the logs from the Unified Logging System: 12:34:10.086064+0200 PushProvider [C526 Hostname#fd7b1452:8443 initial parent-flow ((null))] event: path:start @0.000s 12:34:10.087363+0200 PushProvider [C526 Hostname#fd7b1452:8443 waiting parent-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: path:satisfied @0.005s 12:34:10.090074+0200 PushProvider [C526 Hostname#fd7b1452:8443 in_progress parent-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: flow:start_connect @0.006s 12:34:10.093190+0200 PushProvider [C526.1 Hostname#fd7b1452:8443 in_progress resolver (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: resolver:start_dns @0.009s 12:34:10.094403+0200 PushProvider [C526.1.1 IPv4#f261a0dc:8443 waiting path (unsatisfied (Local network prohibited), interface: en0[802.11], ipv4, uses wifi)] event: path:unsatisfied @0.010s 12:34:10.098370+0200 PushProvider [C526.1.1.1 IPv4#f261a0dc:8443 failed path (unsatisfied (Local network prohibited), interface: en0[802.11], ipv4, uses wifi)] event: null:null @0.014s 12:34:10.098716+0200 PushProvider [C526.1 Hostname#fd7b1452:8443 failed resolver (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: resolver:children_failed @0.015s 12:34:10.099297+0200 PushProvider [C526 Hostname#fd7b1452:8443 waiting parent-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: flow:child_failed @0.016s What I’ve Confirmed: The extension works perfectly if the DNS is changed to resolve the name to a public IP instead of a local one. The extension always connects by hostname. Devices on the local network can resolve each other’s IP addresses correctly and respond to pings. What I’ve Tried Adding NSLocalNetworkUsageDescription to the main app’s Info.plist, as recommended. Clean building the project again. Removing and reinstalling the app to ensure permission prompts are triggered fresh. Restarting the iPad. Ensuring main app cannot access the local network until the permission is granted. Ensuring the main app has connected to the same hostname and port before the extension attempts a connection Toggling the permission manually in Settings. Apple’s documentation states (TN3179): “In general, app extensions share the Local Network privilege state of their container app.” It also notes that some background-running extension types may be denied access if the privilege is undetermined. But in my case, the main app clearly has Local Network access, and the extension never receives it, even after repeated successful connections by the main app. Question Is this a known limitation with NEAppPushProvider? Is there a recommended way to ensure the extension is able to use the local network permission once the user has granted it on the app? Any feedback, suggestions, or confirmation would be greatly appreciated. Thanks in advance.

We are currently working on enhancing our iOS app with satellite mode support, allowing users to access a limited set of core features even in the absence of traditional cellular or Wi-Fi connectivity. As part of this capability, we're introducing a chatbot feature that relies on both WebSocket and HTTP connections for real-time interaction and data exchange. Given the constrained nature of satellite networks—especially in terms of latency, bandwidth, and connection stability—we're evaluating the feasibility of supporting these communication protocols under such conditions. Could you please advise whether WebSocket and HTTP connections are expected to work over satellite networks?

Hello there, Starting from iOS 18.4, support was included for QWAC Validation and QCStatements. Using the official QWAC Validator at: https://eidas.ec.europa.eu/efda/qwac-validation-tool I was able to check that the domain "eidas.ec.europa.eu" has a valid QWAC certificate. However, when trying to obtain the same result using the new API, I do not obtain the same result. Here is my sample playground code: import Foundation import Security import PlaygroundSupport PlaygroundPage.current.needsIndefiniteExecution = true @MainActor class CertificateFetcher: NSObject, URLSessionDelegate { private let url: URL init(url: URL) { self.url = url super.init() } func start() { let session = URLSession(configuration: .ephemeral, delegate: self, delegateQueue: nil) let task = session.dataTask(with: url) { data, response, error in if let error = error { print("Error during request: \(error)") } else { print("Request completed.") } } task.resume() } nonisolated func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) { guard let trust = challenge.protectionSpace.serverTrust else { completionHandler(.cancelAuthenticationChallenge, nil) return } if let certificates = SecTrustCopyCertificateChain(trust) as? [SecCertificate] { self.checkQWAC(certificates: certificates) } let credential = URLCredential(trust: trust) completionHandler(.useCredential, credential) } nonisolated func checkQWAC(certificates: [SecCertificate]) { let policy = SecPolicyCreateSSL(true, nil) var trust: SecTrust? guard SecTrustCreateWithCertificates(certificates as CFArray, policy, &trust) == noErr, let trust else { print("Unable to create SecTrust") return } var error: CFError? guard SecTrustEvaluateWithError(trust, &error) else { print("Trust evaluation failed") return } guard let result = SecTrustCopyResult(trust) as? [String : Any] else { print("No result dictionary") return } let qwacStatus = result[kSecTrustQWACValidation as String] let qcStatements = result[kSecTrustQCStatements as String] print("QWAC Status: \(String(describing: qwacStatus))") print("QC Statements: \(String(describing: qcStatements))") } } let url = URL(string: "https://eidas.ec.europa.eu/")! let fetcher = CertificateFetcher(url: url) fetcher.start() Which prints: QWAC Status: nil QC Statements: nil Request completed. Am I making a mistake while using the Security framework? I would greatly appreciate any help or guidance you can provide.

My company has a server that supports ticket-based TLS session resumption (per RFC 5077). We have done Wireshark captures that show that our iOS client app, which uses URLSession for REST and WebSocket connections to the server, is not sending the TLS "session_ticket" extension in the Client Hello package that necessary to enable ticket-based resumption with the server. Is it expected that URLSession does not support ticket-based TLS session resumption? If "yes", is there any way to tell URLSession to enable ticket-based session resumption? the lower-level API set_protocol_options_set_tls_tickets_enabled() hints that the overall TLS / HTTP stack on IOS does support ticket-based resumption, but I can't see how to use that low-level API with URLSession. I can provide (lots) more technical details if necessary, but hopefully this is enough context to determine whether ticket-based TLS resumption is supported with URLSession. Any tips / clarifications would be greatly appreciated.

This happens when trying to connect to my development web server. The app works fine when connecting to my production server. The production server has a certificate purchased from a CA. My development web server has a locally generated certificate (from mkcert). I have dragged and dropped the rootCA.pem onto the Simulator, although it doesn't indicate it has been loaded the certificate does appear in the Settings app and is checked to be trusted. I have enabled "App Sandbox" and "Outgoing connections (Client)". I have tested the URL from my local browser which is working fine. What am I missing?

I am currently creating a MacOS app that uses NetworkExtension and SystemExtension without going through the Store. Using entitlements, I manually codesign and create a pkg Installer, but when I run it I get an error message saying "No matching profile found." Below is the log /Applications/Runetale.app/Contents/MacOS/Runetale not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=file:///Applications/Runetale.app/, unsatisfiedEntitlements=<CFArray 0x71c040fa0 [0x1f7bec120]>{type = immutable, count = 3, values ​​= ( 0 : <CFString 0x71c04f340 [0x1f7bec120]>{contents = "com.apple.developer.system-extension.install"} 1 : <CFString 0x71c1ccaf0 [0x1f7bec120]>{contents = "com.apple.developer.networking.networkextension"} 2 : <CFString 0x71c04fc00 [0x1f7bec120]>{contents = "com.apple.developer.team-identifier"} )}, NSLocalizedDescription=No matching profile found} I looked into it myself and found that if you want to install the app without going through the Store, you need to use packet-tunnel-provider-systemextension instead of packet-tunnel-provider. here However, simply changing to packet-tunnel-provider-systemextension does not allow the build to pass. I use a build method that changes the value of entitlements only during codesign in order to pass the build. SYSEXT="$APP_BUNDLE/Contents/Library/SystemExtensions/com.runetale.desktop.PacketTunnel.systemextension" if [ -d "$SYSEXT" ]; then echo "Signing PacketTunnel system extension with entitlements..." cp macos/PacketTunnel/PacketTunnelRelease.entitlements macos/PacketTunnel/PacketTunnelRelease-sign.entitlements sed -i '' 's/packet-tunnel-provider/packet-tunnel-provider-systemextension/' macos/PacketTunnel/PacketTunnelRelease-sign.entitlements codesign --force --options runtime --timestamp --entitlements "$ENTITLEMENTS_FILE" --sign "$DEV_ID_APP_CERT" "$SYSEXT" fi # 3. Sign the entire .app bundle (deep sign by signing the outer app after inner ones) echo "Signing Runetale App with entitlements..." cp macos/Runner/Release.entitlements macos/PacketTunnel/Release-sign.entitlements sed -i '' 's/packet-tunnel-provider/packet-tunnel-provider-systemextension/' macos/PacketTunnel/Release-sign.entitlementsmacos/PacketTunnel/Release-sign.entitlements codesign --force --options runtime --timestamp --entitlements "$APP_ENTITLEMENTS_FILE" --sign "$DEV_ID_APP_CERT" "$APP_BUNDLE" Is this build method wrong? The next solution I'm thinking of is as follows. Is there a way to write packet-tunnel-provider-systemextension directly to entitlments and pass the build? (provisioning profile?) Apply to forum and get permission to use packet-tunnel-provider-systemextension Thank you.

I want to detect if the adapter is connected to the iPhone even if no IP has been given to the iPhone. I can detect that the interface is connected when the iPhone has been given an IP address, but how can I detect the adapter when not?

Currently in our app, to identify a network switch in device we are doing NEHotspotHelper.register and then NEHotspotHelperHandler block. When the command type is evaluate and if the network.didJustJoin, we are identifying it as a network switch. As a part of moving our code base to iOS 26, if is found that NEHotspotHelper is deprecated. What is the proper replacement for this?

I am trying to migrate an app to use Network framework for p2p connection. I came across this great article for migrating to Network framework however this doesnt use the new structured concurrency. This being introduced with iOS 26, there doesnt seem to be any sample code available on how to use the new classes. I am particularly interested in code samples showing how to add TLS with PSK encryption support and handling of switching between Wifi and peer to peer interface with the new structured concurrency supported classes. Are there any good resources I can refer on this other than the WWDC video?

In my Packet Tunnel Provider, I'm setting the NEDNSSettings to localhost as I have a local DNS server listening on port 53 (this is a dns forwarder which conditionally forwards to different upstreams based on rules). On iOS it works just fine, I'm able to listen on localhost:53 in the Network Extension, then set NEDNSSettings servers to "127.0.0.1". However on macOS due to the port being under 1024, I get a Permission denied OS code 13 error. I'm assuming this is due to the Network Extension not running as root. Can this be changed? This could be rectified if you could customize the port in NEDNSSettings, as the listener could be on port 5353, but it doesn't look like it is possible? Just wondering if there is some other way to accomplish what I'm trying to do in the macOS Network Extension?

Hello all, WWDC 2025 introduced Wi‑Fi Aware (NAN) support on iOS 26 for peer-to-peer discovery and direct connections, but I noticed macOS Tahoe doesn’t include it. I couldn’t find any references to Wi‑Fi Aware APIs or framework support in the macOS SDK. Is Apple planning to bring Wi‑Fi Aware to macOS? If so, will this come in a future update to macOS 26 (e.g., 26.x), or is it deferred to macOS 27 or beyond? Thanks for any insights!

We currently supporting proxy app with Tunnel.appEx and PacketTunnelProvider. Some users report about constant error "The VPN session failed because an internal error occurred." on VPN start (which fails rapidly). This error occur mostly after user updated app with active VPN. Rebooting device solves the problem and it doesnt come again, but it is still very frustrating. I can provide any required info about app setup to solve this issue if you need. Thanks

Apple is encouraging VPN apps on macOS to transition to Network Extension APIs, if they haven't done so yet, see: TN3165: Packet Filter is not API WWDC25: Filter and tunnel network traffic with NetworkExtension Using Network Extension is fine for VPN apps that are distributed via the Mac App Store. Users get one pop-up requesting permission to add VPN configurations and that's it. However, VPN apps that are distributed outside of the App Store (using Developer ID) cannot use Network Extension in the same way, such apps need to install a System Extension first (see TN3134: Network Extension provider deployment). Installing a System Extension is a very poor user experience. There is a pop-up informing about a system extension, which the user has to manually enable. The main button is "OK", which only dismisses the pop-up and in such case there is little chance that the user will be able to find the correct place to enable the extension. The other button in that pop-up navigates to the correct screen in System Settings, where the user has to enable a toggle. Then there is a password prompt. Then the user has to close the System Settings and return to the app. This whole dance is not necessary for VPN apps on the Mac App Store, because they work with "app extensions" rather than "system extensions". As a developer of a VPN app that is distributed outside of the App Store, my options are: Implement VPN functionality in an alternative way, without Network Extension. This is discouraged by Apple. Use a System Extension with Network Extension. This is going to discourage my users. I have submitted feedback to Apple: FB19631390. But I wonder, why did Apple create this difference in the first place? Is there a chance that they will either improve the System Extension installation process or even allow "app extensions" outside of the Mac App Store?

Apologies if this is not the correct topic to post under. EpochField 5.2 is our application. It's a .NET MAUI application built against XCode 16. A customer of ours uses another app, TN3270, to connect to a mainframe host. After installing our app on an iPad and restarting the device, the TN3270 app will disconnect when suspended. Uninstalling our app (EpochField) will allow the TN3270 to suspend without disconnecting. We have tried removing background services, setting UIRequiresFullScreen to false or removing it entirely, and several other ideas. The only remedy seems to be uninstalling EpochField. On an iPad device: Install MochaSoft’s TN3270 app (free version is fine). Create a connection to ssl3270.nccourts.org, port 2023, SSL/TLS turned on, keep alive turned on. Verify that you can connect. Suspend the app by swiping up or choosing another app. Go back to TN3270 and verify that the app has not disconnected. Install EpochField 5.2. Do not run or configure the app, just install it. Repeat step 2. Restart the device. Open EpochField 5.2. You do not need to configure the app or login. Sometimes it isn't necessary to ever open EpochField to get the disconnects, but this is the most reliable way to reproduce the situation. Repeat step 2. The TN3270 app will now disconnect when suspended, even if EpochField is closed. You may need to wait a few seconds after suspending. Uninstall EpochField 5.2. Repeat step 2: the TN3270 app will now remain connected when suspended.

I am developing a program on my chip and attempting to establish a connection with the WiFi Aware demo app launched by iOS 26. Currently, I am encountering an issue during the pairing phase. If I am the subscriber of the service and successfully complete the follow-up frame exchange of pairing bootstrapping, I see the PIN code displayed by iOS. Question 1: How should I use this PIN code? Question 2: Subsequently, I need to negotiate keys with iOS through PASN. What should I use as the password for the PASN SAE process? If I am the subscriber of the service and successfully complete the follow-up frame exchange of pairing bootstrapping, I should display the PIN code. Question 3: How do I generate this PIN code? Question 4: Subsequently, I need to negotiate keys with iOS through PASN. What should I use as the password for the PASN SAE process?

Many times the device totally lost connectivity, WIFI is completely down, no ip was assigned after device wakeup. From system log I can see BPF socket for DHCP was closed and detached right after attached to en0 in DHCP INIT phase, as result even the DHCP server sent back OFFER(I see server sent OFFER back from packet capture), but there is no persistent BPF socket since it is closed reception during the entire INIT phase. It is definitely an OS issue, is it a known issue? Please help understand Why BPF socket was close right after sending DISCOVER? Default 0x0 0 0 kernel: bpf26 attached to en0 by configd:331 2026-03-25 14:06:33.625851+0100 0x31dea Default 0x0 0 0 kernel: bpf26 closed and detached from en0 fcount 0 dcount 0 by configd:331 System log and packet capture attach, please check.