I created an App using PeerNetworking to connect two iOS-Devices without existing wifi-infrastructure. In general the solution works fine but when there are many other smart devices nearby connection gets unstable and breaks, devices have to be closer together or dont connect at all. In "Lab"-conditions everything works fine. What could I do to get the connection more stable and reliable?

I would like to know whether it is possible to collect Wi-Fi signal strength on iOS 18 from an iPhone app. I need to measure Wi-Fi signal strength for an internal app. The app is not intended for App Store distribution. I enabled the Access WiFi Information capability and tested NEHotspotNetwork.fetchCurrent(). SSID and BSSID are returned correctly, but signalStrength always returns 0.0. Is there any official or supported way to get the current Wi-Fi RSSI/signal strength on iOS 18? For example, is this possible through NEHotspotNetwork, NEHotspotHelper, or any other iOS API?

This issue has cropped up many times here on DevForums. Someone recently opened a DTS tech support incident about it, and I used that as an opportunity to post a definitive response here. If you have questions or comments about this, start a new thread and tag it with Network so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" iOS Network Signal Strength The iOS SDK has no general-purpose API that returns Wi-Fi or cellular signal strength in real time. Given that this has been the case for more than 10 years, it’s safe to assume that it’s not an accidental omission but a deliberate design choice. For information about the Wi-Fi APIs that are available on iOS, see TN3111 iOS Wi-Fi API overview. Network performance Most folks who ask about this are trying to use the signal strength to estimate network performance. This is a technique that I specifically recommend against. That’s because it produces both false positives and false negatives: The network signal might be weak and yet your app has excellent connectivity. For example, an iOS device on stage at WWDC might have terrible WWAN and Wi-Fi signal but that doesn’t matter because it’s connected to the Ethernet. The network signal might be strong and yet your app has very poor connectivity. For example, if you’re on a train, Wi-Fi signal might be strong in each carriage but the overall connection to the Internet is poor because it’s provided by a single over-stretched WWAN. The only good way to determine whether connectivity is good is to run a network request and see how it performs. If you’re issuing a lot of requests, use the performance of those requests to build a running estimate of how well the network is doing. Indeed, Apple practices what we preach here: This is exactly how HTTP Live Streaming works. Remember that network performance can change from moment to moment. The user’s train might enter or leave a tunnel, the user might step into a lift, and so on. If you build code to estimate the network performance, make sure it reacts to such changes. Keeping all of the above in mind, iOS 26 beta has two new APIs related to this issue: Network framework now offers a linkQuality property. See this post for my take on how to use this effectively. The WirelessInsights framework can notify you of anticipated WWAN condition changes. But what about this code I found on the ’net? Over the years various folks have used various unsupported techniques to get around this limitation. If you find code on the ’net that, say, uses KVC to read undocumented properties, or grovels through system logs, or walks the view hierarchy of the status bar, don’t use it. Such techniques are unsupported and, assuming they haven’t broken yet, are likely to break in the future. But what about Hotspot Helper? Hotspot Helper does have an API to read Wi-Fi signal strength, namely, the signalStrength property. However, this is not a general-purpose API. Like the rest of Hotspot Helper, this is tied to the specific use case for which it was designed. This value only updates in real time for networks that your hotspot helper is managing, as indicated by the isChosenHelper property. But what about MetricKit? MetricKit is so cool. Amongst other things, it supports the MXCellularConditionMetric payload, which holds a summary of the cellular conditions while your app was running. However, this is not a real-time signal strength value. But what about Wi-Fi Aware? Wi-Fi Aware supports a signalStrength property, and a new forcecast property in iOS 27 beta, but those only work in the context of Wi-Fi Aware; they do not represent a general-purpose API. But what if I’m working for a carrier? This post is about APIs in the iOS SDK. If you’re working for a carrier, discuss your requirements with your carrier’s contact at Apple. Revision History 2026-06-18 Added a discussion of Wi-Fi Aware. 2025-07-02 Updated to cover new features in the iOS 16 beta. Made other minor editorial changes. 2022-12-01 First posted.

We're developing a custom Thunderbolt device and want to expose it to macOS as an ethernet interface, while owning the full network stack implementation up to and including IP, TCP and UDP — bypassing the macOS network stack for those layers. Is IOEthernetController the right DriverKit approach for this, and does it allow intercepting traffic before it reaches the macOS IP stack?

