Dear apple: Our app uses the BSD socket interface for socket communication over the local area network. However, when using the socket's connect interface, some iPhone devices fail, and the socket has also bound the local Wi-Fi card's IP using the bind interface. The errno is 65, indicating "no route." We have checked that the app has already requested local network permissions and permissions to use the local area network. The TCP server on the other end is also listening normally. Please help us see if any additional permissions need to be requested. Thank you

I'm creating a custom VPN app which should only work on Cellular. Apart from cellular interface binding VPN is working fine. Even though I specified cellular interface like let cellularParams = NWParameters.udp cellularParams.requiredInterfaceType = .cellular It is going via Wifi when it is ON. I know this is the default iOS behaviour. How can I prevent this and route through cellular only even when Wifi is enabled on device?

I am developing an iOS application using NWPathMonitor for network connectivity monitoring. We discovered a reproducible issue where disabling and re-enabling WiFi triggers an unexpected network status sequence. ENVIRONMENT: iOS Version: 17.x Device: iPhone (various models tested) Network Framework: NWPathMonitor from iOS Network framework STEPS TO REPRODUCE: Device connected to WiFi normally Disable WiFi via Settings or Control Center Re-enable WiFi via Settings or Control Center EXPECTED BEHAVIOR: WiFi reconnects and NWPathMonitor reports stable satisfied status ACTUAL BEHAVIOR: T+0s: WiFi re-enables, NWPathMonitor reports path.status = .satisfied T+8s: NWPathMonitor unexpectedly reports path.status = .unsatisfied with unsatisfiedReason = .notAvailable T+9-10s: NWPathMonitor reports path.status = .satisfied again Connection becomes stable afterward NETWORK PATH TIMELINE: T+0s: satisfied (IPv4: true, DNS: false) T+140ms: satisfied (IPv4: true, DNS: true) T+8.0s: unsatisfied (reason: notAvailable, no interfaces available) T+10.0s: satisfied (IPv4: true, DNS: true) KEY OBSERVATIONS: Timing consistency: unsatisfied event always occurs ~8 seconds after reconnection resolution: "Reset Network Settings" eliminates this behavior TECHNICAL QUESTIONS: What causes the 8-second delayed unsatisfied status after WiFi re-enablement? Is this expected behavior that applications should handle? Why does reset network setting in iPhone fix this issue?

I have a requirement to create a VPN app which only works on Cellular. But I'm facing an issue like when wifi is ON, OS is using wifi interface to route the traffic instead of cellular. I tried some ways like let cellularParams = NWParameters.udp cellularParams.requiredInterfaceType = .cellular But this is not working properly as expected. How can I manually bind to cellular interface in iOS?

