Before iOS16, we can use https://developer.apple.com/documentation/coretelephony/ctcarrier But after iOS this is deprecated and has no replacement. There are some discussions on it, eg. https://developer.apple.com/forums/thread/714876 https://developer.apple.com/forums/thread/770400 Now I asked AI, then it provided this solution, to check the serviceCurrentRadioAccessTechnology, so it this ok to check the SIM card status? var hasSIMCard = false let info = CTTelephonyNetworkInfo() if let rat = info.serviceCurrentRadioAccessTechnology, rat.values.contains(where: { !$0.isEmpty }) { hasSIMCard = true. // has RAT } BTW, I can see a lot of changes in the Core Telephony framework. https://developer.apple.com/documentation/coretelephony 1.isSIMInserted https://developer.apple.com/documentation/coretelephony/ctsubscriber/issiminserted A Boolean property that indicates whether a SIM is present. iOS 18.0+ iPadOS 18.0+ This value property is true if the system finds a SIM matching the Info.plist carrier information (MCC / MNC / GID1 / GID2). Is this ok to check SIM insert status, this seems must preconfig some info in the info.plist. 2.iOS26 provide CTCellularPlanStatus https://developer.apple.com/documentation/coretelephony/ctcellularplanstatus Can I use this to check SIM status?

I'm a long-time developer, but pretty new to Swift. I'm trying to get information from a web service (and found code online that I adjusted to build the function below). (Note: AAA_Result -- referenced towards the end -- is another class in my project) Trouble is, I'm getting the subject error on the call to session.dataTask. Any help/suggestions/doc pointers will be greatly appreciated!!! var result: Bool = false var cancellable: AnyCancellable? self.name = name let params = "json={\"\"}}" // removed json details let base_url = URL(string: "https://aaa.yyy.com?params=\(params)&format=json")! // removed URL specifics do { let task = URLSession.shared.dataTask(with: base_url) { data, response, error in if let error = error { print("Error: \(error)") } guard let response = response as? HTTPURLResponse, (200...299).contains(response.statusCode) else { print("Error \(String(describing: response))") } do { let decoder = JSONDecoder() let ar = try decoder.decode(AAA_Result.self, from: response.value) // removed specific details... result = true } catch { print(error) } } task.resume() } catch { print(error) } return result }

Hi everyone 👋 As a network engineer and indie iOS developer, I couldn’t find a lightweight mobile tool that fully supports IPv4/IPv6 dual-stack diagnostics — so I built NetToolbox -All-In-One Utility for engineers, DevOps, and developers. Here are its core features that solve real mobile networking pain points: One-Click Full Diagnostics: Integrates ping, traceroute, and multi-type DNS queries (A/AAAA/CNAME) — no need to switch between apps IPv4/IPv6 Dual-Stack Support: Seamlessly works in IPv6-only networks, with the ability to test connectivity differences between dual-stack environments LAN Device Scanning: Quickly identifies all devices on the same network segment and checks port availability Offline Functionality: Diagnostic logic is stored locally, enabling LAN troubleshooting without an internet connection Lightweight Design: 5MB install size, no storage bloat, and low power consumption during operation Dark Mode Support: Tailored for developers who work late at night During development, I leveraged Apple Intelligence alongside Claude Code and Gemini 3 to accelerate the process, optimize iOS native networking stack adaptation and local storage logic, and significantly boost development efficiency. I’d love to hear from the community: What must-have features are missing from mobile network diagnostic tools? Do you have experience optimizing iOS workflows with Apple Intelligence? 👉 You can try the app here: https://apps.apple.com/us/app/nettoolbox-all-in-one-utility/id6757392404 Feedback is highly appreciated — I’ll keep iterating to make it better! 🚀

Just bought a macbook pro m4, im trying to run an api on port 5000, disabled airplay receiver, checked processes, ghost ones, hidden ones, and stuck ones. I didn't find a thing using the port, but i still get port in use.

