For important background information, read Extra-ordinary Networking before reading this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Working with a Wi-Fi Accessory Building an app that works with a Wi-Fi accessory presents specific challenges. This post discusses those challenges and some recommendations for how to address them. Note While my focus here is iOS, much of the info in this post applies to all Apple platforms. IMPORTANT iOS 18 introduced AccessorySetupKit, a framework to simplify the discovery and configuration of an accessory. I’m not fully up to speed on that framework myself, but I encourage you to watch WWDC 2024 Session 10203 Meet AccessorySetupKit and read the framework documentation. IMPORTANT iOS 26 introduced WiFiAware, a framework for setting up communication with Wi-Fi Aware accessories. Wi-Fi Aware is an industry standard to securely discover, pair, and communicate with nearby devices. This is especially useful for stand-alone accessories (defined below). For more on this framework, watch WWDC 2025 Session 228 Supercharge device connectivity with Wi-Fi Aware and read the framework documentation. For information on how to create a Wi-Fi Aware accessory that works with iPhone, go to Developer > Accessories, download Accessory Design Guidelines for Apple Devices, and review the Wi-Fi Aware chapter. Accessory Categories I classify Wi-Fi accessories into three different categories. A bound accessory is ultimately intended to join the user’s Wi-Fi network. It may publish its own Wi-Fi network during the setup process, but the goal of that process is to get the accessory on to the existing network. Once that’s done, your app interacts with the accessory using ordinary networking APIs. An example of a bound accessory is a Wi-Fi capable printer. A stand-alone accessory publishes a Wi-Fi network at all times. An iOS device joins that network so that your app can interact with it. The accessory never provides access to the wider Internet. An example of a stand-alone accessory is a video camera that users take with them into the field. You might want to write an app that joins the camera’s network and downloads footage from it. A gateway accessory is one that publishes a Wi-Fi network that provides access to the wider Internet. Your app might need to interact with the accessory during the setup process, but after that it’s useful as is. An example of this is a Wi-Fi to WWAN gateway. Not all accessories fall neatly into these categories. Indeed, some accessories might fit into multiple categories, or transition between categories. Still, I’ve found these categories to be helpful when discussing various accessory integration challenges. Do You Control the Firmware? The key question here is Do you control the accessory’s firmware? If so, you have a bunch of extra options that will make your life easier. If not, you have to adapt to whatever the accessory’s current firmware does. Simple Improvements If you do control the firmware, I strongly encourage you to: Support IPv6 Implement Bonjour [1] These two things are quite easy to do — most embedded platforms support them directly, so it’s just a question of turning them on — and they will make your life significantly easier: Link-local addresses are intrinsic to IPv6, and IPv6 is intrinsic to Apple platforms. If your accessory supports IPv6, you’ll always be able to communicate with it, regardless of how messed up the IPv4 configuration gets. Similarly, if you support Bonjour, you’ll always be able to find your accessory on the network. [1] Bonjour is an Apple term for three Internet standards: RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses RFC 6762 Multicast DNS RFC 6763 DNS-Based Service Discovery WAC For a bound accessory, support Wireless Accessory Configuration (WAC). This is a relatively big ask — supporting WAC requires you to join the MFi Program — but it has some huge benefits: You don’t need to write an app to configure your accessory. The user will be able to do it directly from Settings. If you do write an app, you can use the EAWiFiUnconfiguredAccessoryBrowser class to simplify your configuration process. HomeKit For a bound accessory that works in the user’s home, consider supporting HomeKit. This yields the same onboarding benefits as WAC, and many other benefits as well. Also, you can get started with the HomeKit Open Source Accessory Development Kit (ADK). Bluetooth LE If your accessory supports Bluetooth LE, think about how you can use that to improve your app’s user experience. For an example of that, see SSID Scanning, below. Claiming the Default Route, Or Not? If your accessory publishes a Wi-Fi network, a key design decision is whether to stand up enough infrastructure for an iOS device to make it the default route. IMPORTANT To learn more about how iOS makes the decision to switch the default route, see The iOS Wi-Fi Lifecycle and Network Interface Concepts. This decision has significant implications. If the accessory’s network becomes the default route, most network connections from iOS will be routed to your accessory. If it doesn’t provide a path to the wider Internet, those connections will fail. That includes connections made by your own app. Note It’s possible to get around this by forcing your network connections to run over WWAN. See Binding to an Interface in Network Interface Techniques and Running an HTTP Request over WWAN. Of course, this only works if the user has WWAN. It won’t help most iPad users, for example. OTOH, if your accessory’s network doesn’t become the default route, you’ll see other issues. iOS will not auto-join such a network so, if the user locks their device, they’ll have to manually join the network again. In my experience a lot of accessories choose to become the default route in situations where they shouldn’t. For example, a bound accessory is never going to be able to provide a path to the wider Internet so it probably shouldn’t become the default route. However, there are cases where it absolutely makes sense, the most obvious being that of a gateway accessory. Acting as a Captive Network, or Not? If your accessory becomes the default route you must then decide whether to act like a captive network or not. IMPORTANT To learn more about how iOS determines whether a network is captive, see The iOS Wi-Fi Lifecycle. For bound and stand-alone accessories, becoming a captive network is generally a bad idea. When the user joins your network, the captive network UI comes up and they have to successfully complete it to stay on the network. If they cancel out, iOS will leave the network. That makes it hard for the user to run your app while their iOS device is on your accessory’s network. In contrast, it’s more reasonable for a gateway accessory to act as a captive network. SSID Scanning Many developers think that TN3111 iOS Wi-Fi API overview is lying when it says: iOS does not have a general-purpose API for Wi-Fi scanning It is not. Many developers think that the Hotspot Helper API is a panacea that will fix all their Wi-Fi accessory integration issues, if only they could get the entitlement to use it. It will not. Note this comment in the official docs: NEHotspotHelper is only useful for hotspot integration. There are both technical and business restrictions that prevent it from being used for other tasks, such as accessory integration or Wi-Fi based location. Even if you had the entitlement you would run into these technical restrictions. The API was specifically designed to support hotspot navigation — in this context hotspots are “Wi-Fi networks where the user must interact with the network to gain access to the wider Internet” — and it does not give you access to on-demand real-time Wi-Fi scan results. Many developers look at another developer’s app, see that it’s displaying real-time Wi-Fi scan results, and think there’s some special deal with Apple that’ll make that work. There is not. In reality, Wi-Fi accessory developers have come up with a variety of creative approaches for this, including: If you have a bound accessory, you might add WAC support, which makes this whole issue go away. In many cases, you can avoid the need for Wi-Fi scan results by adopting AccessorySetupKit. You might build your accessory with a barcode containing the info required to join its network, and scan that from your app. This is the premise behind the Configuring a Wi-Fi Accessory to Join the User’s Network sample code. You might configure all your accessories to have a common SSID prefix, and then take advantage of the prefix support in NEHotspotConfigurationManager. See Programmatically Joining a Network, below. You might have your app talk to your accessory via some other means, like Bluetooth LE, and have the accessory scan for Wi-Fi networks and return the results. Programmatically Joining a Network Network Extension framework has an API, NEHotspotConfigurationManager, to programmatically join a network, either temporarily or as a known network that supports auto-join. For the details, see Wi-Fi Configuration. One feature that’s particularly useful is it’s prefix support, allowing you to create a configuration that’ll join any network with a specific prefix. See the init(ssidPrefix:) initialiser for the details. For examples of how to use this API, see: Configuring a Wi-Fi Accessory to Join the User’s Network — It shows all the steps for one approach for getting a non-WAC bound accessory on to the user’s network. NEHotspotConfiguration Sample — Use this to explore the API in general. Secure Communication Users expect all network communication to be done securely. For some ideas on how to set up a secure connection to an accessory, see TLS For Accessory Developers. Revision History 2025-11-05 Added a link to the Accessory Design Guidelines for Apple Devices. 2025-06-19 Added a preliminary discussion of Wi-Fi Aware. 2024-09-12 Improved the discussion of AccessorySetupKit. 2024-07-16 Added a preliminary discussion of AccessorySetupKit. 2023-10-11 Added the HomeKit section. Fixed the link in Secure Communication to point to TLS For Accessory Developers. 2023-07-23 First posted.

