General: Forums subtopic: App & System Services > Networking TN3151 Choosing the right networking API Networking Overview document — Despite the fact that this is in the archive, this is still really useful. TLS for App Developers forums post Choosing a Network Debugging Tool documentation WWDC 2019 Session 712 Advances in Networking, Part 1 — This explains the concept of constrained networking, which is Apple’s preferred solution to questions like How do I check whether I’m on Wi-Fi? TN3135 Low-level networking on watchOS TN3179 Understanding local network privacy Adapt to changing network conditions tech talk Understanding Also-Ran Connections forums post Extra-ordinary Networking forums post Foundation networking: Forums tags: Foundation, CFNetwork URL Loading System documentation — NSURLSession, or URLSession in Swift, is the recommended API for HTTP[S] on Apple platforms. Moving to Fewer, Larger Transfers forums post Testing Background Session Code forums post Network framework: Forums tag: Network Network framework documentation — Network framework is the recommended API for TCP, UDP, and QUIC on Apple platforms. Building a custom peer-to-peer protocol sample code (aka TicTacToe) Implementing netcat with Network Framework sample code (aka nwcat) Configuring a Wi-Fi accessory to join a network sample code Moving from Multipeer Connectivity to Network Framework forums post NWEndpoint History and Advice forums post Network Extension (including Wi-Fi on iOS): See Network Extension Resources Wi-Fi Fundamentals TN3111 iOS Wi-Fi API overview Wi-Fi Aware framework documentation Wi-Fi on macOS: Forums tag: Core WLAN Core WLAN framework documentation Wi-Fi Fundamentals Secure networking: Forums tags: Security Apple Platform Security support document Preventing Insecure Network Connections documentation — This is all about App Transport Security (ATS). WWDC 2017 Session 701 Your Apps and Evolving Network Security Standards [1] — This is generally interesting, but the section starting at 17:40 is, AFAIK, the best information from Apple about how certificate revocation works on modern systems. Available trusted root certificates for Apple operating systems support article Requirements for trusted certificates in iOS 13 and macOS 10.15 support article About upcoming limits on trusted certificates support article Apple’s Certificate Transparency policy support article What’s new for enterprise in iOS 18 support article — This discusses new key usage requirements. Technote 2232 HTTPS Server Trust Evaluation Technote 2326 Creating Certificates for TLS Testing QA1948 HTTPS and Test Servers Miscellaneous: More network-related forums tags: 5G, QUIC, Bonjour On FTP forums post Using the Multicast Networking Additional Capability forums post Investigating Network Latency Problems forums post WirelessInsights framework documentation iOS Network Signal Strength forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] This video is no longer available from Apple, but the URL should help you locate other sources of this info.

I'm seeing fully reproducible issues with URLSession on iOS 18.4 RC Simulator running from Xcode 16.3 RC. URLSession seems to get into a broken state after a second app run. The following sample succeeds in fetching the JSON on first app run but when the app is closed and ran again it fails with one of these errors: Error: Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost." Error: Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." I'm wondering if this something related to my OS setup or is this due to internal URLSession changes in iOS 18.4. Already submitted as FB17006003. Sample code attached below: import SwiftUI @main struct NetworkIssue18_4App: App { var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { @State private var message: String = "" var body: some View { VStack { Text(message) Button("Try Again") { Task { await fetch() } } } .task { await fetch() } } private func fetch() async { message = "Loading..." let url = URL(string: "https://poetrydb.org/title/Ozymandias/lines.json")! let session = URLSession.shared do { let response = try await session.data(from: url) print("Response: \(response)") message = "Success, data length: \(response.0.count)" } catch { print("Error: \(error)") message = "Error: \(error.localizedDescription)" } } }

It's not yet fully clear why and when does this crash occur, but I'm creating this post so there's a centralized thread for this. Some hints collected so far: The crash is occurring for existing Xcode projects opened with new Xcode 26.0 beta (17A5241e); no one's been able to reproduce on a project created in Xcode 26. I even tried creating a project with Xcode 16.2 and open it in Xcode 26, but it's all working fine there (don't have older Xcode at the moment, to try with many versions) It crashes right at the line of code that initializes URLSessionConfiguration. If you call URLSession() without parameters (which is deprecated as of iOS 13), the session initializes without the crash. It's NOT occurring only for libraries installed through package manages. In a project where it crashes, one should be able to reproduce by adding URLSessionConfiguration.default as the first line in didFinishLaunchingWithOptions It crashes when running an app on an iOS 26 simulator. (I don't have a device running beta iOS 26 to test on it!) It's working fine when running the app on a simulator or a device running iOS 18 or older. Related issue on Firebase GitHub repo: https://github.com/firebase/firebase-ios-sdk/issues/14948 Sorry to not be able to provide more info at the moment. I wanted to report this so in case someone from Apple knows about it, we could at least get some feedback or workarounds, until fix is released -- and, to prevent us all from duplicating this report in repositories of each library, as this isn't related to libraries.