Most apps perform ordinary network operations, like fetching an HTTP resource with URLSession and opening a TCP connection to a mail server with Network framework. These operations are not without their challenges, but they’re the well-trodden path. If your app performs ordinary networking, see TN3151 Choosing the right networking API for recommendations as to where to start. Some apps have extra-ordinary networking requirements. For example, apps that: Help the user configure a Wi-Fi accessory Require a connection to run over a specific interface Listen for incoming connections Building such an app is tricky because: Networking is hard in general. Apple devices support very dynamic networking, and your app has to work well in whatever environment it’s running in. Documentation for the APIs you need is tucked away in man pages and doc comments. In many cases you have to assemble these APIs in creative ways. If you’re developing an app with extra-ordinary networking requirements, this post is for you. Note If you have questions or comments about any of the topics discussed here, put them in a new thread here on DevForums. Make sure I see it by putting it in the App & System Services > Networking area. And feel free to add tags appropriate to the specific technology you’re using, like Foundation, CFNetwork, Network, or Network Extension. Links, Links, and More Links Each topic is covered in a separate post: The iOS Wi-Fi Lifecycle describes how iOS joins and leaves Wi-Fi networks. Understanding this is especially important if you’re building an app that works with a Wi-Fi accessory. Network Interface Concepts explains how Apple platforms manage network interfaces. If you’ve got this far, you definitely want to read this. Network Interface Techniques offers a high-level overview of some of the more common techniques you need when working with network interfaces. Network Interface APIs describes APIs and core techniques for working with network interfaces. It’s referenced by many other posts. Running an HTTP Request over WWAN explains why most apps should not force an HTTP request to run over WWAN, what they should do instead, and what to do if you really need that behaviour. If you’re building an iOS app with an embedded network server, see Showing Connection Information in an iOS Server for details on how to get the information to show to your user so they can connect to your server. Many folks run into trouble when they try to find the device’s IP address, or other seemingly simple things, like the name of the Wi-Fi interface. Don’t Try to Get the Device’s IP Address explains why these problems are hard, and offers alternative approaches that function correctly in all network environments. Similarly, folks also run into trouble when trying to get the host name. On Host Names explains why that’s more complex than you might think. If you’re working with broadcasts or multicasts, see Broadcasts and Multicasts, Hints and Tips. If you’re building an app that works with a Wi-Fi accessory, see Working with a Wi-Fi Accessory. If you’re trying to gather network interface statistics, see Network Interface Statistics. There are also some posts that are not part of this series but likely to be of interest if you’re working in this space: TN3179 Understanding local network privacy discusses the local network privacy feature. Calling BSD Sockets from Swift does what it says on the tin, that is, explains how to call BSD Sockets from Swift. When doing weird things with the network, you often find yourself having to use BSD Sockets, and that API is not easy to call from Swift. The code therein is primarily for the benefit of test projects, oh, and DevForums posts like these. TN3111 iOS Wi-Fi API overview is a critical resource if you’re doing Wi-Fi specific stuff on iOS. TLS For Accessory Developers tackles the tricky topic of how to communicate securely with a network-based accessory. A Peek Behind the NECP Curtain discusses NECP, a subsystem that control which programs have access to which network interfaces. Networking Resources has links to many other useful resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision History 2025-07-31 Added a link to A Peek Behind the NECP Curtain. 2025-03-28 Added a link to On Host Names. 2025-01-16 Added a link to Broadcasts and Multicasts, Hints and Tips. Updated the local network privacy link to point to TN3179. Made other minor editorial changes. 2024-04-30 Added a link to Network Interface Statistics. 2023-09-14 Added a link to TLS For Accessory Developers. 2023-07-23 First posted.