During development, before things eventually go live, if the associated server for a message filter extension has a self signed SSL then if/how can test iPhones be configured such that the OS will connect to the server when they are performing a message filter query request?

I’m working with the NEHotspotHelper API in my iOS app, and I noticed the following log message in Console: "(BUNDLE ID ) is using NEHotspotHelper API and it's unresponsive to API's evaluate command. The API gives 45 seconds to 3rd party apps to respond, and then it launches WebSheet to allow user to interact with the portal." I have two different apps that both register a NEHotspotHelper handler: App A checks for .evaluate and calls createResponse(.unsupportedNetwork) if we don’t manage that particular network. App B registers for hotspot events but does not handle .evaluate at all. In App A, whenever I see that “unresponsive” or “45 seconds” log, the system eventually launches the standard captive portal WebSheet. In App B, I never see those logs. I have a few questions: Are these “unresponsive” logs indeed triggered by the .evaluate command specifically? In other words, do we only see that 45-second timeout and the subsequent WebSheet message if our app is registered to handle Evaluate but doesn’t respond quickly (or responds with .unsupportedNetwork)? Is it best practice (or required) to always respond to .evaluate—for example, sending .unsupportedNetwork if we don’t plan on managing the user’s login or captive portal? Does ignoring .evaluate lead to other unexpected behavior or logs? Should we still explicitly respond to Evaluate with .unsupportedNetwork? Or is it okay to skip Evaluate handling entirely on every app or invocation? I’d love to confirm whether .evaluate handling is the direct cause of these logs, and how best to avoid the “unresponsive”/“45 seconds” fallback if our app isn’t intended to manage the portal. Thanks in advance for any insights!