Aloha. Opening and closing VPN tunnels results in as many utun interfaces as the amount of times the tunnel has been opened. These interfaces stay present and seem to be removed only upon system reboot. We are using the NetworkExtension as a SystemExtension on macOS to create the virtual interfaces. Is this the normal behaviour. Has anybody else experienced this? utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380 inet6 fe80::8038:c353:17cd:c422%utun0 prefixlen 64 scopeid 0xf nd6 options=201<PERFORMNUD,DAD> utun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000 inet6 fe80::cfb6:1324:d7e9:5d5%utun1 prefixlen 64 scopeid 0x10 nd6 options=201<PERFORMNUD,DAD> utun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1300 options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM> utun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1300 options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM> utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1300 options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM> utun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1300 options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM> utun6: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1300 options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM> utun7: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1300 options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM> utun8: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1300 options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>

There is a problem with the Apple local network setting api, iOS18 system, you turn off the local network permissions of the APP, uninstall the APP, and then re-install, the local network permissions even if opened, there is no effect, only restart the phone is useful

Hi, Having an issue on one mac using Xcode 16.3 and simulator 18.4. macSO 15.4 We are checking for bonjour: authorizationBrowser = NWBrowser(for: .bonjour(type: "_bonjour._tcp", domain: nil), using: parameters) authorizationBrowser?.stateUpdateHandler = { [weak self] newState in switch newState { ... } } However at the command line we get the error: nw_browser_fail_on_dns_error_locked [B1] nw_browser_dns_service_browse_callback failed: PolicyDenied(-65570) Any idea why this is happening? or what this error means? Thanks Antz

Hi, I'm new to swift programming and right now writing an app for esp8266-controlled lamp device. My lamp is broadcasting it's own IP through bonjour. So all I want is to discover any lamps in my network (http.tcp) and to read name and value. Is there any example of such implementation? All I found so far is old or a lit bit complicated for such simple question. Thanks in advance!

On iOS 26 beta 5, it is impossible to add a VPN configuration when a passcode is set on the device. Every time, all it does is redirect to the Settings app with no prompt for passcode. The only way around this is to disable passcode on the device so adding a VPN configuration doesn’t have to open the Settings app. This issue happened intermittently in the past with previous iOS 26 betas and even on iOS 18, but the problem has worsened on iOS 26 beta 5 to the point where you have to turn off passcode to add a VPN. Feedback ID: FB17974765

After pairing and having subscribed to a service, and even after having exchanged messages, the service fails after a period of time and both devices need to pair again.

