Apologies if this is not the correct topic to post under. EpochField 5.2 is our application. It's a .NET MAUI application built against XCode 16. A customer of ours uses another app, TN3270, to connect to a mainframe host. After installing our app on an iPad and restarting the device, the TN3270 app will disconnect when suspended. Uninstalling our app (EpochField) will allow the TN3270 to suspend without disconnecting. We have tried removing background services, setting UIRequiresFullScreen to false or removing it entirely, and several other ideas. The only remedy seems to be uninstalling EpochField. On an iPad device: Install MochaSoft’s TN3270 app (free version is fine). Create a connection to ssl3270.nccourts.org, port 2023, SSL/TLS turned on, keep alive turned on. Verify that you can connect. Suspend the app by swiping up or choosing another app. Go back to TN3270 and verify that the app has not disconnected. Install EpochField 5.2. Do not run or configure the app, just install it. Repeat step 2. Restart the device. Open EpochField 5.2. You do not need to configure the app or login. Sometimes it isn't necessary to ever open EpochField to get the disconnects, but this is the most reliable way to reproduce the situation. Repeat step 2. The TN3270 app will now disconnect when suspended, even if EpochField is closed. You may need to wait a few seconds after suspending. Uninstall EpochField 5.2. Repeat step 2: the TN3270 app will now remain connected when suspended.

I am trying to migrate an app to use Network framework for p2p connection. I came across this great article for migrating to Network framework however this doesnt use the new structured concurrency. This being introduced with iOS 26, there doesnt seem to be any sample code available on how to use the new classes. I am particularly interested in code samples showing how to add TLS with PSK encryption support and handling of switching between Wifi and peer to peer interface with the new structured concurrency supported classes. Are there any good resources I can refer on this other than the WWDC video?

Are the Wifi-Aware's WAEndpoint's discovered ephemeral? I'm trying to understand what's the best way to reconnect a disconnected WifiAware connection - Can I just cache the endpoint and start a new connection with the same endpoint or do I need to browse again and get a new WAEndpoint? My use case requires both WifiAware connection to another device and the devices also need to be connected to infrastructure wifi most of the time. I'm concerned about the WifiAware's connection having any impact on infrastructure wifi. What is the impact on the infrastructure wifi here in comparison to using the Apple peer to peer wifi(That Multipeer framework or Network framework use)?