hi everybody, When I use the following code to connect to WiFi network, an error message of "error=null" or "error='Error Domain=NEHotspotConfigurationErrorDomain Code=11 "" UserInfo={NSLocalizedDescription=}' " will occur. It has been uploaded to Feedback. Feedback ID： FB16819345 (WiFi-无法加入网络) NEHotspotConfiguration *hotspotConfig = [[NEHotspotConfiguration alloc] initWithSSID:ssid passphrase:psk isWEP:NO]; [[NEHotspotConfigurationManager sharedManager] applyConfiguration:hotspotConfig completionHandler:^(NSError * _Nullable error) { }];

We’ve been dealing with local network permission issues on macOS 15. Although 15.1 brought some improvement, users are now reporting similar problems again on 15.2. Our setup: A “launcher” app (installed from a web package, not sandboxed) uses NSTask to launch our main macOS app. This macOS app connects to an iOS app via the local network. We expect a local network permission prompt to appear when the new app launches, but for many users, it never does. In cases where it worked on an earlier macOS version, there’s no entry in System Settings > Privacy & Security > Local Network, so they can’t toggle anything. Oddly, if we run the macOS app directly in 15.2, local network access works, yet the privacy entry is still sometimes missing. We haven’t found a clear way to troubleshoot this within the current API. Has anyone experienced a similar issue, or have suggestions on how to debug and resolve this? Thanks in advance!

We are trying to connect an accessory to the home's Wi-Fi network and we want to pass that name from the app to the accessory. Passing via Bluetooth. Is there and API available on iOS to list the networks that the phone can see?

With the new macOS 15, Apple introduced the new Local Network Privacy feature. This is causing issues for our customers as - even though they granted the required permission for our software - connections to a server in their local network are being blocked. The situation is not fixed by recent macOS updates. As far as I know, this issue exists for machines running on Apple Silicon. Systems running macOS versions (e.g. Sonoma) are not affected. Currently, the workaround is to re-enable the permission under Settings > Privacy & Security > Local Network. The list shows our application with an enabled checkbox. Users now have to de-select the box and then re-select it again for the application to work. They have to do this after each and every reboot of their system, which is slightly annoying (so at the moment we recommend to not upgrade macOS to Sequoia, if possible) I did some research and saw that other products are also affected by this bug. Is there a solution to this issue or any plans to fix it?

