I am developing an iOS application using NWPathMonitor for network connectivity monitoring. We discovered a reproducible issue where disabling and re-enabling WiFi triggers an unexpected network status sequence.
ENVIRONMENT:
iOS Version: 17.x
Device: iPhone (various models tested)
Network Framework: NWPathMonitor from iOS Network framework
STEPS TO REPRODUCE:
Device connected to WiFi normally
Disable WiFi via Settings or Control Center
Re-enable WiFi via Settings or Control Center
EXPECTED BEHAVIOR:
WiFi reconnects and NWPathMonitor reports stable satisfied status
ACTUAL BEHAVIOR:
T+0s: WiFi re-enables, NWPathMonitor reports path.status = .satisfied
T+8s: NWPathMonitor unexpectedly reports path.status = .unsatisfied with unsatisfiedReason = .notAvailable
T+9-10s: NWPathMonitor reports path.status = .satisfied again
Connection becomes stable afterward
NETWORK PATH TIMELINE:
T+0s: satisfied (IPv4: true, DNS: false)
T+140ms: satisfied (IPv4: true, DNS: true)
T+8.0s: unsatisfied (reason: notAvailable, no interfaces available)
T+10.0s: satisfied (IPv4: true, DNS: true)
KEY OBSERVATIONS:
Timing consistency: unsatisfied event always occurs ~8 seconds after reconnection
resolution: "Reset Network Settings" eliminates this behavior
TECHNICAL QUESTIONS:
What causes the 8-second delayed unsatisfied status after WiFi re-enablement?
Is this expected behavior that applications should handle?
Why does reset network setting in iPhone fix this issue?
Networking
RSS for tagExplore the networking protocols and technologies used by the device to connect to Wi-Fi networks, Bluetooth devices, and cellular data services.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
At WWDC 25, Dr. Swetank mentioned, “DeviceDiscoveryUI is for making connections between apps and from an app to another device. It supports pairing with both Apple and third-party devices.” I find the pairing process in DeviceDiscoveryUI via Wi-Fi Aware intriguing. I have two questions:
Can we pair devices via Bluetooth first and then establish a Wi-Fi Aware connection?
If I use DeviceDiscoveryUI, how should I write an Android program to correspond with it and achieve iPhone-Android pairing?
The app is an official Apple app: https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps.
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.
I'm running a Node.js server on my MacBook with Apple M4 Pro chip, macOS Sequoia 15.4, and Node.js v23.10.0.
The server starts normally on port 5000 and logs show that it's listening correctly. However, when I try to access it via browser or Postman (http://localhost:5000/api/...), I get a 403 Forbidden error.
After checking with lsof -i :5000, I noticed that the ControlCenter process is listening on port 5000 under the name commplex-main.
Interestingly, this doesn't happen on M3 Pro machines. On those devices, Node.js runs fine on port 5000 and can be accessed from Postman and browsers.
Is port 5000 now internally reserved by macOS or used by some system-level service in Sequoia or Apple Silicon (M4 Pro)?
Should I avoid using this port going forward?
Any official clarification would be appreciated.
Topic:
App & System Services
SubTopic:
Networking
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!
Hello, im currently developing proxy app with XrayCore trying to bypass APNs when tunnel us up and i found .excludeAPNs property in NETunnelProviderProtocol that works only when includeAllNetworks property is also TRUE.
I wonder if there is a possible way to make APNs bypass tunnel in split tunnelling mode? because we use excludedRoutes and full tunnel is not an option
For our outdoor power supply company that builds public WiFi networks at camping sites, we want to implement the following features in our app:
Scan surrounding WiFi networks
When detecting specific public WiFi SSIDs, provide users with corresponding passwords
Automatically connect to those WiFi networks
Regarding the NEHotspotHelper API permission application, when I clicked on https://developer.apple.com/contact/request/network-extension, it redirected me to https://developer.apple.com/unauthorized/. I'm not sure where to properly apply for this permission now.
Topic:
App & System Services
SubTopic:
Networking
I have read the other most relevant posts on this topic here and here. However, the situations described in these posts are different. My app is just a regular Mach-O bundle with a single executable that is launched by the user from the Finder. I've read the Local Network Privacy FAQ and TN3179 carefully and these also doesn't cover the problem described below, which is being reported to me by several of my users.
The problem is that some days after giving Local Network permission to my app, without having changed anything, local network connections will spontaneously start failing with EHOSTUNREACH, indicating that it is being blocked by macOS. This typically happens after a Mac reboot. Toggling off/on the Local Network permission for my app will get it working again, until the next time it fails.
My users who are reporting this have stated that they are running macOS Sonoma 15.2, with only a single version/copy of my app installed.
I've tried, and failed, to reproduce this in a VM with a clean 15.2 system, but maybe this is due to the relatively short duration of my testing (days rather than weeks).
I know there isn't much to go on here, and it may be tempting to put this down to misreporting. After all, the vast majority of my users aren't reporting this, and I can't reproduce it. But, I have received enough similar reports at this point that it's starting to feel like a macOS bug.
Is anyone else seeing this? If there is anything that anyone can suggest - either modifications in my app, or anything that my users can do on their side - this would be very much appreciated!
Many thanks,
Ben
Hi everyone, I developed an Android version of a VPN app built with Flutter using OpenVPN, and it works perfectly on Android. However, when porting it to iOS, I’ve encountered an issue: the app connects successfully but then automatically disconnects when tested via TestFlight. We’ve already added all the necessary network extensions. Despite this, we decided to submit the app to the App Store. It’s been five days now, and the app is still 'Waiting for Review.' Could anyone share their experience deploying and working on an iOS version of a VPN app? I’d really appreciate your insights!
Our app supports live streaming (RTSP, RTMP, WebRTC) functionality.
After updating to the 18.5 Developer Beta version, we’ve encountered an issue where streaming over LTE is not working for customers using SKT (SK Telecom) as their carrier.
Upon investigation, it seems that a similar issue might be occurring with a streaming service app called "SOOP."
I would appreciate it if you could share any information regarding this bug.
Thank you.
I have been using networking multicast permissions in my Xamarin application for UDP device discovery, and it has been working reliably for years. However, I am now encountering an issue specific to iPadOS 18.1 (potentially also iPadOS 18, though I haven’t tested this).
The issue is that my app no longer requests the required network permission on devices running iPadOS 18.1. On the other hand, the app works perfectly on iPhone and iPadOS 17.7 without any problems.
Has there been any change in the networking or permissions framework in iPadOS 18.1 that could cause this behavior? I would appreciate any guidance or insights to resolve this issue.
Thank you for your assistance!
Topic:
App & System Services
SubTopic:
Networking
Could anyone teach me how to ask iOS 18 to have a prompt during set-up process of a new APP if user accidentally turns off Local Network ?
We need your assistance as we are currently facing an issue without a workaround for users on macOS 15.4 and 15.5.
FeedbackID: FB17547675
The problem has been observed on macOS versions 15.4 and 15.5. Apple has acknowledged this issue and confirmed that it is fixed in the macOS 15.6 beta. Although we tried to reproduce the issue in our environment, it did not occur, even on macOS 15.5. Therefore, we cannot verify if the fix in macOS 15.6 beta resolves the problem.
We are actively working to identify an appropriate workaround for users on macOS 15.5. Some users have reported a failure to obtain an IP address over Wi-Fi, possibly due to a DHCP failure.
As a temporary solution, we added logic to restart Wi-Fi programmatically when either an APIPA address (169.254.x.x) or no IPv4 address is detected on the active interface. However, restarting Wi-Fi does not always resolve the issue, and the device may still fail to obtain an IP address over Wi-Fi or Ethernet.
Could you advise if there is a reliable method to detect DHCP failure and recover the device from this state? Also, any idea, how we can reproduce this scenario in our machine?
Below is the failure.
default 2025-06-27 10:07:57.055003 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:07:57.055269 -0700 configd DHCP en0: status = 'no server'
default 2025-06-27 10:08:23.336215 -0700 airportd WiFiUsageBssSession:: ChannelAfterRoam=0; ChannelAtJoin=36; FaultReasonApsdTimedOut=0; FaultReasonArpFailureCount=0; FaultReasonBrokenBackhaulLinkFailed=0; FaultReasonDhcpFailure=0;
default 2025-06-27 10:08:23.367852 -0700 configd DHCP en0: status = 'media inactive'
default 2025-06-27 10:08:23.367909 -0700 configd DHCP en0: INACTIVE
default 2025-06-27 10:08:23.988565 -0700 configd DHCP en0: status = 'media inactive'
default 2025-06-27 10:08:23.988703 -0700 configd DHCP en0: INACTIVE
info 2025-06-27 10:08:23.988852 -0700 configd DHCPv6 en0: Inactive
default 2025-06-27 10:08:35.656415 -0700 configd DHCP en0: status = 'network changed'
default 2025-06-27 10:08:35.656817 -0700 configd DHCP en0: INIT
default 2025-06-27 10:08:35.656821 -0700 configd DHCP en0: supplying device type 'Mac'
info 2025-06-27 10:08:35.656934 -0700 configd DHCP en0: busy
default 2025-06-27 10:08:35.657351 -0700 configd DHCP en0: INIT waiting at 0 for 1.358613
info 2025-06-27 10:08:35.657404 -0700 configd DHCPv6 en0: Inactive
default 2025-06-27 10:08:37.019229 -0700 configd DHCP en0: INIT waiting at 1.36206 for 2.113913
default 2025-06-27 10:08:39.136955 -0700 configd DHCP en0: INIT waiting at 3.47937 for 4.462224
default 2025-06-27 10:08:43.602229 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:08:43.603143 -0700 configd DHCP en0: INIT waiting at 7.94533 for 8.128784
default 2025-06-27 10:08:51.735532 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:08:51.735846 -0700 configd DHCP en0: INIT waiting at 16.0786 for 8.749985
default 2025-06-27 10:09:00.488315 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:09:00.488550 -0700 configd DHCP en0: INIT waiting at 24.8313 for 8.496864
default 2025-06-27 10:09:08.988284 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:09:08.988310 -0700 configd DHCP en0: reported address acquisition failure symptom
default 2025-06-27 10:09:08.988579 -0700 configd DHCP en0: INIT waiting at 33.3312 for 8.300735
default 2025-06-27 10:09:17.294478 -0700 configd DHCP en0: ARP router: No leases to query for
info 2025-06-27 10:09:17.294485 -0700 configd DHCP en0: symptom failure already reported
default 2025-06-27 10:09:17.295454 -0700 configd DHCP en0: INIT waiting at 41.6373 for 8.798768
default 2025-06-27 10:09:26.096673 -0700 configd DHCP en0: ARP router: No leases to query for
info 2025-06-27 10:09:26.096688 -0700 configd DHCP en0: symptom failure already reported
default 2025-06-27 10:09:26.097553 -0700 configd DHCP en0: INIT waiting at 50.4394 for 8.807943
default 2025-06-27 10:09:34.909050 -0700 configd DHCP en0: ARP router: No leases to query for
info 2025-06-27 10:09:34.909054 -0700 configd DHCP en0: symptom failure already reported
default 2025-06-27 10:09:34.909375 -0700 configd DHCP en0: INIT waiting at 59.2517 for 8.877971
default 2025-06-27 10:09:43.792458 -0700 configd DHCP en0: ARP router: No leases to query for
info 2025-06-27 10:09:43.792464 -0700 configd DHCP en0: symptom failure already reported
default 2025-06-27 10:09:43.793641 -0700 configd DHCP en0: status = 'no server'
info 2025-06-27 10:09:43.794145 -0700 configd DHCP en0: not busy
DNS failure
resolver #1
flags :
reach : 0x00000000 (Not Reachable)
resolver #2
domain : local
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300000
resolver #3
domain : 254.169.in-addr.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300200
resolver #4
domain : 8.e.f.ip6.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300400
resolver #5
domain : 9.e.f.ip6.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300600
resolver #6
domain : a.e.f.ip6.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300800
resolver #7
domain : b.e.f.ip6.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 301000
Route table
Destination Gateway Flags Netif Expire
127 127.0.0.1 UCS lo0
127.0.0.1 127.0.0.1 UH lo0
169.254 link#14 UCS en0 !
169.254.160.160/32 link#14 UCS en0 !
224.0.0/4 link#14 UmCS en0 !
224.0.0.251 1:0:5e:0:0:fb UHmLWI en0
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI en0
255.255.255.255/32 link#14 UCS en0 !
Is There a Reliable Way to Check Local Network Permission Status in 2025?
I've read many similar requests, but I'm posting this in 2025 to ask:
Is there any official or reliable method to check the current Local Network permission status on iOS 18.x?
We need this to guide or navigate users to the appropriate Settings page when permission is denied.
Background
Our app is an IoT companion app, and Local Network access is core to our product's functionality. Without this permission, our app cannot communicate with the IoT hardware. Sadly, Apple doesn't provide any official API to check the current status of this permission.
This limitation has caused confusion for many users, and we frequently receive bug reports simply because users have accidentally denied the permission and the app can no longer function as expected.
Our App High Level Flow:
1. Trigger Permission
We attempt to trigger the Local Network permission using Bonjour discovery and browsing methods. (see the implementation)
Since there's no direct API to request this permission, we understand that iOS will automatically prompt the user when the app makes its first actual attempt to communicate with a local network device.
However, in our case, this creates a problem:
The permission prompt appears only at the time of the first real connection attempt (e.g., when sending an HTTP request to the IoT device).
This results in a poor user experience, as the request begins before the permission is granted.
The first request fails silently in the background while the permission popup appears unexpectedly.
We cannot wait for the user's response to proceed, which leads to unreliable behavior and confusing flows.
To avoid this issue, we trigger the Local Network permission proactively using Bonjour-based discovery methods. This ensures that the system permission prompt appears before any critical communication with the IoT device occurs.
We’ve tried alternative approaches like sending dummy requests, but they were not reliable or consistent across devices or iOS versions. (see the support ticket)
2. Wi-Fi Connection:
Once permission is granted, we allow the user to connect to the IoT device’s local Wi-Fi.
3. IoT Device Configuration:
After connecting, we send an HTTP request to a known static IP (e.g., 192.168.4.1) on the IoT network to configure the hardware.
I assume this pattern is common among all Wi-Fi-based IoT devices and apps.
Problem:
Even though we present clear app-level instructions when the system prompt appears, some users accidentally deny the Local Network permission. In those cases, there’s no API to check if the permission was denied, so:
We can’t display a helpful message.
We can’t guide the user to Settings → Privacy & Security → Local Network to re-enable it.
The app fails silently or behaves unpredictably.
Developer Needs:
As app developers, we want to handle negative cases gracefully by:
Detecting if the Local Network permission was denied
Showing a relevant message or a prompt to go to Settings
Preventing silent failures and improving UX
So the question is:
What is the current, official, or recommended way to determine whether Local Network permission is granted or denied in iOS 18.x (as of 2025)?
This permission is critical for a huge category of apps especially IoT and local communication-based products. We hope Apple will offer a better developer experience around this soon.
Thanks in advance to anyone who can share updated guidance.
Hi everyone,
I'm developing a visionOS app that allows users to download large video files (similar to a movie download experience, with each file being around 10 GB). I've successfully implemented the core video download functionality using URLSession, and everything works as expected while the app is active.
Now, I’m looking to support background downloading. Specifically, I want users to be able to start a download and then leave the app (e.g., switch apps or return to the home screen) while the download continues in the background.
Additionally, I’d like to confirm a specific scenario:
If the user starts a download, then removes the headset (keeping the device turned on and connected to power), will the download continue in the background? Or does visionOS suspend the app or downloads in this case?
I’m considering using a background URLSessionConfiguration (as done in iOS/macOS) to enable this behavior, but I’m not sure if it behaves the same way on visionOS or if there are special limitations or best practices when handling large downloads on this platform.
Any insights or official guidance would be greatly appreciated!
Thanks!
For our outdoor power supply company that builds public WiFi networks at camping sites, we want to implement the following features in our app:
Scan surrounding WiFi networks
When detecting specific public WiFi SSIDs, provide users with corresponding passwords
Automatically connect to those WiFi networks
Regarding the NEHotspotHelper API permission application, when I clicked on https://developer.apple.com/contact/request/network-extension, it redirected me to https://developer.apple.com/unauthorized/. I'm not sure where to properly apply for this permission now.
Topic:
App & System Services
SubTopic:
Networking
I am making a USB attached IoT device that follows the Matter approach to connectivity (IP/mDNS/DHCP). I am having conflicts with it as it appears to MacOS as an Ethernet adapter and this is causing it to be assigned as a "default" route, interfering with routing when my Mac is connected to NAT based WiFi.
I'd like to be able to hint to MacOS & iPadOS that this is not a routable private network, the subnet should be respected and a default route should not be assigned to it, otherwise the order of the device connection is used by the IP routing tables and I am concerned my non-routable private network will initialize before Wifi and block NAT based internet connectivity.
How can I hint to MacOS/iPadOS "this is not a routable private network, this is not a NAT, do not assign me a default route beyond the subnet I have provided you."
way to display it is by holding the Option key and clicking the Wi-Fi icon.
In macOS 14.0, wdutil was still usable, but in 14.6.1, the returned information is now . I am unsure if there is an official way to obtain the corresponding BSSID.
I need to process the BSSID in my code, so either a command-line tool or an API would work.
Hello, I have encountered an issue with an iPhone 15PM with iOS 18.5. The NSHTTPCookieStorage failed to clear cookies, after clearing them, I was still able to retrieve them. However, on the same system
NSHTTPCookie *cookie;
NSHTTPCookieStorage *storage = [NSHTTPCookieStorage sharedHTTPCookieStorage];
for (cookie in [storage cookies]) {
[storage deleteCookie:cookie];
}
NSArray *cookies = [[NSHTTPCookieStorage sharedHTTPCookieStorage] cookiesForURL:[[self url] absoluteURL]]; // still able to get cookies,why???
What I want to do?
I want to completely block network traffic for installed iOS apps.
Hence, I need to filter network traffic based on the app, which executes this network request.
Note that my app is created for personal use and learning purposes.
How is this possible on iOS. Could you kindly point me into the right direction?
What I don't want to do?
Block network requests just by using the given domain names or using local VPNs.
What I did?
I skimmed through the Network Extension documentation and this forum.
https://developer.apple.com/documentation/networkextension/content-filter-providers?language=objc
https://developer.apple.com/forums/thread/692597
Thank you!
BR,
Markus