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!

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.

Hello, Since the release of iOS 26.0, we are seeing DNS traffic being blocked from within our NEPacketTunnelExtension on some devices. We have not isolated exact reproduction steps, but DNS resolves successfully for a period of time after enabling "iCloud Private Relay" (varying from 1-day to 2-weeks), until it then fails as MDNSResponder then returns: mDNSResponder [Q37046] DetermineUnicastQuerySuppression: Query suppressed for <mask.hash: 'REDACTED'> Addr (blocked by policy) DNS resolution continues to fail for all domains with the above until the device is rebooted. The Packet Tunnel intentionally does not have a DNS server set and this occurs for traffic from the Extension yet off-tunnel, which needs resolution from the system DNS server (and this configuration works perfectly for a period of time before being "blocked by policy"). The following do not resolve the issue once DNS queries are being "blocked by policy" on affected devices: disconnecting then reconnecting the vpn; toggling airplane mode for 10+ seconds; switching connection between WiFi & cellular data; disabling iCloud Private Relay. We have currently only seen this on unmanaged devices running iOS 26.0 or 26.1 beta and with iCloud Private Relay enabled. We did not see this issue on iOS 16,17 nor 18. We also have not yet seen this when iCloud Private Relay is disabled nor on iOS 26.0.1, however we cannot confirm whether they too are also affected. Is there a known a bug with iOS 26.0 & 26.1 Beta 1 that could cause this? How can we prevent DNS requests from NEPacketTunnelExtension being sporadically "blocked by policy" until the device is rebooted? Many thanks in advance.