We've been directed here by Quinn in DTS. We use multicast/broadcast messages extensively in our physical products for discovery purposes. If, for whatever reason, our customers cannot get this to work on their home Wi-Fi network, we advise that they connect to an iPhone hotspot to confirm behaviour and perform firmware updates as needed. As of iOS 18, we're seeing odd behaviour when using Personal Hotspot. Interestingly, we're also seeing that client devices connected to the Hotspot network are not showing a Subnet Mask in the Wi-Fi Details screen in the iOS Settings app - I don't know if that's related. We're also seeing that screen show an IP address of 192.0.0.2 for all client iPhones connected to an iPhone Hotspot. Getting more specific, we're seeing that multicast messages are no longer being received by clients when connected to an iPhone Hotspot where the iPhone running the hotspot is running iOS 18.0 or newer. By "multicast", I mean we're using a BSD socket to send data to 255.255.255.255 I've confirmed that our app has the multicast entitlement, the user has granted Local Network permission, and we've created a small sample app that demonstrates this behaviour perfectly - when connected to any other test network, multicast messages are received correctly by clients. We've also confirmed that this behaviour doesn't happen when the iPhone running the hotspot is running older iOS versions. We've tried a number of iOS 17.x releases and a number of iOS 16.x releases specifically with our sample app, but have been using this exact code since our app's original iOS 9 deployment target and have had no issues until now.

I am developing an App based on Network Extension that lets all network requests on device access the Internet through a private Relay. I created an empty iOS App and only the entitlements file and ViewController.swift(Main.storyboard) file have been modified. The code was copied from the official video https://developer.apple.com/videos/play/wwdc2023/10002/ But, running the App on iPhone, the saveToPreferences API reported Error Domain=NERelayErrorDomain Code=3 "(null)" and the App doesn't look like it's changed at all (it doesn't jump to the Settings - VPN&Relay). Does anyone know why？Any reply would be greatly appreciated. The contents of the entitlements file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.networking.networkextension</key> <array> <string>relay</string> </array> </dict> </plist> ViewController.swift: import UIKit import NetworkExtension class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. } @IBAction func tap(_ sender: Any) { let newRelay = NERelay() let relayURL = URL(string: "https://relay.example.com:443/") newRelay.http3RelayURL = relayURL newRelay.http2RelayURL = relayURL newRelay.additionalHTTPHeaderFields = ["Authorization" : "PrivateToken=123"] let manager = NERelayManager.shared() manager.relays = [newRelay] manager.matchDomains = ["internal.example.com"] manager.isEnabled = false manager.saveToPreferences { err in print(err) } } }