Hi everyone, I’m encountering what appears to be a system-level issue with NEAppPushProvider extensions being unable to communicate with other devices on the local network, even when the main app has already been granted Local Network permission by the user. Context The following problem occurs in an iPad app running iOS 18.5. The main app successfully requests and is granted Local Network access via NSLocalNetworkUsageDescription in its Info.plist configuration. It can connect to a WebSocket server hosted on the local network without any issues, resolving its address by name. The extension (NEAppPushProvider) uses the same networking code as the app, extended via target membership of a controller class. It attempts to connect to the same hostname and port but consistently fails to establish a connection. The system log shows it properly resolving DNS but being stopped due to "local network prohibited". An extract of the logs from the Unified Logging System: 12:34:10.086064+0200 PushProvider [C526 Hostname#fd7b1452:8443 initial parent-flow ((null))] event: path:start @0.000s 12:34:10.087363+0200 PushProvider [C526 Hostname#fd7b1452:8443 waiting parent-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: path:satisfied @0.005s 12:34:10.090074+0200 PushProvider [C526 Hostname#fd7b1452:8443 in_progress parent-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: flow:start_connect @0.006s 12:34:10.093190+0200 PushProvider [C526.1 Hostname#fd7b1452:8443 in_progress resolver (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: resolver:start_dns @0.009s 12:34:10.094403+0200 PushProvider [C526.1.1 IPv4#f261a0dc:8443 waiting path (unsatisfied (Local network prohibited), interface: en0[802.11], ipv4, uses wifi)] event: path:unsatisfied @0.010s 12:34:10.098370+0200 PushProvider [C526.1.1.1 IPv4#f261a0dc:8443 failed path (unsatisfied (Local network prohibited), interface: en0[802.11], ipv4, uses wifi)] event: null:null @0.014s 12:34:10.098716+0200 PushProvider [C526.1 Hostname#fd7b1452:8443 failed resolver (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: resolver:children_failed @0.015s 12:34:10.099297+0200 PushProvider [C526 Hostname#fd7b1452:8443 waiting parent-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: flow:child_failed @0.016s What I’ve Confirmed: The extension works perfectly if the DNS is changed to resolve the name to a public IP instead of a local one. The extension always connects by hostname. Devices on the local network can resolve each other’s IP addresses correctly and respond to pings. What I’ve Tried Adding NSLocalNetworkUsageDescription to the main app’s Info.plist, as recommended. Clean building the project again. Removing and reinstalling the app to ensure permission prompts are triggered fresh. Restarting the iPad. Ensuring main app cannot access the local network until the permission is granted. Ensuring the main app has connected to the same hostname and port before the extension attempts a connection Toggling the permission manually in Settings. Apple’s documentation states (TN3179): “In general, app extensions share the Local Network privilege state of their container app.” It also notes that some background-running extension types may be denied access if the privilege is undetermined. But in my case, the main app clearly has Local Network access, and the extension never receives it, even after repeated successful connections by the main app. Question Is this a known limitation with NEAppPushProvider? Is there a recommended way to ensure the extension is able to use the local network permission once the user has granted it on the app? Any feedback, suggestions, or confirmation would be greatly appreciated. Thanks in advance.

Greetings.I have an app today that uses multipeer connectivity extensively. Currently, when the user switches away from the app, MPC disconnects the session(s) - this is by design apparently (per other feedback). I'd like to hear if anyone has experimented with iOS9 multitasking / multipeer and whether MPC sessions can stay alive?Thanks

I've had no problem running my app in a simulator or on a device, but today my app is failing on a URLRequest to my local machine (in a sim). From the same simulator I can go to Safari and manually enter the URL that the app is using (and that appears in the error message), and it works fine. I think there was a recent Xcode update; did something change in this regard?

Hello, I have been playing around the the SimpleURLFilter sample code. I keep getting this error upon installed the filter profile on the device: mapError unexpected error domain NEVPNConnectionErrorDomainPlugin code 7 which then causes this error: Received filter status change: <FilterStatus: 'stopped' errorMessage: 'The operation couldn’t be completed. (NetworkExtension.NEURLFilterManager.Error error 14.)'> I can't find much info about code 7. Here is the configuration I am trying to run: <Configuration: pirServerURL: 'http://MyComputer.local:8080' pirAuthenticationToken: 'AAAA' pirPrivacyPassIssuerURL: 'http://MyComputer.local:8080' enabled: 'true' shouldFailClosed: 'true' controlProviderBundleIdentifier: 'krpaul.SimpleURLFilter.SimpleURLFilterExtension' prefilterFetchInterval: '2700.0'>

I want to detect if the adapter is connected to the iPhone even if no IP has been given to the iPhone. I can detect that the interface is connected when the iPhone has been given an IP address, but how can I detect the adapter when not?

Hi everyone, I'm trying to establish a connection to a server that requires mutual TLS (mTLS) using NSURLSession in an iOS app. The server is configured with a self-signed root CA (in the project, we are using ca.cer) and requires clients to present a valid certificate during the TLS handshake. What I’ve done so far: Server trust is working: I manually trust the custom root CA using SecTrustSetAnchorCertificates and SecTrustEvaluateWithError. I also configured the necessary NSAppTransportSecurity exception in Info.plist to allow the server certificate to pass ATS. This is confirmed by logs showing: Server trust succeeded The .p12 identity is correctly created: Contains the client certificate and private key. Loaded using SecPKCS12Import with the correct password. I implemented the delegate method: func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -&gt; Void) { if challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust { // Server trust override code (working) ... } if challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodClientCertificate { print("🔐 Client cert challenge triggered") if let identity = loadIdentity() { let credential = URLCredential(identity: identity, certificates: nil, persistence: .forSession) completionHandler(.useCredential, credential) } else { completionHandler(.cancelAuthenticationChallenge, nil) } return } completionHandler(.performDefaultHandling, nil) } The session is correctly created using my custom delegate: let delegate = MTLSDelegate(identity: identity, certificates: certs) let session = URLSession(configuration: .default, delegate: delegate, delegateQueue: nil) Despite everything above, the client certificate is never sent, and the request fails with: Error Domain=NSURLErrorDomain Code=-1206 "The server requires a client certificate." From logs, it's clear the delegate is being hit for NSURLAuthenticationMethodServerTrust, but not for NSURLAuthenticationMethodClientCertificate.

Hello Apple Support Team, We are experiencing a performance issue with HTTP/3 in our iOS application during testing. Problem Description: Network requests using HTTP/3 are significantly slower than expected. This issue occurs on both Wi-Fi and 4G networks, with both IPv4 and IPv6. The same setup worked correctly in an earlier experiment. Key Observations: The slowdown disappears when the device uses: · A personal hotspot. · Network Link Conditioner (with no limitations applied). · Internet sharing from a MacBook via USB (where traffic was also inspected with Wireshark without issues). The problem is specific to HTTP/3 and does not occur with HTTP/2. The issue is reproducible on iOS 15, 18.7, and the latest iOS 26 beta. HTTP/3 is confirmed to be active (via assumeHttp3Capable and Alt-Svc header). Crucially, the same backend endpoint works with normal performance on Android devices and using curl with HTTP/3 support from the same network. I've checked the CFNetwork logs in the Console but haven't found any suspicious errors or obvious clues that explain the slowdown. We are using a standard URLSession with basic configuration. Attempted to collect qlog diagnostics by setting the QUIC_LOG_DIRECTORY=~/ tmp environment variable, but the logs were not generated. Question: What could cause HTTP/3 performance to improve only when the device is connected through a hotspot, unrestricted Network Link Conditioner, or USB-tethered connection? The fact that Android and curl work correctly points to an issue specific to the iOS network stack. Are there known conditions or policies (e.g., related to network interface handling, QoS, or specific packet processing) that could lead to this behavior? Additionally, why might the qlog environment variable fail to produce logs, and are there other ways to obtain detailed HTTP/3 diagnostic information from iOS? Any guidance on further diagnostic steps or specific system logs to examine would be greatly appreciated. Thank you for your assistance.

I did watch WWDC 2019 Session 716 and understand that an active audio session is key to unlocking low‑level networking on watchOS. I’m configuring my audio session and engine as follows: private func configureAudioSession(completion: @escaping (Bool) -> Void) { let audioSession = AVAudioSession.sharedInstance() do { try audioSession.setCategory(.playAndRecord, mode: .voiceChat, options: []) try audioSession.setActive(true, options: .notifyOthersOnDeactivation) // Retrieve sample rate and configure the audio format. let sampleRate = audioSession.sampleRate print("Active hardware sample rate: \(sampleRate)") audioFormat = AVAudioFormat(standardFormatWithSampleRate: sampleRate, channels: 1) // Configure the audio engine. audioInputNode = audioEngine.inputNode audioEngine.attach(audioPlayerNode) audioEngine.connect(audioPlayerNode, to: audioEngine.mainMixerNode, format: audioFormat) try audioEngine.start() completion(true) } catch { print("Error configuring audio session: \(error.localizedDescription)") completion(false) } } private func setupUDPConnection() { let parameters = NWParameters.udp parameters.includePeerToPeer = true connection = NWConnection(host: "***.***.xxxxx.***", port: 0000, using: parameters) setupNWConnectionHandlers() } private func setupTCPConnection() { let parameters = NWParameters.tcp connection = NWConnection(host: "***.***.xxxxx.***", port: 0000, using: parameters) setupNWConnectionHandlers() } private func setupWebSocketConnection() { guard let url = URL(string: "ws://***.***.xxxxx.***:0000") else { print("Invalid WebSocket URL") return } let session = URLSession(configuration: .default) webSocketTask = session.webSocketTask(with: url) webSocketTask?.resume() print("WebSocket connection initiated") sendAudioToServer() receiveDataFromServer() sendWebSocketPing(after: 0.6) } private func setupNWConnectionHandlers() { connection?.stateUpdateHandler = { [weak self] state in DispatchQueue.main.async { switch state { case .ready: print("Connected (NWConnection)") self?.isConnected = true self?.failToConnect = false self?.receiveDataFromServer() self?.sendAudioToServer() case .waiting(let error), .failed(let error): print("Connection error: \(error.localizedDescription)") DispatchQueue.main.asyncAfter(deadline: .now() + 2) { self?.setupNetwork() } case .cancelled: print("NWConnection cancelled") self?.isConnected = false default: break } } } connection?.start(queue: .main) } I am reaching out to seek further assistance regarding the challenges I've been experiencing with establishing a UDP, TCP & web socket connection on watchOS using NWConnection for duplex audio streaming. Despite implementing the recommendations provided earlier, I am still encountering difficulties. Or duplex audio streaming not possible on apple watch?

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

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://aninterestingwebsite.com/forums/thread/711713 https://aninterestingwebsite.com/forums/thread/667597 https://aninterestingwebsite.com/forums/thread/742992 https://aninterestingwebsite.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

We are having an issue with the Local Network permission pop-up not getting triggered for our apps that need to communicate with devices via local network interfaces/addresses. As we understand, apps using UDP should trigger this, causing macOS to prompt for access, or, if denied, fail to connect. However, we are facing issues with macOS not prompting this popup at all. Here are important and related points: Our application is packaged as a .app package and distributed independently (not on the App Store). The application controls hardware that we manufacture. In order to find the hardware on the network, we send a UDP broadcast with a message for our hardware on the local network, and the hardware responds with a message back. However, the popup (to ask for permission) never shows up. The application is not able to find the hardware device. It is interesting to note that data is still sent out to the network (without the popup) but we receive back the wrong data. The behaviour is consistent macOS Sequoia (and above) with both Apple And Intel silicon. Workarounds that have been tried: Manual Authorization: One solution suggested in various blogs was to go to "Settings → Privacy and Security-> Local network", find your application and grant access. However, the application never shows up in the list here. Firewall: No difference is seen in behaviour with firewall being ON OR OFF. Setting NSLocalNetworkUsageDescription: We have also tried setting the Info.plist adding the NSLocalNetworkUsageDescription with a meaningful string and updating the NSBonjourServices. Running Via terminal (WORKS): Running the application via terminal sees no issues. The application runs correctly and is able to send UDP and receive correct data (and find the devices on the network). But this is not an appropriate solution. How can we get this bug/issue fixed in macOS Sequoia (and above)? Are there any other solutions/workarounds that we can try on our end?

I'm struggling to understand why the async-await version of URLSession download task APIs do not call the delegate functions, whereas the old non-async version that returns a reference to the download task works just fine. Here is my sample code: class DownloadDelegate: NSObject, URLSessionDownloadDelegate { func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didWriteData bytesWritten: Int64, totalBytesWritten: Int64, totalBytesExpectedToWrite: Int64) { // This only prints the percentage of the download progress. let calculatedProgress = Float(totalBytesWritten) / Float(totalBytesExpectedToWrite) let formatter = NumberFormatter() formatter.numberStyle = .percent print(formatter.string(from: NSNumber(value: calculatedProgress))!) } } // Here's the VC. final class DownloadsViewController: UIViewController { private let url = URL(string: "https://pixabay.com/get/g0b9fa2936ff6a5078ea607398665e8151fc0c10df7db5c093e543314b883755ecd43eda2b7b5178a7e613a35541be6486885fb4a55d0777ba949aedccc807d8c_1280.jpg")! private let delegate = DownloadDelegate() private lazy var session = URLSession(configuration: .default, delegate: delegate, delegateQueue: nil) // for the async-await version private var task: Task&lt;Void, Never&gt;? // for the old version private var downloadTask: URLSessionDownloadTask? override func viewWillAppear(_ animated: Bool) { super.viewWillAppear(animated) task?.cancel() task = nil task = Task { let (_, _) = try! await session.download(for: URLRequest(url: url)) self.task = nil } // If I uncomment this, the progress listener delegate function above is called. // downloadTask?.cancel() // downloadTask = nil // downloadTask = session.downloadTask(with: URLRequest(url: url)) // downloadTask?.resume() } } What am I missing here?

This problem doesn’t appear to relate to the app as everything worked when using http (although an https setup issue may still be the problem). The problem appears to relate to the SSL server certificate on the Ubuntu server and the fact that apple does not accept that it is secure. However I have no problem with the equivalent Android app or web browser connections to the same rest API web services. There are numerous posts on these problems on Apple and other Forums, but none have helped me successfully address the issue. I ran an SSL server test on https://www.ssllabs.com/ssltest/ which gives ratings for SSL sites. The test gave an A rating although a number of minor issues were shown that may be crucial to the iOS failure. Some Sectigo certificates said self signed, which I couldn't understand. Error message from XCode log attached 2025-09-10 10:28:01.725091+0100 locateandclock[2291:1585213] ATS failed system trust 2025-09-10 10:28:01.725192+0100 locateandclock[2291:1585213] Connection 1: system TLS Trust evaluation failed(-9802) 2025-09-10 10:28:01.725291+0100 locateandclock[2291:1585213] Connection 1: TLS Trust encountered error 3:-9802 2025-09-10 10:28:01.725352+0100 locateandclock[2291:1585213] Connection 1: encountered error(3:-9802) 2025-09-10 10:28:01.726727+0100 locateandclock[2291:1585213] Task <4E41098F-6B71-4FB8-8753-78DD32961812>.<1> HTTP load failed, 0/0 bytes (error code: -1200 [3:-9802]) 2025-09-10 10:28:01.736504+0100 locateandclock[2291:1585213] Task <4E41098F-6B71-4FB8-8753-78DD32961812>.<1> finished with error [-1200] Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." UserInfo={NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, NSErrorPeerCertificateChainKey=( "<cert(0x10681be00) s: *.xxxxxxxxxxx.co.uk i: Sectigo Public Server Authentication CA DV R36>", "<cert(0x10681c800) s: Sectigo Public Server Authentication CA DV R36 i: Sectigo Public Server Authentication Root R46>", "<cert(0x10681d200) s: Sectigo Public Server Authentication Root R46 i: Sectigo Public Server Authentication Root R46>" ), NSErrorClientCertificateStateKey=0, NSErrorFailingURLKey=https://xxxxxxxxxxxx.co.uk/insertclocking, NSErrorFailingURLStringKey=https://xxxxxxxxxxxx.co.uk/insertclocking, NSUnderlyingError=0x282361650 {Error Domain=kCFErrorDomainCFNetwork Code=-1200 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, kCFStreamPropertySSLPeerTrust=<SecTrustRef: 0x281cf4460>, _kCFNetworkCFStreamSSLErrorOriginalValue=-9802, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9802, kCFStreamPropertySSLPeerCertificates=( "<cert(0x10681be00) s: *.xxxxxxxxxxxxxco.uk i: Sectigo Public Server Authentication CA DV R36>", "<cert(0x10681c800) s: Sectigo Public Server Authentication CA DV R36 i: Sectigo Public Server Authentication Root R46>", "<cert(0x10681d200) s: Sectigo Public Server Authentication Root R46 i: Sectigo Public Server Authentication Root R46>" )}}, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <4E41098F-6B71-4FB8-8753-78DD32961812>.<1>" ), _kCFStreamErrorCodeKey=-9802, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <4E41098F-6B71-4FB8-8753-78DD32961812>.<1>, NSURLErrorFailingURLPeerTrustErrorKey=<SecTrustRef: 0x281cf4460>, NSLocalizedDescription=An SSL error has occurred and a secure connection to the server cannot be made.}

Hello! 👋 I am noticing new failures in the iOS 18.5 Developer Beta build (22EF5042g) when calling the system call connect() (from C++ source, in network extension). When using cell/mobile data (Mint & T-Mobile) this returns with EINTR (interrupted system call) right away. When I switch over to wifi, everything works fine. Note: I have not tested on other mobile carriers; which could make a difference since T-Mobile/Mint are IPv6 networks. FWIW, this is working in the previous developer beta (18.4). Anyone have any ideas?

I use Iphone 17 wifi to test the device and mobile phone communicate,but I found the wifi disconnect innormal in hign frequency. This situation is only appears in iphone 17 series, iphone 14 and 15 is ok, so I think iphone 17 wifi chip or software has bugs. the local network disconnect in hign frequency.

We’ve noticed an issue where after running a network extension, if the phone’s language is changed the Locale.preferredLanguages array is not updated and still returns the old array. It only returns the updated array when the app is reinstalled or the phone is restarted. This is unlike the app itself where using the same Locale.preferredLanguages API immediately returns the updated array. We think this issue is also the cause of notifications that are sent by the network extension being in the previous language as long as the app isn’t reinstalled or the phone is restarted, despite our Localizable file having localised strings for the new language. Feedback ID: FB20086051 The feedback report includes a sample project with steps on how to reproduce the issue.

Question 1: After NetworkExtension is installed, when the software receives a pushed uninstall command, it needs to download the entire software but fails to uninstall this NetworkExtension. Are there any solutions? Question 2: How can residual, uninstalled NetworkExtensions be cleaned up when SIP (System Integrity Protection) is enabled?