Hi there, We are facing some issues regarding TLS connectivity: Starting with iOS 26, the operating system refuses to open TLS sockets to local devices with self-signed certificates over Wi-Fi. In this situation, connection is no longer possible, even if the device is detected on the network with Bonjour. We have not found a workaround for this problem. We've tryied those solutions without success: Added the 'NSAppTransportSecurity' key to the info.plist file, testing all its items, such as "NSAllowsLocalNetworking", "NSExceptionDomains", etc. Various code changes to use properties such as "sec_protocol_options_set_local_identity" and "sec_protocol_options_set_tls_server_name" to no avail. Brutally import the certificate files into the project and load them via, for example, "Bundle.main.url(forResource: "nice_INTERFACE_server_cert", withExtension: "crt")", using methods such as sec_trust_copy_ref and SecCertificateCopyData. Download the .pem or .crt files to the iPhone, install them (now visible under "VPN & Device Management"), and then flag them as trusted by going to "Settings -> General -> Info -> Trust". certificates" The most critical part seems to be the line sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { $2(true) }, queue) whose purpose is to bypass certificate checks and validate all of them (as apps already do). However, on iOS26, if I set a breakpoint on leg$2(true),` it never gets there, while on iOS 18, it does. I'll leave as example the part of the code that was tested the most below. Currently, on iOS26, the handler systematically falls back to .cancelled: func startConnection(host: String, port: UInt16) { self.queue = DispatchQueue(label: "socketQueue") let tlsOptions = NWProtocolTLS.Options() sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { $2(true) }, queue) let parameters = NWParameters(tls: tlsOptions) self.nwConnection = NWConnection(host: .init(host), port: .init(rawValue: port)!, using: parameters) self.nwConnection.stateUpdateHandler = { [weak self] state in switch state { case .setup: break case .waiting(let error): self?.connectionDidFail(error: error) case .preparing: break case .ready: self?.didConnectSubject.onNext(Void()) case .failed(let error): self?.connectionDidFail(error: error) case .cancelled: self?.didDisconnectSubject.onNext(nil) @unknown default: break } } self.setupReceive() self.nwConnection.start(queue: queue) } These are the prints made during the procedure. The ones with the dot are from the app, while the ones without are warnings/info from Xcode: 🔵 INFO WifiNetworkManager.connect():52 - Try to connect onto the interface access point with ssid NiceProView4A9151_AP 🔵 INFO WifiNetworkManager.connect():68 - Connected to NiceProView4A9151_AP tcp_output [C13:2] flags=[R.] seq=215593821, ack=430284980, win=4096 state=CLOSED rcv_nxt=430284980, snd_una=215593821 nw_endpoint_flow_failed_with_error [C13 192.168.0.1:443 in_progress channel-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], dns, uses wifi, LQM: unknown)] already failing, returning nw_connection_copy_protocol_metadata_internal_block_invoke [C13] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C13] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C13] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C13] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C14] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C14] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C14] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C14] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection [C14 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel [C14 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel nw_connection_copy_protocol_metadata_internal_block_invoke [C15] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C15] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C15] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C15] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C16] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C16] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C16] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C16] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection [C16 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel [C16 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel 🔴 ERROR InterfaceDisconnectedViewModel.connect():51 - Sequence timeout.

On one test machine, our extension wouldn't load, because [NETransparentProxyManager loadAllFromPreferencesWithCompletionHandler] can't find a manager, saying Skipping configuration appname because it is of the wrong type. This is the first time I've seen this behaviour. (The containing app tries to find a configuration, if it can't find it it creates one, then modifies whatever it found or created, then stores it. I don't have the right logging yet for that, so I can't see the error messages. [NSLog instead of os_log_error.])

Questions about FTP crop up from time-to-time here on DevForums. In most cases I write a general “don’t use FTP” response, but I don’t have time to go into all the details. I’ve created this post as a place to collect all of those details, so I can reference them in other threads. IMPORTANT Apple’s official position on FTP is: All our FTP APIs have been deprecated, and you should avoid using deprecated APIs. Apple has been slowly removing FTP support from the user-facing parts of our system. The most recent example of this is that we removed the ftp command-line tool in macOS 10.13. You should avoid the FTP protocol and look to adopt more modern alternatives. The rest of this post is an informational explanation of the overall FTP picture. This post is locked so I can keep it focused. If you have questions or comments, please do create a new thread in the App & System Services > Networking subtopic and I’ll respond there. Don’t Use FTP FTP is a very old and very crufty protocol. Certain things that seem obvious to us now — like being able to create a GUI client that reliably shows a directory listing in a platform-independent manner — aren’t possible to do in FTP. However, by far the biggest problem with FTP is that it provides no security [1]. Specifically, the FTP protocol: Provides no on-the-wire privacy, so anyone can see the data you transfer Provides no client-authenticates-server authentication, so you have no idea whether you’re talking to the right server Provides no data integrity, allowing an attacker to munge your data in transit Transfers user names and passwords in the clear Using FTP for anonymous downloads may be acceptable (see the explanation below) but most other uses of FTP are completely inappropriate for the modern Internet. IMPORTANT You should only use FTP for anonymous downloads if you have an independent way to check the integrity of the data you’ve downloaded. For example, if you’re downloading a software update, you could use code signing to check its integrity. If you don’t check the integrity of the data you’ve downloaded, an attacker could substitute a malicious download instead. This would be especially bad in, say, the software update case. These fundamental problems with the FTP protocol mean that it’s not a priority for Apple. This is reflected in the available APIs, which is the subject of the next section. FTP APIs Apple provides two FTP APIs: All Apple platforms provide FTP downloads via URLSession. Most Apple platforms (everything except watchOS) support CFFTPStream, which allows for directory listings, downloads, uploads, and directory creation. All of these FTP APIs are now deprecated: URLSession was deprecated for the purposes of FTP in the 2022 SDKs (macOS 13, iOS 16, iPadOS 16, tvOS 16, watchOS 9) [2]. CFFTPStream was deprecated in the 2016 SDKs (macOS 10.11, iOS 9, iPadOS 9, tvOS 9). CFFTPStream still works about as well as it ever did, which is not particularly well. Specifically: There is at least one known crashing bug (r. 35745763), albeit one that occurs quite infrequently. There are clear implementation limitations — like the fact that CFFTPCreateParsedResourceListing assumes a MacRoman text encoding (r. 7420589) — that won’t be fixed. If you’re looking for an example of how to use these APIs, check out SimpleFTPSample. Note This sample hasn’t been updated since 2013 and is unlikely to ever be updated given Apple’s position on FTP. The FTP support in URLSession has significant limitations: It only supports FTP downloads; there’s no support for uploads or any other FTP operations. It doesn’t support resumable FTP downloads [3]. It doesn’t work in background sessions. That prevents it from running FTP downloads in the background on iOS. It’s only supported in classic loading mode. See the usesClassicLoadingMode property and the doc comments in <Foundation/NSURLSession.h>. If Apple’s FTP APIs are insufficient for your needs, you’ll need to write or acquire your own FTP library. Before you do that, however, consider switching to an alternative protocol. After all, if you’re going to go to the trouble of importing a large FTP library into your code base, you might as well import a library for a better protocol. The next section discusses some options in this space. Alternative Protocols There are numerous better alternatives to FTP: HTTPS is by far the best alternative to FTP, offering good security, good APIs on Apple platforms, good server support, and good network compatibility. Implementing traditional FTP operations over HTTPS can be a bit tricky. One possible way forward is to enable DAV extensions on the server. FTPS is FTP over TLS (aka SSL). While FTPS adds security to the protocol, which is very important, it still inherits many of FTP’s other problems. Personally I try to avoid this protocol. SFTP is a file transfer protocol that’s completely unrelated to FTP. It runs over SSH, making it a great alternative in many of the ad hoc setups that traditionally use FTP. Apple doesn’t have an API for either FTPS or SFTP, although on macOS you may be able to make some headway by invoking the sftp command-line tool. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] In another thread someone asked me about FTP’s other problems, those not related to security, so let’s talk about that. One of FTP’s implicit design goals was to provide cross-platform support that exposes the target platform. You can think of FTP as being kinda like telnet. When you telnet from Unix to VMS, it doesn’t aim to abstract away VMS commands, so that you can type Unix commands at the VMS prompt. Rather, you’re expected to run VMS commands. FTP is (a bit) like that. This choice made sense back when the FTP protocol was invented. Folks were expecting to use FTP via a command-line client, so there was a human in the loop. If they ran a command and it produced VMS-like output, that was fine because they knew that they were FTPing into a VMS machine. However, most users today are using GUI clients, and this design choice makes it very hard to create a general GUI client for FTP. Let’s consider the simple problem of getting the contents of a directory. When you send an FTP LIST command, the server would historically run the platform native directory list command and pipe the results back to you. To create a GUI client you have to parse that data to extract the file names. Doing that is a serious challenge. Indeed, just the first step, working out the text encoding, is a challenge. Many FTP servers use UTF-8, but some use ISO-Latin-1, some use other standard encodings, some use Windows code pages, and so on. I say “historically” above because there have been various efforts to standardise this stuff, both in the RFCs and in individual server implementations. However, if you’re building a general client you can’t rely on these efforts. After all, the reason why folks continue to use FTP is because of it widespread support. [2] To quote the macOS 13 Ventura Release Notes: FTP is deprecated for URLSession and related APIs. Please adopt modern secure networking protocols such as HTTPS. (92623659) [3] Although you can implement resumable downloads using the lower-level CFFTPStream API, courtesy of the kCFStreamPropertyFTPFileTransferOffset property. Revision History 2025-10-06 Explained that URLSession only supports FTP in classic loading mode. Made other minor editorial changes. 2024-04-15 Added a footnote about FTP’s other problems. Made other minor editorial changes. 2022-08-09 Noted that the FTP support in URLSession is now deprecated. Made other minor editorial changes. 2021-04-06 Fixed the formatting. Fixed some links. 2018-02-23 First posted.