Hi everyone, I’m running a dual-homed IPv6-mostly LAN where two on-link routers advertise distinct global Provider-Assigned prefixes (one per ISP). On Linux, the host stack appears to follow RFC 8028. It keeps one default route per prefix, and packets appear to leave through a router that recognises their source address and pass ISP BCP 38 (https://datatracker.ietf.org/doc/bcp38/) checks. On macOS Sequoia, I'm only seeing a single un-scoped default route. As a result, traffic sourced from prefix B often exits via router A and is dropped upstream. Questions: Is the single-default-per-interface model in macOS an intentional design choice or simply legacy behaviour that has not yet been updated to RFC 8028? Does the kernel perform any hidden next-hop selection that isn’t reflected in netstat -rn output? Are there any road-map items for fully adopting RFC 8028 in macOS? As a bonus, I'd be very interested in any info you might be able to provide on the status of implementation/support for https://datatracker.ietf.org/doc/html/rfc8978 (Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events).

I'm developing a safety-critical monitoring app that needs to fetch data from government APIs every 30 minutes and trigger emergency audio alerts for threshold violations. The app must work reliably in background since users depend on it for safety alerts even while sleeping. Main Challenge: iOS background limitations seem to prevent consistent 30-minute intervals. Standard BGTaskScheduler and timers get suspended after a few minutes in background. Question: What's the most reliable approach to ensure consistent 30-minute background monitoring for a safety-critical app where missed alerts could have serious consequences? Are there special entitlements or frameworks for emergency/safety applications? The app needs to function like an alarm clock - working reliably even when backgrounded with emergency audio override capabilities.

Visual Studio 2022 is attempting to use port 11000 instead of 62078, but the port on iOS 18.5 is not listening for VS's Hot Reloading. Is this allowable? If so, how?

(related post: How to optimize my app for for a carrier-provided satellite network? ) I am trying to implement an app so that it works under a carrier-provided satellite network. The app uses (AS)WebAuthenticationSession for signing in. If the app is entitled to access a satellite network, will (AS)WebAuthenticationSession work as well? How about WKWebView and SFSafariViewController? Is there a way to test(simulate) a ultra-constrained network on a device or a simulator to see the expected behavior? Thanks,

when i am running this app on Iphone13 facing these errors On starting Publisher: failed(-11992: Wi-Fi Aware) [L1 ready, local endpoint: , parameters: udp, traffic class: 700, interface: nan0, local: ::.0, definite, attribution: developer, server, port: 65041, path satisfied (Path is satisfied), interface: nan0[802.11], ipv4, uses wifi, LQM: unknown, service: com.example.apple-samplecode.Wi-FiAwareSample94KV3E626L._sat-fileservice._udp scope:0 route:0 custom:107]: waiting(POSIXErrorCode(rawValue: 50): Network is down) [L1 cancelled, local endpoint: , parameters: udp, traffic class: 700, interface: nan0, local: ::.0, definite, attribution: developer, server, port: 65041, path , service: com.example.apple-samplecode.Wi-FiAwareSample94KV3E626L._sat-fileservice._udp scope:0 route:0 custom:107]: ready [L1 cancelled, local endpoint: , parameters: udp, traffic class: 700, interface: nan0, local: ::.0, definite, attribution: developer, server, port: 65041, path , service: com.example.apple-samplecode.Wi-FiAwareSample94KV3E626L._sat-fileservice._udp scope:0 route:0 custom:107]: failed(-11992: Wi-Fi Aware) OnStarting Subscriber : -11992: Wi-Fi Aware B1 <nw_browse_descriptor application_service _sat-simulation._udp bundle_id=com.example.apple-samplecode.Wi-FiAwareSample94KV3E626L device_types=7f device_scope=ff custom:108>, generic, interface: nan0, multipath service: interactive, attribution: developer: failed(-11992: Wi-Fi Aware)

Hello everyone, 👋🏼🤠 I've been struggling with a persistent issue for several weeks and would greatly appreciate any insights or suggestions from the community. ❗️Problem Summary We are sending JSON requests (~100 KB in size) via URLSession from a Swift app running on Windows. These requests consistently time out after a while. Specifically, we receive the following error: Error Domain=NSURLErrorDomain Code=-1001 "(null)" This only occurs on Windows – under macOS and Linux, the same requests work perfectly. 🔍 Details The server responds in under 5 seconds, and we have verified that the backend (a Vapor app in Kubernetes) is definitely not the bottleneck. The request always hits the timeout interval, no matter how high we configure it: 60, 120, 300, 600 seconds – the error remains the same. (timeoutForRequest) The request flow: Swift App (Windows) ---> HTTPS ---> Load Balancer (NGINX) ---> HTTP ---> Ingress Controller ---> Vapor App (Kubernetes) On the load balancer we see this error: client prematurely closed connection, so upstream connection is closed too (104: Connection reset by peer) The Ingress Controller never receives the complete body in these error cases. The content length set by the Swift app exceeds the data actually received. We disabled request buffering in the Ingress Controller, but the issue persists. We even tested a setup where we inserted a Caddy server in between to strip away TLS. The Swift app sent unencrypted HTTP requests to Caddy, which then forwarded them. This slightly improved stability but did not solve the issue. 🧪 Additional Notes The URLSession is configured in an actor, with a nonisolated URLSession instance: actor DataConnectActor { nonisolated let session : URLSession = URLSession(configuration: { let urlSessionConfiguration : URLSessionConfiguration = URLSessionConfiguration.default urlSessionConfiguration.httpMaximumConnectionsPerHost = ProcessInfo.processInfo.environment["DATACONNECT_MAX_CONNECTIONS"]?.asInt() ?? 16 urlSessionConfiguration.timeoutIntervalForRequest = TimeInterval(ProcessInfo.processInfo.environment["DATACONNECT_REQUEST_TIMEOUT"]?.asInt() ?? 120) urlSessionConfiguration.timeoutIntervalForResource = TimeInterval(ProcessInfo.processInfo.environment["DATACONNECT_RESSOURCE_TIMEOUT"]?.asInt() ?? 300) urlSessionConfiguration.httpAdditionalHeaders = ["User-Agent": "DataConnect Agent (\(Environment.version))"] return urlSessionConfiguration }()) public internal(set) var accessToken: UUID? = nil ... } Requests are sent via a TaskGroup, limited to 5 concurrent tasks. The more concurrent tasks we allow, the faster the timeout occurs. We already increased the number of ephemeral ports in Windows. This made things slightly better, but the problem remains. Using URLSessionDebugLibcurl=1 doesn't reveal any obvious issue related to libcurl. We have also implemented a retry mechanism, but all retries also time out. 🔧 Request Flow (Code Snippet Summary) let data = try JSONEncoder().encode(entries) var request = URLRequest(url: url) request.httpMethod = "POST" request.httpBody = data request.setValue("Bearer \(token)", forHTTPHeaderField: "Authorization") request.setValue("application/json; charset=UTF-8", forHTTPHeaderField: "Content-Type") // additional headers... let (responseData, response) = try await urlSession.data(for: request) ✅ What We’ve Tried Tested with and without TLS Increased timeout and connection settings Disabled buffering on Ingress Increased ephemeral ports on Windows Limited concurrent requests Used URLSessionDebugLibcurl=1 We don't know how we can look any further here. Thank you in advance for any guidance!

Problem : Connection error occurs in iOS26 beta while connecting to the device's softap via commercial app (Socket exception errSSLfeerBadCert CFSreamErrorDomainSSL code -9825). iOS 18 release version does not occur. Why does it cause problems? Does the iOS 26 version not cause problems? Is there a way to set it up in the app so that the iOS 26 beta doesn't cause problems? error : "alias":"SOCKET_LOG", "additional":{"currentNetworkStatus":"socket e=errSSLPeerBadCert ns WifiStatus: Connected Error Domain kCFStreamErrorDomainSSL Code-9825 "(null)" UserInfo={NSLocalizedRecoverySuggestion=Error code definition can be found in Apple's SecureTransport.h} Description : It's an issue that happens when you connect our already mass-produced apps to our home appliances (using SoftAP), and it's currently only happening in iOS 26 beta. This particular issue didn't appear until iOS 18 version. Let me know to make sure that this issue will persist with the official release of iOS 26? If the issue continues to occur with the official version, would you share any suggestions on how to mitigate or avoid it. Also, it would be helpful to find out if there are known solutions or processes such as exemptions to fix this issue.

I am developing a macOS application (targeting macOS 13 and later) that is non-sandboxed and needs to install and trust a root certificate by adding it to the System keychain programmatically. I’m fine with prompting the user for admin privileges or password, if needed. So far, I have attempted to execute the following command programmatically from both: A user-level process A root-level process sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.pem While the certificate does get installed, it does not appear as trusted in the Keychain Access app. One more point: The app is not distributed via MDM. App will be distributed out side the app store. Questions: What is the correct way to programmatically install and trust a root certificate in the System keychain? Does this require additional entitlements, signing, or profile configurations? Is it possible outside of MDM management? Any guidance or working samples would be greatly appreciated.

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?

I'm creating a simple p2p server to advertise a service: // server let txtRecord = NWTXTRecord(["key": "value"]) NWListener.Service(name: name, type: "_p2p._tcp", domain: nil, txtRecord: txtRecord) and client to look that service up: // client switch result.endpoint { case let .service(name: name, type: type, domain: domain, interface: interface): print(result.metadata) The client is getting the advertisement ok, but metadata is nil. I expected to see a txt record there, is that not supported? public let metadata: NWBrowser.Result.Metadata /// Additional metadata provided to the browser by a service. Currently, /// only Bonjour TXT records are supported. Is the above server making a Bonjour TXT record or something else? Basically what I want is to pass a short key/value data as part of advertisement.

IMPORTANT The resume rate limiter is now covered by the official documentation. See Use background sessions efficiently within Downloading files in the background. So, the following is here purely for historical perspective. NSURLSession’s background session support on iOS includes a resume rate limiter. This limiter exists to prevent apps from abusing the background session support in order to run continuously in the background. It works as follows: nsurlsessiond (the daemon that does all the background session work) maintains a delay value for your app. It doubles that delay every time it resumes (or relaunches) your app. It resets that delay to 0 when the user brings your app to the front. It also resets the delay to 0 if the delay period elapses without it having resumed your app. When your app creates a new task while it is in the background, the task does not start until that delay has expired. To understand the impact of this, consider what happens when you download 10 resources. If you pass them to the background session all at once, you see something like this: Your app creates tasks 1 through 10 in the background session. nsurlsessiond starts working on the first few tasks. As tasks complete, nsurlsessiond starts working on subsequent ones. Eventually all the tasks complete and nsurlsessiond resumes your app. Now consider what happens if you only schedule one task at a time: Your app creates task 1. nsurlsessiond starts working on it. When it completes, nsurlsessiond resumes your app. Your app creates task 2. nsurlsessiond delays the start of task 2 a little bit. nsurlsessiond starts working on task 2. When it completes, nsurlsessiond resumes your app. Your app creates task 3. nsurlsessiond delays the start of task 3 by double the previous amount. nsurlsessiond starts working on task 3. When it completes, nsurlsessiond resumes your app. Steps 8 through 11 repeat, and each time the delay doubles. Eventually the delay gets so large that it looks like your app has stopped making progress. If you have a lot of tasks to run then you can mitigate this problem by starting tasks in batches. That is, rather than start just one task in step 1, you would start 100. This only helps up to a point. If you have thousands of tasks to run, you will eventually start seeing serious delays. In that case it’s much better to change your design to use fewer, larger transfers. Note All of the above applies to iOS 8 and later. Things worked differently in iOS 7. There’s a post on DevForums that explains the older approach. Finally, keep in mind that there may be other reasons for your task not starting. Specifically, if the task is flagged as discretionary (because you set the discretionary flag when creating the task’s session or because the task was started while your app was in the background), the task may be delayed for other reasons (low power, lack of Wi-Fi, and so on). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" (r. 22323366)

Question: What is the standard, most reliable way to manage temporary files associated with a URLSessionDownloadTask that has been terminated abnormally due to a network error or other issues? Details Hello, I'm currently developing a feature to download multiple files concurrently on iOS using URLSessionDownloadTask, and I have a question regarding the lifecycle of the temporary files created during this process. As I understand it, URLSessionDownloadTask stores incoming data in a temporary file within the tmp directory, typically with a name like CFNetworkDownload_*.tmp. In my testing, temporary files are managed correctly in the normal scenario. For instance, when I call the cancel() method on an active downloadTask and then release all references to it, the corresponding temporary file is automatically cleaned up from the tmp directory shortly after. However, the problem occurs when a download is interrupted abnormally due to external factors, such as a lost network connection. In this situation, the urlSession(_:task:didCompleteWithError:) delegate method is called, but the associated temporary file is not deleted and remains in the tmp directory. I've observed a particularly interesting behavior related to this. Immediately after the error occurs, if I check my app's storage usage in the iOS Settings app, the data size appears to have decreased momentarily. However, the tmp file has not actually been deleted, and after a short while, the storage usage is recalculated to include the size of this orphaned temporary file. Since my app does not support resuming interrupted downloads, these leftover files become orphaned and unnecessarily consume storage. Therefore, I want to ensure they are all reliably deleted. With this context, I'd like to ask the community: What is the standard, most reliable way to manage temporary files associated with a URLSessionDownloadTask that has been terminated abnormally due to a network error or other issues? I am wondering if there is an official guide or a framework-level API to handle these orphaned files. I would appreciate any advice from those with experience in this area. Thank you.

At WWDC 25, Dr. Swetank mentioned, “DeviceDiscoveryUI is for making connections between apps and from an app to another device. It supports pairing with both Apple and third-party devices.” I find the pairing process in DeviceDiscoveryUI via Wi-Fi Aware intriguing. I have two questions: Can we pair devices via Bluetooth first and then establish a Wi-Fi Aware connection? If I use DeviceDiscoveryUI, how should I write an Android program to correspond with it and achieve iPhone-Android pairing? The app is an official Apple app: https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps.

Do we have clear document around multiple content filter applications running on single device.? While the documentation says 8 content filters and Only one filter available for system-wide use, there is no clear mention about below scenarios - Which content filter will get precedence? System-wide or App managed? Can there be mulitple Content filters configured for same managed application? Will all control provider running on the device get notified about network traffic ? I searched the forums to get a clear answer but seems older threads where nothing was conclusive. Thanks in advance for the help !!

Hello! I have a quirky situation that I am looking for a solution to. The iOS app I am working on needs to be able to communicate with systems that do not have valid root certs. Furthermore, these systems addresses will be sent to the user at run time. The use case is that administrators will provide a self signed certificate (.pem) for the iPhones to download which will then be used to pass the authentication challenge. I am fairly new to customizing trust and my understanding is that it is very easy to do it incorrectly and expose the app unintentionally. Here is our users expected workflow: An administrator creates a public ip server. The ip server is then configured with dns. A .pem file that includes a self signed certificate is created for the new dns domain. The pem file is distributed to iOS devices to download and enable trust for. When they run the app and attempt to establish connection with the server, it will not error with an SSL error. When I run the app without modification to the URLSessionDelegate method(s) I do get an SSL error. Curiously, attempting to hit the same address in Safari will not show the insecure warning and proceed without incident. What is the best way to parity the Safari use case for our app? Do I need to modify the urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) method to examine the NSURLAuthenticationMethodServerTrust? Maybe there is a way to have the delegate look through all the certs in keychain or something to find a match? What would you advise here? Sincerely thank you for taking the time to help me, ~Puzzled iOS Dev