I am porting a project from the now deprecated dns_util api to use the DNS Service Discovery api. With dns_util I am able to specify a DNS name server to use for resolving queries. This is useful for testing new servers or propogation when changes have been made to DNS records. Is it possible to specify the nameserver to use with DNS Service Discovery?

We have an app that uses UDP messaging. It has been working for over 3 years successfully. The App is now failing on installation with MacOS26. The issue would appear to be that MacOS is silently blocking the UDP traffic. If we disable the local network for the App, and then turn back on, this will fix the issue. But this needs to be done on every system restart.

We operate a captive portal WIFI network in a walled-garden setup. There is no public internet access on this network. Users connect to our SSID and can only reach a local resource. On Android, our captive portal can show a button that launches the devices default browser and navigates to our portal page. We cannot reproduce this on iOS: we can place the button inside the CNA tear sheet but tapping it does not open Safari, the redirect simply does not happen. I found this older thread describing the same need: https://developer.apple.com/forums/thread/75498 From that thread, it seems the behavior changed several times. It reportedly worked around iOS 11.2 then broke again in later releases. My questions: On current iOS, is it possible to open Safarı or the default browser programmatically from within the CNA? For example, via a link or button after authentication? If yes, what is the supported way? If it is not supported, is that intentional? Is there any official documentation describing CNA limitations and the recommended pattern? For a walled-garden network with no public Internet, what is Apple's recommended approach to move the user from the CNA into a full browser session?

I previously attempted to apply for the hotspot-provider entitlement but was rejected. I no longer require this entitlement. I need to remove the hotspot-provider permission although the Network Extensions capability is checked. However, the generated provisioning profile still includes the hotspot-provider permission, which causes error 409 when I upload the IPA file. I only need the Network Extensions entitlement. Could you please advise how to remove hotspot-provider from the provisioning profile?

Description of the Issue: We are experiencing intermittent, severe latency spikes during cellular data transmission (specifically with MQTT Publish) on iPhone 17 devices. Through internal testing and cross-referencing with similar user reports online, we suspect this is caused by an aggressive power-saving or sleep mechanism in the cellular modem/iOS network stack when traffic is sporadic or low-frequency. Steps to Reproduce / Observations: Establish an MQTT connection over a cellular network (5G/LTE) on an iPhone 17. Publish messages at irregular or low-frequency intervals (e.g., sporadic IoT data transmission). Result: Severe latency spikes occur intermittently during transmission. Diagnostic Findings & Documented Workarounds: Workaround 1 (Constant Traffic): If we connect a secondary device (e.g., a PC) to the iPhone 17's Personal Hotspot and run a continuous background ping (with a 10ms interval), the MQTT latency spikes disappear completely. This high-frequency traffic prevents the device/modem from dropping into power-save mode. Workaround 2 (VPN Tunnel): Utilizing a VPN profile (such as Cloudflare's 1.1.1.1 app) significantly mitigates the issue. We suspect this is due to either the VPN's background keep-alive packets maintaining the active state of the modem, or iOS applying a less aggressive power-saving policy to active VPN interfaces. System Environment: Device: iPhone 17 series OS: iOS 19 (or specify your current version) Network: Cellular (5G/LTE) Questions Regarding Temporary Workarounds & Mitigations: To unblock our current development and ensure a reliable user experience before an official OS-level fix is deployed, we would highly appreciate Apple's technical guidance on the following questions: Recommended Keep-Alive Mechanism: Since higher frequency traffic effectively prevents the modem from entering power-save mode, does iOS have a recommended, power-efficient way for an application to maintain an active cellular network state (e.g., recommended TCP/MQTT keep-alive intervals or NWPathEvaluator configurations) without being suspended or penalized by the system? Network Optimization APIs: Are there specific Network Framework APIs (Network.framework) or socket configuration flags (such as Multipath TCP, or Quality of Service (QoS) flags like Background vs Default) that can signal to the iOS kernel to apply a less aggressive power-saving policy on the active cellular interface? Background Execution Policy: For IoT applications that need to publish MQTT data seamlessly while running in the background, what is the best practice to prevent the cellular link from dropping into deep sleep mode? We would appreciate it if the Apple Network/CoreOS engineering team could look into this cellular power management behavior. Thank you for your support.