I have a Vision Pro app, which I intend to use Apple-Hosted Background Assets for some of my videos after watching: https://developer.apple.com/videos/play/wwdc2025/325 I added a Apple-Hosted, Managed extension. New Target -> Background Download -> Apple-Hosted, Managed After creating an Archive, I tried uploading it to TestFlight, it complains about a DTPlatformName error in my Info.plist. So I added the following : <key>DTPlatformName</key> <string>xros</string> With which, I managed to upload the app with the extension to TestFlight. However, when I tried installing the app on TestFlight to Vision Pro, it gives me an error that says the app cannot be verified. Any help or pointers is greatly appreciated. Info.plist Entitlements

I've been wondering what is the memory limit for network extensions. Specifically, I'm using the NEPacketTunnelProvider extension point.The various posts on this forum mention 5 MB and 6 MB for 32-bit and 64-bit respectively. However I find that (at least on iOS 10) the upper limit seems to be 15 MB. Is this the new memory limit for extensions?

We currently have a PacketTunnelProvider providing a VPN connection to managed devices. Our profile locks this down with OnDemandEnabled and OnDemandUserOverrideDisabled set to true. We've had reports of the OnDemand feature not kicking in on macOS when switching profiles or creating new profiles for managed users (but this works for the initial user login). When switching profiles, OnDemand does not enable; however, if the user manually enables the VPN and then disables, OnDemand will now correctly turn the connection back on. The installed profile contains: OnDemandEnabled: 1 OnDemandRules: Connect Action for WiFi, Cellular, and Ethernet OnDemandUserOverrideDisabled: 1 From sysdiagnose logs, I see some interesting logs for nesessionmanager: Handling a network changed event Resetting VPN On Demand Found 0 registrations for [...].PacketTunnel Failed to find [...].PacketTunnel app extension using neagent Plugin is not available in launch services Plugin is not installed (I also see some failures with LSApplicationProxy, but not sure if those are relevant.) Eventually, I see: Plugin is installed Enabling VPN On Demand And things seem to kick off more as expected from that point on. Do we have any guidance on how to address this issue? We also have a ticket submitted with Feedback Assistant.