Every now and again folks notice that Network framework seems to create an unexpected number of connections on the wire. This post explains why that happens and what you should do about it. If you have questions or comments, put them in a new thread here on the forums. Use the App & System Services > Networking topic area and the Network tag. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Understanding Also-Ran Connections Network framework implements the Happy Eyeballs algorithm. That might create more on-the-wire connections than you expect. There are two common places where folks notice this: When looking at a packet trace When implementing a listener Imagine that you’ve implemented a TCP server using NWListener and you connect to it from a client using NWConnection. In many situations there are multiple network paths between the client and the server. For example, on a local network there’s always at least two paths: the link-local IPv6 path and either an infrastructure IPv4 path or the link-local IPv4 path. When you start your NWConnection, Network framework’s Happy Eyeballs algorithm might [1] start a TCP connection for each of these paths. It then races those connections. The one that connects first is the ‘winner’, and Network framework uses that connection for your traffic. Once it has a winner, the other connections, the also-ran connections, are redundant, and Network framework just closes them. You can observe this behaviour on the client side by looking in the system log. Many Network framework log entries (subsystem com.apple.network) contain a connection identifier. For example C8 is the eighth connection started by this process. Each connection may have child connections (C8.1, C8.2, …) and grandchild connections (C8.1.1, C8.1.2, …), and so on. You’ll see state transitions for these child connections occurring in parallel. For example, the following log entries show that C8 is racing the connection of two grandchild connections, C8.1.1 and C8.1.2: type: debug time: 12:22:26.825331+0100 process: TestAlsoRanConnections subsystem: com.apple.network category: connection message: nw_socket_connect [C8.1.1:1] Calling connectx(…) type: debug time: 12:22:26.964150+0100 process: TestAlsoRanConnections subsystem: com.apple.network category: connection message: nw_socket_connect [C8.1.2:1] Calling connectx(…) Note For more information about accessing the system log, see Your Friend the System Log. You also see this on the server side, but in this case each connection is visible to your code. When you connect from the client, Network framework calls your listener’s new connection handler with multiple connections. One of those is the winning connection and you’ll receive traffic on it. The others are the also-ran connections, and they close promptly. IMPORTANT Depending on network conditions there may be no also-ran connections. Or there may be lots of them. If you want to test the also-ran connection case, use Network Link Conditioner to add a bunch of delay to your packets. You don’t need to write special code to handle also-ran connections. From the perspective of your listener, these are simply connections that open and then immediately close. There’s no difference between an also-ran connection and, say, a connection from a client that immediately crashes. Or a connection generated by someone doing a port scan. Your server must be resilient to such things. However, the presence of these also-ran connections can be confusing, especially if you’re just getting started with Network framework, and hence this post. [1] This is “might” because the exact behaviour depends on network conditions. More on that below.