Hello, I am working to integrate the new com.apple.developer.networking.carrier-constrained.app-optimized entitlement in my iOS 26 app so that my app can use a carrier-provided satellite network, and want to confirm my understanding of how to detect and optimize for satellite network conditions. (Ref: https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.networking.carrier-constrained.app-optimized ) My current approach: I plan to set the entitlement to true once my app is optimized for satellite networks. To detect if the device is connected to a satellite network, I intend to use the Network framework’s NWPath properties: isUltraConstrained — I understand this should be set to true when the device is connected to a satellite network. (Ref: https://developer.apple.com/documentation/network/nwpath/isultraconstrained ) linkQuality == .minimal — I believe this will also be set in satellite scenarios, though it may not be exclusive to satellite connections. (Ref: https://developer.apple.com/documentation/network/nwpath/linkquality-swift.enum/minimal ) Questions: Is it correct that isUltraConstrained will reliably indicate a satellite connection? Should I also check for linkQuality == .minimal, or is isUltraConstrained sufficient? Are there any additional APIs or best practices for detecting and optimizing for satellite connectivity that I should be aware of? Thank you for confirming whether my understanding and approach are correct, and for any additional guidance.

There is no available API that allows you to connect to Android. The current APIs that are provided are not compatible outside of the Apple Ecosystem. For example, Android requires you to set a service name and a password where iOS sets a service and a PIN authentication strategy in a specific format that’s not compatible. It looks like the implementation is not following the Wifi Aware Specifications. To enable cross platform interoperability while providing security, could you adopt the same strategy as with Bluetooth and enable iOS users to enable the sharing and subscription of services with Everyone.

When a VPN is active, RCS messaging does not work on iOS 18. I work on an iOS VPN app, and we were very appreciative of the excludeCellularServices network flag that was released during the iOS 16 cycle. It's a great solution to ensure the VPN doesn't interfere with cellular network features from the cellular provider. Separately - As a user, I'm excited that iOS 18 includes RCS messaging. Unfortunately, RCS messaging is not working when our VPN is active (when checking on the iOS 18 release candidate). My guess is that RCS is not excluded from the VPN tunnel, even when excludeCellularServices is true. It seems like RCS should be added in this situation, as it is a cell provider service. Can RCS be added as a service that is excluded from the VPN tunnel when excludeCellularServices is true? (I've also sent this via feedback assistant, as 15094270.)

I haven’t been able to get this to work at any level! I’m running into multiple issues, any light shed on any of these would be nice: I can’t implement a bloom filter that produces the same output as can be found in the SimpleURLFilter sample project, after following the textual description of it that’s available in the documentation. No clue what my implementation is doing wrong, and because of the nature of hashing, there is no way to know. Specifically: The web is full of implementations of FNV-1a and MurmurHash3, and they all produce different hashes for the same input. Can we get the proper hashes for some sample strings, so we know which is the “correct” one? Similarly, different implementations use different encodings for the strings to hash. Which should we use here? The formulas for numberOfBits and numberOfHashes give Doubles and assign them to Ints. It seems we should do this conversing by rounding them, is this correct? Can we get a sample correct value for the combined hash, so we can verify our implementations against it? Or ignoring all of the above, can we have the actual code instead of a textual description of it? 😓 I managed to get Settings to register my first attempt at this extension in beta 1. Now, in beta 2, any other project (including the sample code) will redirect to Settings, show the Allow/Deny message box, I tap Allow, and then nothing happens. This must be a bug, right? Whenever I try to enable the only extension that Settings accepted (by setting its isEnabled to true), its status goes to .stopped and the error is, of course, .unknown. How do I debug this? While the extension is .stopped, ALL URL LOADS are blocked on the device. Is this to be expected? (shouldFailClosed is set to false) Is there any way to manually reload the bloom filter? My app ships blocklist updates with background push, so it would be wasteful to fetch the filter at a fixed interval. If so, can we opt out of the periodic fetch altogether? I initially believed the API to be near useless because I didn’t know of its “fuzzy matching” capabilities, which I’ve discovered by accident in a forum post. It’d be nice if those were documented somewhere! Thanks!!

Hi! I've noticed that the IP_RECVIF socket option, i.e.: int y = 1; setsockopt(fd, IPPROTO_IP, IP_RECVIF, &y, sizeof(y)); does not seem to work if the socket is proxied by a NETransparentProxyProvider type network extension: there's no ancillary data in messages received with recvmsg. As soon as I disable the network extension, recvmsg starts returning ancillary data containing the interface name. This seems to break some applications which rely on IP_RECVIF in the presence of a transparent proxy, making it, in fact, not transparent. One such example is Apple's own libresolv, which relies on IP_RECVIF and breaks if there's no ancillary data in the recvmsg result. I don't think that this is the intended behaviour, since IPV6_PKTINFO seems to work fine. I've filed a bug report (FB17586550) about this, however, I would greatly appreciate if someone could point me in the direction of a workaround.