Title / Summary Crash in libquic.dylib when app is backgrounded and issues an HTTP/3 request Description On iOS 26, the app crashes inside libquic.dylib while performing a network request using HTTP/3 (QUIC) after the app has moved to the background. The crash happens within low-level QUIC / libquic internals. Reproduction Steps Launch the app, perform normal operations. Background the app (press home / switch away). While in background, trigger a network request that uses HTTP/3 / QUIC. Observe that the app crashes (stack trace pointing into libquic.dylib). Expected Behavior The HTTP/3 request in background should either be handled gracefully (fail or complete) without causing a crash; the app must not be terminated due to internal libquic failures. Actual Behavior The app crashes with signals/exceptions coming from libquic.dylib (in the QUIC / packet building / encryption / key state logic) when a HTTP/3 request is made in background. Environment / Device Information • OS: iOS 26 • Device: iPhone 13 Pro Max • Network environment: (Wi-Fi / Cellular) • HTTP/3 support: enabled in URLSession / Network framework Stack Trace： 8eedc0df3d914b0faf8def9af3b21574-symbolicated.crash

1) Blocked page UX When a URL is blocked, the browser typically shows a generic error like “"Safari cannot open the page because it couldn’t load any data,” with no indication that the page was blocked by a policy. Is there any plan to add an API that allows developers to present a custom “blocked” page or remediation action, similar to NEFilterControlProvider’s remediationMap? Even a minimal hook (custom HTML, deep link, or support URL) would make the experience clearer for users. 2) Cross‑app link‑opening behavior With a block rule in place, direct navigation in Safari is blocked as expected. However, tapping the same URL in a messaging app (e.g., WhatsApp) opens Safari - and the page loads, not blocked. Repro steps: Configure a URL Filter extension that blocks https://example.com. Case A: Open a browser and type the URL in the address bar → blocked (expected). Case B: Tap the same URL in WhatsApp (or another messenger) → a browser opens and the page loads (unexpected). iOS version - 26.0

