Hello all, Does anyone know how long it will take Apple to approve multicast entitlement approval after the Apple form is submitted? Any input would be appreciated. Thank you Allyson

We have a vpn app which uses PacketTunnelProvider. We also support per-app vpn for iOS, I need help with debugging steps for an issue I am facing recently. In the per app vpn, we have split tunneling: some urls should be tunneled while others should be direct, for tunneled urls/ips everything is working as expected. But for "direct" resources, I am facing an issue where sometimes I don't get an ACK back from the browser. Leading to a series of retransmissions and eventually the direct website not loading. Some more points of data: we do get true for the writePackets call, which seems to mean that the vpn app did write the packets to the TUN interface, but we don't get an ACK from the browser. I want some way of debugging this further so I can check if the browser actually got the packets. I also suspect that there might be a loop with packets (we are reading the packets we just wrote onto TUN), but can't say for sure since the issue is intermittent, in case of a loop, I would expect it to always help. Any help would be greatly appreciated.

I'm seeing fully reproducible issues with URLSession on iOS 18.4 RC Simulator running from Xcode 16.3 RC. URLSession seems to get into a broken state after a second app run. The following sample succeeds in fetching the JSON on first app run but when the app is closed and ran again it fails with one of these errors: Error: Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost." Error: Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." I'm wondering if this something related to my OS setup or is this due to internal URLSession changes in iOS 18.4. Already submitted as FB17006003. Sample code attached below: import SwiftUI @main struct NetworkIssue18_4App: App { var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { @State private var message: String = "" var body: some View { VStack { Text(message) Button("Try Again") { Task { await fetch() } } } .task { await fetch() } } private func fetch() async { message = "Loading..." let url = URL(string: "https://poetrydb.org/title/Ozymandias/lines.json")! let session = URLSession.shared do { let response = try await session.data(from: url) print("Response: \(response)") message = "Success, data length: \(response.0.count)" } catch { print("Error: \(error)") message = "Error: \(error.localizedDescription)" } } }

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.

I've been wondering what is the memory limit for network extensions. Specifically, I'm using the NEPacketTunnelProvider extension point.The various posts on this forum mention 5 MB and 6 MB for 32-bit and 64-bit respectively. However I find that (at least on iOS 10) the upper limit seems to be 15 MB. Is this the new memory limit for extensions?

Sometimes when adding a VPN configuration, it just redirects to the Settings app and doesn’t continue with the rest of the configuration process like prompting for passcode. But it proceeds as normal after the 2nd or 3rd try. This issue is occurring on iOS 18.5 build 22F5068a but it has been a problem over several versions now. Feedback ID: FB17458055

[Q] Has there been a change in macOS 15.3.2 and later that can explain why some UDP traffic is not seen by some Network Extensions when it is in previous macOS minor and major versions?

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

Feedback Ticket: FB13812251 Problem Statement: We are currently facing internet connectivity issue with our VPN application where we try to disconnect the VPN from the Packet Tunnel Network Extension using - (void)cancelTunnelWithError:(nullable NSError *)error. Which API to use to disconnect the VPN from Packet Tunnel as VPN app is not running such that device retains its internet connectivity as soon as VPN disconnects. Configuration: We have configured PacketTunnelProvider with the following settings: (NETunnelProviderManager *)tunnelProvider.protocolConfiguration.includeAllNetworks = YES; (NETunnelProviderManager *)tunnelProvider.protocolConfiguration.excludeLocalNetworks = NO; (NETunnelProviderManager *)tunnelProvider.protocolConfiguration.enforceRoutes = NO; These settings are applied from the VPN app and allow us to successfully establish a VPN connection, with all traffic being routed through the tunnel as expected.We are setting above properties to address local net attack. Issue we are facing: However, we encounter a problem when we attempt to disconnect the VPN from. When we call the following method from PacketTunnel network extension: (void)cancelTunnelWithError:(nullable NSError *)error Upon calling this method, the VPN disconnects as expected, but the device loses all internet connectivity and is unable to access any resources. This is not the desired behavior. Observation : Interestingly, when we call the following method from the app side. The VPN disconnects and the device retains its internet connectivity. [enabledConfig.connection stopVPNTunnel]; We would like to achieve the same behavior when disconnecting the VPN from the Network Extension. So we are looking for an API that could be called from NE without causing any internet connectivity issue. Any guidance on how to resolve this issue would be greatly appreciated.

We have a VPN app built using PacketTunnelProvider and support per-app VPN on iOS. We're currently investigating an issue specific to per-app VPN configurations that use split tunneling, where some URLs are routed through the VPN tunnel while others are intended to go directly. Tunneled traffic works as expected. However, for direct traffic, we observe intermittent failures where the browser does not receive an ACK, leading to repeated retransmissions and eventual page load failures. This issue appears only in per-app VPN scenarios, and we've reproduced it across multiple MDM solutions (Intune, CEM) and multiple managed browsers. It's intermittent but frequently reproducible with common public URLs routed directly. Key observations: writePackets returns true, confirming the VPN app writes packets to the TUN interface. Despite that, the browser often fails to acknowledge receipt (no ACK), suggesting it may not receive the packet at all. We suspect a possible packet loop, where packets written to TUN are immediately read back by the app. However, due to the intermittent nature of the issue, this is hard to confirm. A consistent loop would likely result in persistent failures, not sporadic ones. We are attaching: A Wireshark summary - highlighting the missing ACK and retransmission pattern. As we cannot attach the xlsx file or a zip file, we have took the screenshots of the files names as image1, image2, image3, image4 and image5 in sequence. Dails on the iOS device and MDM environment. NETunnelProviderProtocol configuration that reproduces the issue Any guidance on how to further debug this, particularly on confirming packet delivery to the browser and identifying potential loops would be greatly appreciated. Thank you. e t

We have an old iOS app and an old camera that connects using Wi-Fi either using an access point or Ad Hoc network, e.g., iPhone/iPad connects to the camera's Wi-Fi directly... How it works (old legacy app/system, which cannot be redesigned): Camera is configured to Ad Hoc Wi-Fi network (insecure TCP). iPhone connects to this insecure Wi-Fi. Camera uses Bonjour service to broadcast its IP address. App reads in IP address and begin to send messages to the camera using NSMutableURLRequest, etc. All this works fine for iOS 17. But in iOS 18 step 4 stopped working. App simply doesn't get any responses! We believe we have configured ATS properly (App Store version): In panic we have also tried this in Test Flight version: The latter actually seemed to make a difference when running the app on macOS Apple Silicon. But on iOS it didn't seem to make any difference. Occasionally, I was lucky to get connection on on iPhone 16 Pro with iOS 18. But for the 'many' iPads I have tried I couldn't. I also tried to install CFNetwork profile and look at the logs but I believe I just got timeout on the requests. Questions: Why it iOS 18 different? Bonjour works fine, but NSSURLRequests doesn't Do we configure ATS correctly for this scenario? What should I look for in the Console log when CFNetwork profile is installed? Should I file a TSI? Thanks! :)

Hi! My project has the Local Push Connectivity entitlement for a feature we have requiring us to send low-latency critical notifications over a local, private Wi-Fi network. We have our NEAppPushProvider creating a SSE connection using the Network framework with our hardware running a server. The server sends a keep-alive message every second. On an iPhone 16 with iOS 18+, the connection is reliable and remains stable for hours, regardless of whether the iOS app is in the foreground, background, or killed. One of our QA engineers has been testing on an iPhone 13 running iOS 16, and has notice shortly after locking the phone, specifically when not connected to power the device seems to turn off the Wi-Fi radio. So when the server sends a notification, it is not received. About 30s later, it seems to be back on. This happens on regular intervals. When looking at our log data, the provider does seem to be getting stopped, then restarted shortly after. The reason code is NEProviderStopReasonNoNetworkAvailable, which further validates that the network is getting dropped by the device in regular intervals. My questions are: Were there possibly silent changes to the framework between iOS versions that could be the reason we're seeing inconsistent behavior? Is there a connection type we could use, instead of SSE, that would prevent the device from disconnecting and reconnecting to the Wi-Fi network? Is there an alternative approach to allow us to maintain a persistent network connection with the extension or app?

General: Forums subtopic: App & System Services > Networking DevForums tag: Network Extension Network Extension framework documentation Routing your VPN network traffic article Filtering traffic by URL sample code Filtering Network Traffic sample code TN3120 Expected use cases for Network Extension packet tunnel providers technote TN3134 Network Extension provider deployment technote TN3165 Packet Filter is not API technote Network Extension and VPN Glossary forums post Debugging a Network Extension Provider forums post Exporting a Developer ID Network Extension forums post Network Extension Framework Entitlements forums post Network Extension vs ad hoc techniques on macOS forums post Network Extension Provider Packaging forums post NWEndpoint History and Advice forums post Extra-ordinary Networking forums post Wi-Fi management: Understanding NEHotspotConfigurationErrorInternal forums post See also Networking Resources for general networking resources, including information about Wi-Fi. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

While trying to use Bonjour, i am encountering an issue. I was following the setup of Bonjour as described here: (https://developer.apple.com/forums/thread/735862) the response is this : nw_browser_fail_on_dns_error_locked [B2] nw_browser_dns_service_browse_callback failed: PolicyDenied(-65570) browser did change state, new: waiting(-65570: PolicyDenied) i tried modifying the info.plist to include NSLocalNetworkUsageDescription and NSBonjourServices but still getting the same a workout or solution is much appreciated !

Hi, Our project is a MacOS SwiftUI GUI application that bundles a System Network Extension, signed with a Developer ID certificate for distribution outside of the app store. The system network extension is used to write a packet tunnel provider. The signing of the app & network extension is handled by XCode (v16.0.0), we do not run codesign ourselves. We have no issues with XPC or the system network extension during normal usage, nor when the application is installed on a user's device for the first time. The problem only arises when the user upgrades the application. I have experienced this issue myself, as have our users. It's been reported on Apple Silicon macbooks running at least macOS 15.3.2. Much like the SimpleFirewall example (which we used as a reference), we use XPC for basic communication of state between the app and NE. These XPC connections stop working when the user installs a new version of the app, with OS logs from the process indicating that the connection is immediately invalidated. Subsequent connection attempts are also immediately invalidated. Toggling the VPN in system settings (or via the app) does not resolve the problem, nor does restarting the app, nor does deleting and reinstalling the app, nor does restarting the device. The only reliable workaround is to delete the system extension in Login Items & Extensions, under Network Extensions. No device restart is necessary to garbage collect the old extension - once the extension is reapproved by the user, the XPC issue resolves itself. This would be an acceptable workaround were it possible to automate the deleting of the system extension, but that appears deliberately not possible, and requiring our users to do this each time they update is unreasonable. When the upgraded app is opened for the first time, the OSSystemExtensionRequest request is sent, and the outcome is that the previously installed system network extension is replaced, as both the CFBundleVersion and CFBundleShortVersionString differ. When this issue is encountered, the output of systemextensionsctl list shows the later version is installed and activated. I've been able to reproduce this bug on my personal laptop, with SIP on and systemextensionsctl developer off, but on my work laptop with SIP off and systemextensionsctl developer on (where the network extension is replaced on each activation request, instead of only when the version strings differ), I do not encounter this issue, which leads me to believe it has something to do with the notarization process. We notarize the pkg using xcrun notarytool, and then staple to the pkg. This is actually the same issue described in: https://developer.apple.com/forums/thread/711713 https://developer.apple.com/forums/thread/667597 https://developer.apple.com/forums/thread/742992 https://developer.apple.com/forums/thread/728063 but it's been a while since any of these threads were updated, and we've made attempts to address it off the suggestions in the threads to no avail. Those suggestions are: Switching to a .pkg installer from a .dmg As part of the .pkg preinstall, doing all of the following: Stopping the VPN (scutil --nc stop), shutting down the app (using osascript 'quit app id'), and deleting the app (which claims to delete the network extension, but not the approval in Login Items & Extensions remains??), by running rm -rf on the bundle in /Applications As part of the .pkg postinstall: Forcing macOS to ingest the App bundle's notarization ticket using spctl --assess. Ensuring NSXPCListener.resume() is called after autoreleasepool { NEProvider.startSystemExtensionMode() } (mentioned in a forum thread above as a fix, did not help.) One thing I'm particularly interested in is the outcome of this feedback assistant ticket, as I can't view it: FB11086599. It was shared on this forum in the first thread above, and supposedly describes the same issue. I almost find it hard to believe that this issue has been around for this many years without a workaround (there's system network extension apps out there that appear to work fine when updating, are they not using XPC?), so I wonder if there's a fix described in that FB ticket. Since I can't view that above feedback ticket, I've created my own: FB17032197

Hello, We have a SwiftUI-based application that runs as a LaunchAgent and communicates with other internal components using Unix domain sockets (UDS). On Sequoia (macOS virtualized environment), when installing the app, we encounter the Local Network Privacy Alert, asking: "Allow [AppName] to find and connect to devices on the local network?" We are not using any actual network communication — only interprocess communication via UDS. Is there a way to prevent this system prompt, either through MDM configuration or by adjusting our socket-related implementation? Here's a brief look at our Swift/NIO usage: class ClientHandler: ChannelInboundHandler { ... public func channelRead(context: ChannelHandlerContext, data: NIOAny) { ... } ... } // init bootstrap. var bootstrap: ClientBootstrap { return ClientBootstrap(group: group) // Also tried to remove the .so_reuseaddr, the prompt was still there. .channelOption(ChannelOptions.socketOption(.so_reuseaddr), value: 1) .channelInitializer { channel in // Add ChannelInboundHandler reader. channel.pipeline.addHandler(ClientHandler()) } } // connect to the UDS. self.bootstrap.connect(unixDomainSocketPath: self.path).whenSuccess { (channel) in .. self.channel = channel } ... ... // Send some data. self.channel?.writeAndFlush(buffer).wait() Any guidance would be greatly appreciated.

Recently, my application was having trouble sending udp messages after it was reinstalled. The cause of the problem was initially that I did not grant local network permissions when I reinstalled, I was aware of the problem, so udp worked fine after I granted permissions. However, the next time I repeat the previous operation, I also do not grant local network permissions, and then turn it back on in the Settings, and udp does not work properly (no messages can be sent, the system version and code have not changed). Fortunately, udp worked after rebooting the phone, and more importantly, I was able to repeat the problem many times. So I want to know if the process between when I re-uninstall the app and deny local network permissions, and when I turn it back on in Settings, is that permissions have been granted normally, and not fake, and not required a reboot to reset something for udp to take effect. I'm not sure if it's the system, or if it's a similar situation as described here, hopefully that will help me find out

I am creating an application that needs to connect to an Iot device, so i want to make a wifi hotspot with a custom SSID and password and WPA3. Could you please provide an example code in Objective-C to get started?

On an iOS 18 device, after installing the application and initially denying local network permission when prompted, manually enabling this permission in the system settings does not resolve the issue. After uninstalling and reinstalling the app, although local network access is granted, the app cannot discover smart hardware devices over the local area network (LAN) or proceed with configuration. The smart hardware sends configuration data packets over the LAN, but the app fails to receive these packets. This issue persists even after another uninstall and reinstall of the app. However, rebooting the device restores normal functionality. Steps to Reproduce: Install the application on an iOS 18 device. Upon first launch, deny the request for local network permissions. Manually enable local network permissions via "Settings" > [App Name]. Uninstall and then reinstall the application. Attempt to discover and configure smart hardware devices using the app. Notice that the app fails to receive configuration data packets sent by the smart hardware over the LAN. Expected Result: The application should be able to normally receive configuration data packets from smart hardware devices over the LAN and successfully complete the configuration process after obtaining local network permissions. Actual Result: Even after being granted local network permissions, the application cannot discover devices or receive configuration data packets over the LAN unless the iPhone device is rebooted. (reinstall app and obtaining local network permissions is not work too.)

Hello, I encountered a memory management issue while developing VPN functionality and would like to seek your advice. The specific phenomenon is as follows: Problem description: After multiple calls to the 'createTCPConnectToEndpoint' and 'create UDPSessionToEndpoint' interfaces to create connection objects, the application memory continues to grow. Even if the cancel interface is immediately called to actively release the object, the memory does not fall back. 3. Confirm that there is no other code referencing these objects, but the system does not seem to automatically reclaim memory. Attempted measures: Immediately call the cancel method after creating the object, and the memory is not reduced Use tools such as Profiler to monitor memory and confirm that objects have not been released. doubt: Is this phenomenon normal? Is there a known memory management mechanism (such as cache pooling) that causes delayed release? 2. Are there any other interfaces or methods (such as release, dispose) that need to be explicitly called? Supplementary Information: Development environment: [iOS 16, 14pm] Reproduction steps: After continuously creating connection objects, the memory grows without falling back. Could you please help confirm if there are any abnormalities and the correct memory release posture. Thank you for your support!