I couldn't find any mention in the Wi-Fi Aware documentation https://developer.apple.com/documentation/WiFiAware about the possibilities of the Wi-Fi Aware connection during the app working in the background execution mode (background state). Does the framework keep the connection alive when the app goes to the background state? Is there anything similar concept to CoreBluetooth state restoration available in the case of the Wi-Fi Aware framework?

I am pretty sure iOS 13.4 (beta and later) did support Coded PHY (Long Range). Tested devices are iPhone SE2 and iPhone 11 Pro. However, it seems iOS 14 removed the support of Coded PHY, accidentally or on purpose, I don't know? The same PHY update request returns "1M PHY" in iOS 14, but "Coded PHY" in iOS 13 (13.4 beta and later). Anyone knows why? Samson

Hi there, We’re developing a companion app for a smart home product that communicates over the user’s local network. To provision the device, it initially creates its own Wi-Fi network. The user joins this temporary network and enters their home Wi-Fi credentials via our app. The app then sends those credentials directly to the device, which stores them and connects to the local network for normal operation. We’re using AccessorySetupKit to discover nearby devices (via SSID prefix) and NEHotspotManager to join the accessory’s Wi-Fi network once the user selects it. This workflow works well in general. However, we’ve encountered a problem: if the user factory-resets the accessory, or needs to restart setup (for example, after entering the wrong Wi-Fi password), the device no longer appears in the accessory picker. In iOS 18, we were able to work around this by calling removeAccessory() after the device is selected. This forces the picker to always display the accessory again. But in iOS 26, a new confirmation dialog now appears when calling removeAccessory(), which confuses users during setup. We’re looking for a cleaner way to handle this scenario — ideally a way to make the accessory rediscoverable without prompting the user to confirm removal. Thanks for your time and guidance.

When installing a new version the app while a tunnel is connected, seemingly the old packet tunnel process gets stopped but the new one does not come back up. Reportedly, a path monitor is reporting that the device has no connectivity. Is this the expected behavior? When installing an update from TestFlight or the App store, the packet tunnel instance from the old tunnel is stopped, but, due to the profile being on-demand and incldueAllNetworks, the path monitoring believes the device has no connectivity - so the new app is never downloaded. Is this the expected behavior? During development, the old packet tunnel gets stopped, the new app is installed, but the new packet tunnel is never started. To start it, the user has to toggle the VPN twice from the Settings app. The tunnel could be started from the VPN app too, if we chose to not take the path monitor into account, but then the user still needs to attempt to start the tunnel twice - it only works on the second try. As far as we can tell, the first time around, the packet tunnel never gets started, the app receives an update about NEVPNStatus being set to disconnecting yet NEVPNConnection does not throw. The behavior I was naively expecting was that the packet tunnel process would be stopped only when the new app is fully downloaded and when the update is installed, Are we doing something horribly wrong here?

I was excited to find out about Wi-Fi Aware in i[Pad]OS 26 and was eager to experiment with it. But after wiping and updating two devices (an iPhone 11 Pro and a 2018 11" iPad Pro) to Beta 1 I found out that neither of them support Wi-Fi Aware 🙁. What current and past iPhone and iPad models support Wi-Fi Aware? And is there a new UIRequiredDeviceCapabilities key for it, to indicate that an app requires a Wi-Fi Aware capable device?

We are developing an iOS application that is interacting with HTTP APIs that requires us to put a unique UUID (a nonce) as an header on every request (obviously there's more than that, but that's irrilevant to the question here). If the same nonce is sent on two subsequent requests the server returns a 412 error. We should avoid generating this kind of errors as, if repeated, they may be flagged as a malicious activity by the HTTP APIs. We are using URLSession.shared.dataTaskPublisher(for: request) to call the HTTP APIs with request being generated with the unique nonce as an header. On our field tests we are seeing a few cases of the same HTTP request (same nonce) being repeated a few seconds on after the other. Our code has some retry logic only on 401 errors, but that involves a token refresh, and this is not what we are seeing from logs. We were able to replicate this behaviour on our own device using Network Link Conditioner with very bad performance, with XCode's Network inspector attached we can be certain that two HTTP requests with identical headers are actually made automatically, the first request has an "End Reason" of "Retry", the second is "Success" with Status 412. Our questions are: can we disable this behaviour? can we provide a new request for the retry (so that we can update headers)? Thanks, Francesco