We're seeing some new and odd behavior where our NEPacketTunnelProvider instance is receiving a stopTunnelWithReason:completionHandler: call with reason NEProviderStopReasonInternalError. Can anyone shed some light into how to diagnose this situation? Here are some basic details: Our PacketTunnel has been in use for years and we only started seeing this issue recently. We're able to reproduce this behavior with some light browsing. The documentation provides no insight on why/when this might occur. Can anyone shed some light into how to diagnose this situation? Things we’ve tried so far: We grabbed a sysdiagnose and looked through the logs: a. Right before the stopTunnel, we see log items referring to a "nesessionmanager" (PID 2038) getting killed. Presumably, this is due to hitting a highwater threshold. (See sysdiagnose items listing below) b. Thinking these were due to memory pressure, we added logging of available/used memory. c. We confirmed that the PacketTunnel was only using 11,808.73 KB. d. Since, there is plenty of memory available the PacketTunnel was not killed for using too much memeory. We wondered if this could be due to our UI's usage of objects like: NETunnelProviderManager and NETunnelProviderSession a. We ran an experiment where we swiped closed the UI to ensure these manager/session objects are not used. b. Without the UI, we still saw the random stopTunnel with NEProviderStopReasonInternalError. We wondered if our routes were the problem, but they seem correct. a. See the NEPacketTunnelNetworkSettings listing below LISTING: From the system_logs.logarchive, the nesessionmanager log items: 2025-01-23 15:07:59.176146 -0800 0x278 memorystatus com.apple.xnu memorystatus: killing process 2038 [nesessionmanager] in high band ? (140) - memorystatus_available_pages: 18932 default kernel 2025-01-23 15:07:59.179641 -0800 0x278 memorystatus com.apple.xnu memorystatus: killing_highwater_process pid 2038 [nesessionmanager] (highwater 140) 7056KB - memorystatus_available_pages: 19161 compressor_size:69593 default kernel 2025-01-23 15:07:59.179888 -0800 0x278 memorystatus com.apple.xnu memorystatus: failed to kill a process and no memory was reclaimed default kernel 2025-01-23 15:07:59.185695 -0800 1 0x45e0c user/501/com.apple.nesessionmanager [2038] exited with exit reason (namespace: 1 code: 0x2) - JETSAM_REASON_MEMORY_HIGHWATER, ran for 266329ms default launchd 2025-01-23 15:07:59.231188 -0800 31 0x45bf2 com.apple.networkextension nesessionmanager(2038) exited default UserEventAgent 2025-01-23 15:07:59.253371 -0800 31 0x45bf2 com.apple.networkextension nesessionmanager exited with active sessions, re-launching nesessionmanager to clear agent status default UserEventAgent LISTING: From the system_logs.logarchive, the stopTunnel from PID 2046 2025-01-23 15:07:59.201581 -0800 SamplePacketTunnel [Extension com.REDACTED.PacketTunnel]: Calling stopTunnelWithReason because: None 2025-01-23 15:08:20.783112 -0800 SamplePacketTunnel 2025-01-23 15:08:20,786 2046 ERROR REDACTED (285805) - Exiting after waiting for stopTunnelWithReason LISTING: routes from NEPacketTunnelNetworkSettings { tunnelRemoteAddress = fd12:3456:789a:1::1 DNSSettings = { protocol = cleartext server = ( 2606:4700:4700::1234, 2606:4700:4700::2345, ) matchDomains = ( , ) matchDomainsNoSearch = NO } IPv6Settings = { configMethod = manual addresses = ( fd12:3456:789a:1::1, ) networkPrefixLengths = ( 64, ) includedRoutes = ( { destinationAddress = 2606:4700:4700::2345 destinationNetworkPrefixLength = 128 }, { destinationAddress = 2606:4700:4700::1234 destinationNetworkPrefixLength = 128 }, ) excludedRoutes = ( { destinationAddress = REDACTED destinationNetworkPrefixLength = 128 }, { destinationAddress = REDACTED destinationNetworkPrefixLength = 128 }, ) } MTU = 3072 } Thanks for taking a look, any help or suggestions would be greatly appreciated

Hi, I would like to confirm whether the matchDomains property in NERelayManager operates strictly at the Application Layer. Specifically, it seems that adding IPv4 addresses or IPv4 CIDR blocks to the matchDomains list does not work, as the relay manager appears unable to match them. For example, I tried adding the following IPv4 patterns to the matchDomains list: 11.22.33.44 11.22.. 11.22.* However, these IPv4 addresses or patterns are not routed through my Relay server. Additionally, I have observed that when using only the excludedDomains property, the desired IPv4 traffic is correctly routed to the relay server as expected. My question is: Can IPv4 addresses or IPv4 CIDR ranges work with matchDomains? If not, is there an alternative approach to enable IPv4 matching while matchDomains is active?

Hi, I would like to confirm if the matchDomains property in NERelayManager operates exclusively at the application layer. Specifically, it seems that adding IPv4 addresses or IPv4 CIDR blocks to the matchDomains list does not work, as the relay manager appears unable to match them. Relay Configuration For example, I tried adding the following IPv4 patterns to the matchDomains list: 11.22.33.44 11.22.. 11.22.* In this configuration, I expected traffic to be routed to the relay server as defined by the matchDomains entries. However, the relay manager did not handle these IPv4 patterns as anticipated. On the other hand, when using only the excludedDomains property, the desired IPv4 traffic is successfully routed to the relay server as expected. Purpose of Forwarding IPv4 to the Relay Server The primary reason for forwarding IPv4 traffic to the relay server is to address cases where certain applications—such as those developed with Flutter or React Native—use their own custom network stack. These custom network stacks often do not respect the relay configuration. As a result, even when these applications use domains that are matched by the relay manager’s matchDomains, their TCP connections to DNS-resolved IPv4 addresses bypass the relay server and connect directly to the IPv4 server. This behavior makes it critical to enable IPv4 matching to ensure all traffic, regardless of the application’s network stack implementation, is routed through the relay server. Questions Can IPv4 addresses or IPv4 CIDR blocks be used with matchDomains? If not, is there an alternative method to enable IPv4 matching while keeping matchDomains enabled? Thank you for your assistance.