Since macOS 26 (Tahoe), getaddrinfo() with AF_UNSPEC for a hostname whose DNS answer contains only A records (no AAAA) fails in forked child processes when the parent performed DNS resolution, or otherwise initialized os_log, before forking. This is a regression: the same code works on macOS 15.x and earlier. The child crashes with EXC_BAD_ACCESS (KERN_INVALID_ADDRESS) inside the NAT64 synthesis path: _os_log_preferences_refresh (libsystem_trace.dylib) <- faulting frame os_log_type_enabled (libsystem_trace.dylib) nw_path_access_agent_cache (Network) _nw_path_update_is_viableTm / nw_path_snapshot_path / nw_path_evaluator_evaluate nw_nat64_v4_address_requires_synthesis _gai_nat64_second_pass (libsystem_info.dylib) si_addrinfo -> getaddrinfo Runtimes that install a SIGSEGV handler (Ruby, Python) do not die; instead the DNS helper thread spins at 100% CPU and the process hangs. We have also captured a parent-side variant where a later fork() deadlocks in the atfork prepare path itself: libSystem_atfork_prepare -> nw_path_prepare_fork -> _os_unfair_lock_lock_slow. Minimal trigger in C: os_log_t log = os_log_create("com.example.repro", "repro"); os_log(log, "init"); struct addrinfo hints = { .ai_family = AF_UNSPEC, .ai_socktype = SOCK_STREAM }, *res; getaddrinfo("api.stripe.com", "443", &hints, &res); // parent: IPv4-only host if (fork() == 0) { getaddrinfo("api.stripe.com", "443", &hints, &res); // child: crashes in _os_log_preferences_refresh _exit(0); } Observed behavior and boundaries: Reproduces on 26.1 through 26.5.1 (25F80). Not reproducible on macOS 15.x. Only AF_UNSPEC lookups of IPv4-only hostnames are affected. AF_INET hints, IPv6-capable hostnames (for example google.com), numeric literals, and localhost are all immune. AF_INET6-only lookups neither trigger nor prevent it. The failure is all-or-nothing per parent process: once a parent is in the affected state, every forked child fails. On 26.5.1 it reproduces most reliably when the process was exec'd over a prior os_log-using image (for example Ruby launched via bundle exec, where the bundler Ruby execs the target Ruby in the same process), and intermittently from a bare shell. On 26.1 even bare runs reproduced readily. This is consistent with per-process logging state surviving exec and then being inherited invalid across fork. I understand that officially only async-signal-safe calls are supported between fork and exec. But this worked through macOS 15, and it breaks the pre-forking worker model used by major Ruby and Python frameworks (Resque, Unicorn, multiprocessing) on developer machines. Filed as FB21364061 in December 2025, no response so far. Is this a known issue, and is a fix present or planned in macOS 26.6 or the macOS 27 beta?

I have a swift app which I'm running via a LaunchAgent. It sends a video feed via multicast UDP. While it works if I manually allow via Privacy & Security - Local Network (allowing the app to find devices on local network), I cannot get AllowedEthernetLocalNetworkAddresses to work. I have attempted to do so with my app and with ffmpeg (installed via homebrew). Neither seems to respect the AllowedEthernetLocalNetworkAddresses setting outlined in TN3179: Understanding local network privacy | Apple Developer Documentation. I have attempted allowing 239.0.0.0/8, 224.0.0.0/4, 239.255.0.0/16, 239.255.1.1/32. I see no change after a reboot with any of these values in the array: sudo defaults write com.apple.network.local-network AllowedEthernetLocalNetworkAddresses -array "239.0.0.0/8" This is on macOS 26.5.1, and I am only connected via ethernet. Am I missing a configuration piece? Thanks!

When entering the following command in macOS 27 beta: lvbojie@Mac ~ % netstat -I nan0 1 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll nan0* 1500 <Link#25> 66:31:00:4c:3c:b5 0 0 41 0 0 nan0* 1500 fe80::6431: fe80:19::6431:ff: 0 - 41 - - liushicong@Mac ~ % netstat -I nan0 1 The nan0 network interface is displayed. Does this indicate that macOS will support Wi-Fi Aware in the near future?