How often do we see control filter start and stop? I read somewhere that data filter is long lived and control Filter is short lived. When does the operating system kills the control filter process?

I have been playing around with the new URL Filtering API. I have successfully installed and configured the sample code, Installed the example app to my iPhone, and am also running the PIR server locally on my Mac. In my input.txtpb file, I simply have 2 endpoints: rows: [{ keyword: "instagram.com", value: "1" }, { keyword: "youtube.com/shorts", value: "1" }] Neither of these are blocked when I attempt to load them from either a browser, or their dedicated apps. Are there any debugging tips I should know about? Additionally, I have also noticed a few times I have left the filter running on my phone, after leaving my LAN (where the PIR server is running), suddenly throughout the day I'm having random, completely unrelated endpoints blocked on my phone. I thought this API was never supposed to produce false positives (without calling back to the PIR server for confirmation).

I was exploring the scenarios where an NWListener or NWConnection can be invalidated or reclaimed by the OS itself. I came across the document TN2277: Networking and Multitasking, which discusses situations where iOS can reclaim the underlying socket descriptor. The document states: while the app is suspended the system may choose to reclaim resources out from underneath a network socket used by the app, thereby closing the network connection represented by that socket. From this, I understand that when the app is in a suspended state, the OS may reclaim the socket descriptor. My questions are: In what scenarios does the OS not reclaim the socket descriptor while the app is suspended, and in which cases does it reclaim it? When reclamation occurs, does the OS reclaim 'a' single NWListener/NWConnection, or does it reclaim 'all' NWListener/NWConnections opened by the application? Thanks.

We are using wifi_aware demo at https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps. We use iPhone 16 with ios26 to install this app successfully for the first time. After then we want to remove some paired devices, but the function used to delete paired device is not founded. So we uninstall the app, and intend to install it again. This time, it jump to the interface displaying the message "This device does not support Wi-Fi Aware". We are confused by this and don't know what to do. Instead of using other devices, how can we successfully install the app on this device. The iphone, Apple computer and Xcode environment maintain the same for sure. We sincerely appreciate your reply.

Hello, we are developing hardware that needs to connect to an iPhone via Wi-Fi to send requests to a server. On Android, we have managed to create a programmatic local hotspot within the app to facilitate connection and improve the user experience. On iOS, however, Personal Hotspot must be manually enabled from the system settings, and the user must manually enter the SSID and password, which significantly degrades the UX. My questions are: Is there a workaround, unofficial method, or private API to generate a local hotspot from an app on iOS, similar to what can be done on Android? Is there an alternative within the MFi program or through specific frameworks to facilitate a quick and automatic connection between the hardware and the iPhone without relying on the manual Personal Hotspot? Are there any best practices for improving the local Wi-Fi connection experience between an accessory and an iPhone in the absence of hotspot controls? I would appreciate any guidance, experience, or resources that would help me better understand the feasible options in iOS for scenarios where fast and direct communication between hardware and mobile devices via Wi-Fi is required.

Device: iPhone 17 Series System: iOS 26.0.0 Wi-Fi: TKIP encryption protocol Question: Unable to join the network We have several products that are used by connecting to iPhone via Wi-Fi. Recently, many customers who have purchased the iPhone 17 series have reported that they are unable to connect to Wi-Fi. For Wi-Fi with TKIP encryption, after entering the password correctly to connect to the Wi-Fi, a pop-up appears stating "Unable to join the network.". Only Wi-Fi with WPA2-AES can be used normally. Before that, during the iPhone 11 era or even earlier, the TKIP encryption method was in normal use. However, the new iPhone models were incompatible with it, which obviously caused great inconvenience. I hope the engineers can fix this issue to support Wi-Fi with older encryption protocols.