I am writing an app using Microsoft's MAUI platform. I am posting this here because that team wants me to make an xcode project to help determine an issue I am having. My MAUI app sends a broadcast packet on a UDP socket using address 255.255.255.255. This worked fine in iOS version 17.x. After upgrading my phone to iOS 18.x it stopped working. The error I get is "no route to host". The exact same code works fine on MacOS. It does not work on iPadOs 18. My question here is 3 fold: Did something specific change between iOS 17 and 18 that would cause a 'no route to host' error when sending a UDP broadcast packet? Can someone provide sample code to show me how to do this type of broadcast using Swift in Xcode for iOS? I read an article that said my app would need the com.apple.developer.networking.multicast entitlement in order to use boradcast functionality. This was introduced in iOS 14. Why did my app work fine in iOS 17 then? Is this what changed? Did this requirement use to be optional and is now required? I did get this entitlement from Apple and applied it to my provisioning profile and my app gave the same "no route to host" error. Why?

I've implemented a custom system extension VPN for macOS using Packet Tunnel Provider. The VPN is configured with on-demand, and a rule to always connect whenever there's traffic: onDemandRules = [NEOnDemandRuleConnect()] As for the tunnel's settings (at the Packet Tunnel Provider), I've configured a split tunnel, so some routes are excluded from the tunnel. Now I have the following scenario: The VPN is connected The Mac enters sleep The sleep() function is called (at my Packet Tunnel Provider) The Mac briefly awakes to check emails/push notifications/etc. This traffic is excluded from the tunnel. What is the expected behavior here? Should the wake function be called because of the on-demand rule? Or should the VPN remain asleep because this traffic is excluded from the tunnel?

Hello eveybody,Currently I'm working on an app which connects to a device. During testing I encounter an internal error of NEHotspotConfigurationErrorDomain. See the log snippet:Domain=NEHotspotConfigurationErrorDomain Code=8 "internal error." UserInfo={NSLocalizedDescription=internal error.}This error appears randomly. In one day I encountered it three times. The only solution I can think of is catching this error somehow and then telling the user to restart the device.After this error appears, the wifi functionality of iOS in all third party apps seems to be broken. Only restarting helps as far as I know. Also there seems to be nothing we as app developers can do about it. Therefor I wonder if there is some way to prevent this error somehow? The only solution I can think of is catching this error somehow and then telling the user to restart the device.Also since there is not much information about this error on the web, it would be really nice if someone can clarify whats going on with this error.Regards.

Context: We are using NWConnection for UDP and TCP Connections, and wanted to know the best way to keep the number of pending send completions in control to limit resource usage Questions: Is there a way to control the send rate, such that too many 'send pending completion' does not get queued. Say if I do a ‘extremely dense flurry of 10 million NWConnection.send’ will all go asynchronous without any complications? Or I would be informed once it reaches some threshold. Or no? And is it the responsibility of the application using NWConnection.send to limit the outstanding completion , as if they were beyond a certain limit, it would have an impact on outstanding and subsequent requests? If so – how would one know ‘what is supposed to be the limit’ at runtime? Is this a process level or system level limit. Will errors like EAGAIN and ETIMEOUT ever will be reported. In the test I simulated, where the TCP Server was made to not do receive, causing the 'socket send buffer' to become full on the sender side. On the sender side my send stopped getting complete, and became pending. Millions of sends were pending for long duration, hence wanted to know if we will ever get EAGAIN or ETIMEOUT.