Hi, I am making a AI-Powered app that makes api requests to the openai API. However, for security, I set up a vercel backend that handles the API calls securely, while my frontend makes a call to my vercel-hosted https endpoint. Interestingly, whenever I try to make that call on my device, an iPhone, I get this error: Task <91AE4DE0-2845-4348-89B4-D3DD1CF51B65>.<10> finished with error [-1003] Error Domain=NSURLErrorDomain Code=-1003 "A server with the specified hostname could not be found." UserInfo={_kCFStreamErrorCodeKey=-72000, NSUnderlyingError=0x1435783f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1003 "(null)" UserInfo={_kCFStreamErrorDomainKey=10, _kCFStreamErrorCodeKey=-72000, _NSURLErrorNWResolutionReportKey=Resolved 0 endpoints in 3ms using unknown from query, _NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: pdp_ip0[lte], ipv4, ipv6, dns, expensive, uses cell}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <91AE4DE0-2845-4348-89B4-D3DD1CF51B65>.<10>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <91AE4DE0-2845-4348-89B4-D3DD1CF51B65>.<10>" ), NSLocalizedDescription=A server with the specified hostname could not be found., NSErrorFailingURLStringKey=https://[my endpoint], NSErrorFailingURLKey=https://[my endpoint], _kCFStreamErrorDomainKey=10} I'm completely stuck because when I directly make https requests to other api's like openai's endpoint, without the proxy, it finds the server completely fine. Running my endpoint on terminal with curl also works as intended, as I see api key usages. But for some reason, on my project, it does not work. I've looked through almost every single post I could find online, but a lot all of the solutions are outdated and unhelpful. I'm willing to schedule a call, meeting, whatever to resolve this issue and get help more in depth as well.

This is a bit complicated to explain so bare with me. I am working on building an app that allows you to send real time video/camera captures from one Apple device to another. I am using a custom UDP protocol built on top of NWListener, NWBrowser, and NWConnection APIs. It works fine, but there are a few issues that seems to all be related to awdl: When transmitting via WiFi over the router (not using peer-to-peer), there are periodic interruptions when the wireless card on the device changes channels for awdl polling. This is resolved by changing the 5GHz WiFi channel on the router to channel 149 (or disabling AWDL altogether which is not really feasible). In order to work around number 1, I decided to build in an option to toggle/prefer peer-to-peer transmission in the app thinking that if everything goes over a peer-to-peer connection the jitter caused from the channel switching should go away. This also works, but with an important caveat. The default transmission is extremely choppy until you take an OS action that “elevates” the AWDL connection into “realtime” mode. I am using includePeerToPeer on the listener, browser, and connection as well as serviceClass interactiveVideo. For number 1, you can understand that asking users to change the channel on their router is not a great user experience, but the problem is the peer-to-peer connection workaround is also not great by default. For number 2, as an example of the behavior, I can send a stream from my Mac to my iPad over a peer-to-peer connection and it works but the video is very choppy until I move my cursor from my Mac to my iPad to trigger Universal Control. I captured the OS logs while doing this and can confirm that something happens to trigger “realtime” mode on the AWDL connection. After that, the streaming is totally smooth with zero latency. Some log samples: 2026-03-19 12:42:01.277968-0400 0x1ae294c Default 0x0 495 3 rapportd: (CoreUtils) [com.apple.rapport:CLinkD] Update client from UniversalControl:697 2026-03-19 12:42:01.278031-0400 0x1ae294c Default 0x0 495 0 rapportd: (CoreUtils) [com.apple.CoreUtils:AsyncCnx] CLinkCnx-6089: Connect start: 'CLink-ed3b9618b4e0._companion-link._tcp.local.%13' 2026-03-19 12:42:01.278149-0400 0x1ae294c Default 0x0 495 0 rapportd: (CoreUtils) [com.apple.CoreUtils:AsyncCnx] CLinkCnx-6089: Querying SRV CLink-ed3b9618b4e0._companion-link._tcp.local.%13 2026-03-19 12:42:01.279454-0400 0x1ae253a Info 0x0 382 0 wifip2pd: [com.apple.awdl:datapathInitiator] Created AWDLDatapathInitiator clink-ed3b9618b4e0._companion-link._tcp.local <To: 2e:f2:5a:15:76:52> 2026-03-19 12:42:01.279498-0400 0x1ae294c Default 0x0 495 0 rapportd: (CoreUtils) [com.apple.CoreUtils:AsyncCnx] CLinkCnx-6089: Resolving DNS f970afcc-1f1c-47af-a3f3-0236c9f9bbb0.local.%13 2026-03-19 12:42:01.279588-0400 0x1ae253a Default 0x0 382 0 wifip2pd: [com.apple.awdl:datapathInitiator] AWDLDatapathInitiator clink-ed3b9618b4e0._companion-link._tcp.local <To: 2e:f2:5a:15:76:52> was started 2026-03-19 12:42:01.282537-0400 0x1ae294c Default 0x0 495 0 rapportd: (Network) [com.apple.network:path] nw_path_evaluator_start [5C54D967-624D-4269-B080-6C7AE63218C7 IPv6#1e905043%awdl0.49154 generic, attribution: developer] path: satisfied (Path is satisfied), interface: awdl0[802.11], dns, uses wifi 2026-03-19 12:42:01.596450-0400 0x1ae253a Debug 0x0 382 0 wifip2pd: [com.apple.awdl:driver] Received event realtimeMode 2026-03-19 12:42:01.596589-0400 0x1ae253a Default 0x0 382 0 wifip2pd: [com.apple.awdl:interface] Realtime mode updated true I noticed that on iOS 26 and iPadOS 26 a realtime mode was added specifically to the Wi-Fi Aware API which I assume does what I want: https://developer.apple.com/documentation/wifiaware/waperformancemode/realtime, but I am looking for a solution that works with the existing network API and also on previous OS versions. I have already tried a lot of things, but is there any way to programmatically trigger “realtime” mode? For additional context, the goal here is to have extremely low latency that also works for gaming. The actual latency introduced in 1 is approximately 30-50ms around once a second… adding a buffer to the stream makes the video completely smooth, but the extra delay on the receiver end is not acceptable for this use case. Any help or ideas would be appreciated. I can’t easily share a reproduce case right now, and even if I could, getting multiple devices into the exact state along with the router configuration in order to reproduce is going to be pretty difficult anyway.

Every now and again I end up helping a developer with a Wi-Fi issue. These fall into two groups: User-level Wi-Fi issues Development Wi-Fi issues A user-level Wi-Fi issue is one where the developer hasn’t created any of the products involved. An example of this is when you’re developing an app for an accessory and iOS is having problems connecting to that accessory but you don’t control the accessory’s firmware. In general, I recommend that you escalate such issues to the accessory vendor. They can then run their own investigation and, if necessary, file their own bug report. A development Wi-Fi issue is one that directly affects one of your products. For example, you’re developing a Wi-Fi accessory and iOS is having problems connecting to it. In that case, the onus is on you [1] to investigate why things are failing. If your conclusion is that iOS is behaving incorrectly, file a bug about that. IMPORTANT If you do file a bug in the context of some forums thread, please post your bug number to the thread, just for the record. When filing this sort of bug report it’s important to provide: Solid evidence that the problem is on the Apple side of the fence Enough information for Apple’s engineers to investigate it effectively Let’s start with that second point. If you can reproduce the problem reliably, install the Wi-Fi debug profile on your device, reproduce the problem, noting down a rough timestamp, and include the resulting logs and that timestamp in your bug report. Also, consider attaching a packet trace. There are three options here: Record a packet trace from the perspective of the Apple device. On iOS, use an RVI packet trace for this. Record a packet trace from the perspective of your accessory. Record a Wi-Fi level packet trace. You can do this from your Mac (see Recording a Wi-Fi Packet Trace) but it might be easier to do this with the infrastructure you used during the bring up of your accessory. It’s fine to include all three (-: Also include any relevant context about the issue. For example: If the issue is tied to a specific device model (In that case, it’d be good to include the above information for both the successful and failing cases.) If the problem shows up when joining from Settings > Wi-Fi, or whether it’s tied to a specific API, like NEHotspotConfigurationManager Finally, make sure to include an explanation of why you think this is an Apple bug, referencing specific items in the logs and packet traces that you attached. Of course, it’s only possible to do all of this if you can reproduce the problem. Investigating an intermittent issue based on reports coming in from users is much harder. It’s OK to file a bug about such issues, but your bug might not be actionable. At a minimum you should aim to include a sysdiagnose log with your bug. IMPORTANT This log has to be taken shortly after reproducing the problem. Don’t just attach any old log. One option is to request such a log from your users. I talk more about this in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. You can also ask your users to file their own bugs using the Feedback Assistant app. It should automatically capture and attach a sysdiagnose log. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] Well, your organisation. It’s rare to find a team where the same engineer works on both the iOS app and the accessory firmware. But if that’s you, good job!

We’re looking to implement a custom IPSec IKEv2 VPN using the Packet Tunnel Provider network extension on iOS because we need to add extra information to EAP, which the built-in IKEv2 VPN configuration does not support. Is it possible to handle the full IKEv2 negotiation and IPSec tunneling within the Packet Tunnel Provider extension? Or are there limitations that would prevent implementing a full IKEv2 stack this way? Any insights or alternative approaches would be appreciated. Thanks!

multicast sockets fail to send/receive on macosx, errno 65 "no route to host". Wireshark and Terminal.app (which have root privileges) both show incoming multicast traffic just fine. Normal UDP broadcast sockets have no problems. Toggling the Security&Privacy -> Local Network setting may fix the problem for some Users. There is no pattern for when multicast socket fails. Sometimes, recreating the sockets fix the problem. Restart the app, sometimes multicast fails, sometimes success (intermittent, no pattern). Reboot machine (intermittent fail) Create a fresh new user on machine, install single version of app, give app permission. (intermittent fail, same as above). We have all the normal entitlements / notarized app. Similar posts here see FB16923535, Related to FB16512666 https://forum.xojo.com/t/udp-multicast-receive-on-mac-failing-intermittant/83221 see my post from 2012 "distinguishing between SENDING sockets and RECEIVING sockets" for source code example of how we bind multicast sockets. Our other socket code is standard "Stevens, et al." code. The bind() is the call that fails in this case. https://stackoverflow.com/questions/10692956/what-does-it-mean-to-bind-a-multicast-udp-socket . Note that this post from 2012 is still relevant, and that it is a workaround to a longstanding Apple bug that was never fixed. Namely, "Without this fix, multicast sending will intermittently get sendto() errno 'No route to host'. If anyone can shed light on why unplugging a DHCP gateway causes Mac OS X multicast SENDING sockets to get confused, I would love to hear it." This may be a hint as to the underlying bug that Apple really needs to fix, but if it's not, then please Apple, fix the Sequoia bug first. These are probably different bugs because in one case, sendto() fails when a socket becomes "unbound" after you unplug an unrelated network cable. In this case, bind() fails, so sendto() is never even called. Note, that we have also tried to use other implementations for network discovery, including Bonjour, CFNetwork, etc. Bonjour fails intermittently, and also suffers from both bugs mentioned above, amongst others.

Dear Apple Developer Technical Support, I am currently developing a macOS network filtering solution using NetworkExtension with NEFilterDataProvider. During implementation of the handleOutboundData logic, we are using the following verdict: NEFilterNewFlowVerdict.filterDataVerdict( withFilterInbound: true, peekInboundBytes: InboundPeekBytes, filterOutbound: true, peekOutboundBytes: OutboundPeekBytes ) However, we have encountered an issue when SMB traffic is involved. When SMB protocol communication occurs, the network connection occasionally becomes unresponsive or appears to stall when peekOutboundBytes is set to a large value. Through testing, we observed the following behavior: On some systems, reducing the peekOutboundBytes value allows SMB communication to proceed normally. On other systems, even relatively small values can still cause the SMB connection to stall. This behavior appears inconsistent across different macOS environments. Because of this, we would like to clarify the following: Is there a documented or recommended maximum value for peekOutboundBytes when using NEFilterNewFlowVerdict.filterDataVerdict? Are there any internal limits or constraints within NetworkExtension that could cause SMB traffic to stall when the peek buffer size is too large? Are there best practices for selecting appropriate peekInboundBytes / peekOutboundBytes values when filtering high-throughput protocols such as SMB? If necessary, we can provide additional information such as macOS version, test environment details, and logs. Thank you for your assistance. Best regards, sangho

Hello, I'm running into an issue while developing an iOS app that requires local network access. I’m using the latest MacBook Air M4 with macOS sequoia 15.5 and Xcode 16.1. In the iOS Simulator, my app fails to discover devices connected to the same local network. I’ve already added the necessary key to the Info.plist: NSLocalNetworkUsageDescription This app needs access to local network devices. When I run the app on a real device and M2 Chip Macbook's simulators, it works fine for local network permission as expected. However, in the M4 Chip Macbook's Simulator: The app can’t find any devices on the local network Bonjour/mDNS seems not to be working as well I’ve tried the following without success: Restarting Simulator and Mac Resetting network settings in Simulator Confirming app permissions under System Settings > Privacy & Security Has anyone else encountered this issue with the new Xcode/macOS combo? Is local network access just broken in the Simulator for now, or is there a workaround? Thanks in advance!

We are assisting a client with their app integration. The client believes that NEPacketTunnelProvider, NEHotspotHelper, and NEHotspotManager extensions stop functioning if the containing app hasn't been launched by the user within some recent window (e.g. 30, 60, or 90 days). We haven't been able to find any documentation supporting this claim. Specifically, we'd like to know: Is there any app launch recency requirement that would cause iOS to stop invoking a registered NEHotspotHelper or NEHotspotManager configuration? Is there any app launch recency requirement that would cause iOS to tear down or prevent activation of a NEPacketTunnelProvider? More generally, does iOS enforce any kind of "staleness" check on apps that provide Network Extension or Hotspot-related functionality, where not being foregrounded for some period causes the system to stop honoring their registrations? If such a mechanism exists, we'd appreciate any pointers to documentation or technical notes describing the behavior and timeframes involved. If it doesn't exist, confirmation would help us guide our client's debugging in the right direction. Thank you.

cant open this website: https://appstoreconnect.apple.com/apps  Bad Gateway Correlation Key: EJMQBY3TQQI6QR2RBCFRFK7WSM

Hello everyone, I'm trying to figure out how to transmit a UIImage (png or tiff) securely to an application running in my desktop browser (Mac or PC). The desktop application and iOS app would potentially be running on the same local network (iOS hotspot or something) or have no internet connection at all. I'm trying to securely send over an image that the running desktop app could ingest. I was thinking something like a local server securely accepting image data from an iPhone. Any suggestions ideas or where to look for more info would be greatly appreciated! Thank you for your help.

This is just an FYI in case someone else runs into this problem. This afternoon (12 Dec 2025), I updated to macOS 26.2 and lost my network. The System Settings' Wi-Fi light was green and said it was connected, but traceroute showed "No route to host". I turned Wi-Fi on & off. I rebooted the Mac. I rebooted the eero network. I switched to tethering to my iPhone. I switched to physical ethernet cable. Nothing worked. Then I remembered I had a beta of an app with a network system extension that was distributed through TestFlight. I deleted the app, and networking came right back. I had this same problem ~2 years ago. Same story: app with network system extension + TestFlight + macOS update = lost network. (My TestFlight build might have expired, but I'm not certain) I don't know if anyone else has had this problem, but I thought I'd share this in case it helps.

I want to add more cipher suites. I use NWConnection to make a connection. Before I use sec_protocol_options_append_tls_ciphersuite method to add more cipher suites, I found that Apple provided 20 cipher suites shown in the client hello packet. But after I added three more cipher suites, I found that nothing changed, and still original 20 cipher suites shown in the client hello packet when I made a new connection. The following is the code about connection. I want to add three more cipher suites: tls_ciphersuite_t.ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, tls_ciphersuite_t.ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, tls_ciphersuite_t.ECDHE_RSA_WITH_AES_256_CBC_SHA384 Can you give me some advice about how to add more cipher suites? Thanks. By the way, I working on a MacOS app. Xcode version: 16 MacOS version: 15.6

Hello, I have implemented a URL Filter using the sample provided here: Filtering Traffic by URL. I am also using an App Group to dynamically manage the Bloom filter and block list data. However, when I update my block list URLs and create a new Bloom filter plist in the App Group, the extension does not seem to use the updated Bloom filter even after the prefetch interval expires. Also for testing purpose can I keep this interval to 10 mins or below ?

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)