Hello, I'm developing a gambling blocker app that uses NEFilterDataProvider. My app was approved on the App Store, but the core feature doesn't work for end users. I have the content-filter-provider entitlement. Issue 1 — saveToPreferences() fails in distribution builds In dev builds (Xcode direct install), NEFilterManager.saveToPreferences() works fine — iOS shows a permission dialog and the filter is registered. In distribution builds (TestFlight/App Store), it fails immediately: NEFilterErrorDomain code 5 — Operation not permitted Console log from nehelper: "Creating a content filter configuration is only allowed through profile in production version" Issue 2 — .mobileconfig profile requires MDM Following the Console hint, I tried a .mobileconfig profile with com.apple.webcontent-filter payload (ContentFilterUUID, FilterType: Plugin, PluginBundleID). On an unsupervised consumer iPhone (iOS 18.5), installation fails: Profile Installation Failed — MDM required Question: What is the correct mechanism to activate a NEFilterDataProvider on a consumer (non-MDM) iPhone in a distribution build? Is there a specific entitlement or approval process I'm missing? (DTS Case-ID: 20087732)

I'm implementing a NETransparentProxyProvider and trying to preserve the original TCP connection semantics as transparently as possible. The current API of NEAppProxyTCPFlow appears not to provide a way to distinguish between the following situations: The client has performed a half-close by calling shutdown(SHUT_WR) (i.e. closed only its write side). The client has fully closed the socket/connection. When readData(completionHandler:) returns empty data, indicating EOF, I cannot determine which of the two cases above has occurred. This creates a problem when forwarding the connection to the upstream server. Upon receiving empty data from the flow, should the corresponding server-side connection: Perform a half-close (close only the write side / send FIN)? Be fully closed? Currently, I always perform a half-close on the server-side connection. While this almost preserves the original flow semantics, it can lead to leaked connections, since the upstream connection may remain in FIN_WAIT_2 indefinitely. Is there any supported way to determine whether the originating connection was half-closed or fully closed? If not, what is the recommended approach for implementing a transparent TCP proxy that needs to accurately preserve TCP shutdown semantics? Any guidance would be appreciated.

libquic.dylib crashes with a null/invalid buffer access in nw_protocol_data_access_buffer during QUIC connection path migration on iOS 26. App code is not in the stack — this is entirely within Apple system libraries. We are seeing a consistent crash on iOS 26 that does not reproduce on iOS 17 or iOS 18. The crash occurs on a background thread ("com.apple.network.connections") with no application code in the crashed thread's stack. The crash trace begins in quic_migration_probe_path and terminates in nw_protocol_data_access_buffer + 180, suggesting a use-after-free or buffer lifetime violation during QUIC connection path migration (e.g., Wi-Fi ↔ Cellular handoff). This crash does not appear to be reproducible on demand — it correlates with network path transitions while QUIC connections are active. Our app uses standard URLSession with default/ephemeral session configurations and does not explicitly enable HTTP/3; iOS 26 is automatically upgrading eligible connections. Crash thread (abbreviated): 0 libquic.dylib quic_conn_send_packet + 144 1 libquic.dylib quic_conn_continue_sending + 424 2 libquic.dylib __quic_conn_send_frames_for_key_state_block_invoke_2 + 1244 3 Network nw_protocol_data_access_buffer + 180 ← crash 4 Network nw_protocol_data_copy_buffer 5 Network nw_endpoint_flow_output_frames 6 libquic.dylib quic_conn_send_frames_for_key_state 7 libquic.dylib quic_conn_send_frames 8 libquic.dylib quic_migration_probe_path + 1464 9 libquic.dylib quic_migration_path_established + 2608 10 libquic.dylib __quic_migration_path_event_block_invoke.21 11 libquic.dylib quic_migration_path_event 12 Network nw_protocol_implementation_connected There is no app code in the crashed thread. This is a regression introduced in iOS 26, where libquic.dylib was separated into its own dynamic library and new path migration probe logic was introduced.