Hello, we have noticed a crash in BigSur 11.7.10, 20G1427 libdispatch: Crashed Thread: 1 Dispatch queue: com.apple.network.connections Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Illegal instruction: 4 Termination Reason: Namespace SIGNAL, Code 0x4 Terminating Process: exc handler [94088] Application Specific Information: BUG IN CLIENT OF LIBDISPATCH: Release of a suspended object Thread 0: 0 libsystem_kernel.dylib 0x00007fff20488aea __sigsuspend_nocancel + 10 1 libdispatch.dylib 0x00007fff2031f4e1 _dispatch_sigsuspend + 36 2 libdispatch.dylib 0x00007fff2031f4bd _dispatch_sig_thread + 53 Thread 1 Crashed:: Dispatch queue: com.apple.network.connections 0 libdispatch.dylib 0x00007fff2033cc35 _dispatch_queue_xref_dispose.cold.1 + 24 1 libdispatch.dylib 0x00007fff20313808 _dispatch_queue_xref_dispose + 50 2 libdispatch.dylib 0x00007fff2030e2eb -[OS_dispatch_source _xref_dispose] + 17 3 libnetwork.dylib 0x00007fff24255999 __nw_queue_context_create_source_block_invoke + 41 4 libdispatch.dylib 0x00007fff2030d623 _dispatch_call_block_and_release + 12 5 libdispatch.dylib 0x00007fff2030e806 _dispatch_client_callout + 8 6 libdispatch.dylib 0x00007fff203111b0 _dispatch_continuation_pop + 423 7 libdispatch.dylib 0x00007fff203211f4 _dispatch_source_invoke + 1181 8 libdispatch.dylib 0x00007fff20316318 _dispatch_workloop_invoke + 1784 9 libdispatch.dylib 0x00007fff2031ec0d _dispatch_workloop_worker_thread + 811 10 libsystem_pthread.dylib 0x00007fff204b545d _pthread_wqthread + 314 11 libsystem_pthread.dylib 0x00007fff204b442f start_wqthread + 15 I have seen similar crashes in the forum, but none from com.apple.network.connections queue. Should we raise a ticket or is this something that was fixed in newer OS versions? Thanks! Jakub

I am writing to seek clarification on two technical issues related to iOS frameworks (CoreBluetooth and NetworkExtension). These observations are critical for optimizing our app's performance, and I would appreciate any official guidance or documentation references. CoreBluetooth Scanning Frequency and Cycle Issue: We noticed inconsistent BLE device discovery times (ranging from 0.5s to 1.5s) despite the peripheral advertising at 2Hz (500ms interval). Questions: Does iOS regulate the BLE scan interval or duty cycle internally? If yes, what factors affect this behavior (e.g., foreground/background state, connected devices)? Are there recommended practices to reduce discovery latency for peripherals with fixed advertising intervals? Is there a way to configure scan parameters (e.g., scan window/interval) programmatically, similar to Android's BluetoothLeScanner? Test Context: Device: iPhone 13 mini (iOS 17.6.1) Code: CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) NEHotspotConfigurationManager Workflow and Latency Issue: Using NEHotspotConfigurationManager.shared.apply(_:) to connect to Wi-Fi occasionally takes up to 8 seconds to complete. Questions: What is the internal workflow of the apply method? Does it include user permission checks, SSID scanning, authentication, or IP assignment steps? Are there known scenarios where this method would block for extended periods (e.g., waiting for user interaction, network timeouts)? Is the latency related to system-level retries or radio coexistence with other wireless activities (e.g., Bluetooth)? Test Context: Configuration: NEHotspotConfiguration(ssid: "TestSSID") Behavior: Delay occurs even when the Wi-Fi network is in range and credentials are correct.

I was trying to call getsockopt(fd, SOL_LOCAL, LOCAL_PEERCRED, ...), and by mistake passed a wrong value for the second parameter where it should be SOL_LOCAL. But the call still succeeded. Then I did more experiments and passed more random values for the second parameter, all succeeded. It seems there is a lack of parameter check in the implementation of getsockopt() , where it should return errors if people pass invalid parameters instead of succeeding silently. Hope the Apple engineers can help to validate and fix it.

Hi everyone, I’m working with the DNSServiceGetAddrInfo API and came across the following statement in the documentation: If the call succeeds then it initializes the DNSServiceRef, returns kDNSServiceErr_NoError, and the query begins and will last indefinitely until the client terminates the query by passing this DNSServiceRef to DNSServiceRefDeallocate(_) I’m trying to understand exactly what this means in practice. Specifically, after receiving a response with kDNSServiceFlagsMoreComing, being set to 0 does it imply that the OS itself continues querying the DNS periodically or indefinitely, even after we've already received some results? Or does it only continue fetching additional results related to the initial query until we explicitly terminate it? Any clarification on the behavior of this query would be greatly appreciated! Thanks in advance!