From time to time the subject of NECP grows up, both here on DevForums and in DTS cases. I’ve posted about this before but I wanted to collect those tidbits into single coherent post. If you have questions or comments, start a new thread in the App & System Services > Networking subtopic and tag it with Network Extension. That way I’ll be sure to see it go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" A Peek Behind the NECP Curtain NECP stands for Network Extension Control Protocol. It’s a subsystem within the Apple networking stack that controls which programs have access to which network interfaces. It’s vitally important to the Network Extension subsystem, hence the name, but it’s used in many different places. Indeed, a very familiar example of its use is the Settings > Mobile Data [1] user interface on iOS. NECP has no explicit API, although there are APIs that are offer some insight into its state. Continuing the Settings > Mobile Data example above, there is a little-known API, CTCellularData in the Core Telephony framework, that returns whether your app has access to WWAN. Despite having no API, NECP is still relevant to developers. The Settings > Mobile Data example is one place where it affects app developers but it’s most important for Network Extension (NE) developers. A key use case for NECP is to prevent VPN loops. When starting an NE provider, the system configures the NECP policy for the NE provider’s process to prevent it from using a VPN interface. This means that you can safely open a network connection inside your VPN provider without having to worry about its traffic being accidentally routed back to you. This is why, for example, an NE packet tunnel provider can use any networking API it wants, including BSD Sockets, to run its connection without fear of creating a VPN loop [1]. One place that NECP shows up regularly is the system log. Next time you see a system log entry like this: type: debug time: 15:02:54.817903+0000 process: Mail subsystem: com.apple.network category: connection message: nw_protocol_socket_set_necp_attributes [C723.1.1:1] setsockopt 39 SO_NECP_ATTRIBUTES … you’ll at least know what the necp means (-: Finally, a lot of NECP infrastructure is in the Darwin open source. As with all things in Darwin, it’s fine to poke around and see how your favourite feature works, but do not incorporate any information you find into your product. Stuff you uncover by looking in Darwin is not considered API. [1] Settings > Cellular Data if you speak American (-: [2] Network Extension providers can call the createTCPConnection(to:enableTLS:tlsParameters:delegate:) method to create an NWTCPConnection [3] that doesn’t run through the tunnel. You can use that if it’s convenient but you don’t need to use it. [3] NWTCPConnection is now deprecated, but there are non-deprecated equivalents. For the full story, see NWEndpoint History and Advice. Revision History 2025-12-12 Replaced “macOS networking stack” with “Apple networking stack” to avoid giving the impression that this is all about macOS. Added a link to NWEndpoint History and Advice. Made other minor editorial changes. 2023-02-27 First posted.