We develop a healthcare emergency-alerting app with a native watchOS companion app. We've hit a network routing issue on watchOS that we cannot work around with any public API, and it breaks a safety-critical flow (triggering an emergency alarm from the watch). Environment watchOS 26.5 on Apple Watch SE3, paired with iPhone SE on iOS 26.5 Watch app deployment target: watchOS 9.0 Plain URLSession (async/await), default configuration plus waitsForConnectivity = false, allowsExpensiveNetworkAccess = true, allowsConstrainedNetworkAccess = true HTTPS to our own backend (valid public TLS certificate, no pinning) Steps to reproduce Pair the watch with the iPhone. Both on the same known Wi-Fi network. On the iPhone: turn OFF Wi-Fi and cellular data. Keep Bluetooth ON. The watch remains connected to its known Wi-Fi network (or would be, if the system brought the radio up). Trigger any HTTPS request from the watch app (foreground). Expected Since the companion iPhone has no internet, the watch should satisfy the request over its own Wi-Fi. Actual The request is routed through the companion link (ipsec1, "companion preference: prefer" in the logs) and fails after the TLS handshake dies inside the tunnel: Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9816 (errSSLClosedNoNotify) The watch never fails over to its own Wi-Fi, no matter how many times we retry or how long we wait. The same request succeeds within seconds if the user disables Bluetooth on the iPhone (watch then joins Wi-Fi directly), or restores the iPhone's internet. What we already tried waitsForConnectivity = true doesn't help; a path exists (the tunnel), it just doesn't work. Fresh URLSession per retry, backoff retries still routed via the tunnel. Per TN3135 we understand low-level networking is not available to a normal app: we prototyped NWConnection with prohibitedInterfaceTypes = [.other], and indeed on device NWPathMonitor stays .unsatisfied even when the watch has working Wi-Fi, exactly as TN3135 describes. So Network framework is not an escape hatch for us, and we are not looking to abuse the audio-streaming/CallKit carve-outs. Questions Is the companion-preferred routing supposed to fail over to the watch's own Wi-Fi when the iPhone is reachable over Bluetooth but has no internet? If yes, on what timescale, and is there anything an app can do to help the system notice the dead path sooner? Is there ANY supported way for a foreground watchOS app to express "do not use the companion link for this request"? We found only the private _companionProxyPreference SPI, which we obviously can't ship. If the answer to both is "no", what is the recommended pattern for safety-critical requests in this state is failing fast and instructing the user to disable iPhone Bluetooth really the intended UX? Related earlier reports of the same behavior: https://developer.apple.com/forums/thread/759321 https://developer.apple.com/forums/thread/107964

Is there any current documentation of Wide-Area Bonjour support in macOS? While the system-level defaults still seem to be the same, in the past there were bugs in the various HMAC and other authentication mechanisms for dynamic updates. Is there a source for current documentation?

We are developing a network extension that utilises the NEPacketTunnelProvider. We have noticed when the extension is running, and the phone screen is off, after about 10 seconds the device goes to system sleep (as evidenced by messages like “suspended timer for imminent system sleep” in the console logs) and the network extension simply won’t run any code during this time, therefore stopping traffic flow. When the device wakes up from sleep, such as when the screen comes on the network extension resumes executing code and runs normally. The use case is relaying traffic from a device on the same Wi-Fi network to our server via the iPhone's cell socket. As such, we need it to work reliably when the screen is off and not freeze the network extension. Is there any way to prevent the device from sleeping and freezing our extension when the screen is off? Also, if sleep causes the extension to pause code execution, then how would system services like APNS or includeAllNetworks (which forces all traffic through the tunnel) even work?

Hello, We have a Network extension transparent proxy (NETransparentProxyProvider) that receives browser TCP flows as NEAppProxyTCPFlow. For each flow we create an NWConnection to the flow's original destination and set NEParameters.preferNoProxies = true - expecting the outbound connection to bypass the user's HTTP/HTTPS proxy and PAC so it goes to the destination server directly. However, in practice we see connections still being redirected to local proxy after being evaluated against the PAC rules using the destination IP and port. Our questions are: Could we expect preferNoProxies to be respected when a PAC exist on the endpoint and supersede the PAC rule decision? If yes, what would be the best way to file a bug and what information do you need? If not, is there any other way of making sure that the outbound NWConnection created by the transparent proxy is not redirected to a proxy and goes directly to the destination? One other way of avoiding our NWConnection being redirected to the proxy is to use hostname instead of destination IP. Would there be a reliable way of getting hostname for the NEAppProxyTCPFlow so that PAC can correctly filter all NWConnection based on rules? We have explored remoteHostname but it's generally not available for connections from browsers other than Safari.

Hi, I was wondering about eSIM on iOS devices. If they are older iOS devices, would they work the same as newer devices? Recently, there was a need to setup an iOS device and we opted for an eSIM with the carrier. The next day, it was having some issues with activation and had to resort to a physical SIM. Would this be fixed in the next version of iOS or is it a hardware related issue? Thank you