Background Android phones supporting Wi-Fi Aware 4.0 should be able to connect with iPhones (iOS 26). For testing, we selected two Samsung S25 devices, which support Wi-Fi Aware 4.0. Issues we are facing Android as Publisher, iOS as Subscriber.iOS cannot discover the service. Log shows: Discovery: Dropping event, 02:14:60:76:a6:0f missing DCEA attribute. iOS as Publisher, Android as Subscriber,Android can discover the service.However, the PIN code is not displayed on iOS. From the packet capture, the publish packet does not contain the DCEA field. However, Android-to-Android devices can still pair normally, and the subsequent PASN packets include the DCEA field. It seems that the Wi-Fi Alliance only requires the DCEA to be present in the PASN packets. iOS cannot discover Android devices or complete pairing — is this caused by the DCEA field, or by other reasons?

Eager to see the Wi-Fi Aware communication between iPhone (iOS 26) and an Android device, I tried iOS 26 beta on my iPhone16. and tried below code snippet from provided example at https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps. Idea is to first verify discovery of Android WiFiAware service on iOS. extension WAPublishableService { public static var simulationService: WAPublishableService { allServices[simulationServiceName]! } } extension WASubscribableService { public static var simulationService: WASubscribableService { allServices[simulationServiceName]! } } struct ContentView: View { @State private var showingDevicePicker = false @State private var pairedDevices: [WAPairedDevice] = [] // To hold discovered/paired devices var body: some View { VStack { Button("Discover Devices") { showingDevicePicker = true // Trigger the device picker presentation } .sheet(isPresented: $showingDevicePicker) { DevicePicker(.wifiAware(.connecting(to: .selected([]), from: .simulationService))) { endpoint in print("Paired Endpoint: \(endpoint)") } label: { Image(systemName: "plus") Text("Add Device") } fallback: { Image(systemName: "xmark.circle") Text("Unavailable") } } List(pairedDevices) { device in Text(device.name ?? "Unknown Device") } } } } With suggested entitlement of WiFiAware and info.plist of service info. Then I had Android device with WIFiAware service publishing service (service name set '_sat-simulation._udp') from this app https://github.com/anagramrice/NAN. But above iOS app is unable to find the service published from android device. Am I missing something? Note: the above Android-NAN app seems to be working fine between Android to Another Android.

Hi! I wrote an internal used backup command line tool which is in use since several years. Today I got an error while sending an email: “Failed: ioOnClosedChannel”. I assume that the latest macOS updates did break my app. On the server I use macOS 15.7 and on my development machine macOS 26. Here is the related code: private func sendMail() { var a : [Email.Attachment] = [] if self.imageData != nil { switch self.imageType { case .tiff: a.append(Email.Attachment(name: "Statistics.tif", contentType: #"image/tiff"#, contents: ByteBuffer(bytes: self.imageData!))) case .pdf: a.append(Email.Attachment(name: "Statistics.pdf", contentType: #"application/pdf"#, contents: ByteBuffer(bytes: self.imageData!))) case .unknown: fatalError("Unimplemented attachment type!") } } mailHtml = mailHtml.replacingOccurrences(of: "<br>", with: "<br>\n") let email = Email(sender: .init(name: "Backup", emailAddress: "SENDER@MYDOMAIN"), replyTo: nil, recipients: recipients, cc: [], bcc: [], subject: self.subject, body: .universal(plain: self.mailText, html: mailHtml), attachments: a) let evg = MultiThreadedEventLoopGroup(numberOfThreads: System.coreCount) let mailer = Mailer(group: evg, configuration: smtpConfig, transmissionLogger: nil) do { print("Sending mail... ", terminator: "") try mailer.send(email: email).wait() // <-- ERROR HERE Failed: ioOnClosedChannel print("done.") } catch { print("Failed: \(error)") } do { try evg.syncShutdownGracefully() } catch { print("Failed shutdown: \(error)") } } I use https://github.com/sersoft-gmbh/swift-smtp. Any clue about the reason of this error? TIA, GreatOm