I know it's already possible to inclusively establish a VPN connection with NETunnelPacketProvider by instantiating an NEAppRule for each of the processes I want included in the network connection, and setting that list as the appRules property (documented here). I'd like to know if there's a way to include all apps/processes by default, and only specify the processes that I'd like to exclude from the VPN connection.

NEPacketTunnelProvider lets you open a TCP connection with or without TLS through the extension's tunnel using the createTCPConnectionThroughTunnel function. However, this function returns a NWTCPConnection, which only has affordances for reading and writing raw data over the connection. Is there any way for me to construct a URLSession or URLRequest that can use this existing connection, so that I can send and receive HTTP data over it without having to roll my own HTTP request/response parsing?

The documentation for NEProviderTunnelSession.sendProviderMessage says the following: If this method can’t start sending the message it reports an error in the returnError parameter. If an error occurs while sending the message or returning the result, nil should be sent to the response handler as notification. My question is, what sorts of errors can occur that would result in this function calling the completion handler with a nil value? When I'm returning an error explicitly to the client from my network extension, I call back with a specific piece of data that indicates an error condition (beginning with the byte 255.) However, I still occasionally get a callback with a nil value, which results in the app sometimes getting confused. I don't notice anything wrong from the extension's side when I check its logs. What issue in the message sending layer might be causing this? Is there a process whose logs I can monitor that might shine some light on the problem and show me what problem I need to avoid?

The .includeAllNetworks flag on the NEVPNProtocol object seems suitable for use as a vpn "kill switch." At the very least, the documentation specifies that "if this value is true and the tunnel is unavailable, the system drops all network traffic." Our application has a UI element that allows the user to toggle this setting, for the purposes of ensuring that all of their traffic is sent through the VPN connection. We're encountering an issue, however: it appears that, with this setting enabled, any NWTCPConnection returned by NEPacketTunnelProvider.createTCPConnectionThroughTunnel will never connect. It stays in the .connecting state and never advances to the .connected state. The documentation for this method states that this method can be used "to create a TCP connection to an endpoint inside the private network." Does this mean that the remote endpoint being connected to by createTCPConnectionThroughTunnel must reside inside the private network being connected to by the tunnel in order for it to work properly with the .includeAllNetworks setting? Or is the documentation simply suggesting that the TCP connection is tunneled through the private network? Other web pages seem to be loading just fine while this tunnel is active, it is just the connections returned by this function that seem to be timing out with .includeAllNetworks set to true. If I set it to false, the NWTCPConnection objects returned by this function transition to the .connected state just fine and data can be passed through them with no problems. Is this expected behavior, or is this a possible manifestation of something misconfigured in the VPN profile? Edit: I tested a bit more and it looks like even local connections over the private network seem to time out; I set up an endpoint within the VPN at 10.1.0.1 and createTCPConnectionThroughTunnel was still unable to connect with .includeAllNetworks set to true.

Hello, I have a multi-platform app that is split across two organizations: One is on iOS, and is distributed using the App Store with bundle ID X with team ID A. One is on macOS, and is distributed using Developer ID with bundle ID Y with team ID B. Once again, these are in two separate organizations. To consolidate these accounts we'd like to transfer ownership of Y to team ID A. However, according to the app transfer criteria, it appears that that's not possible: Both the transferor and recipient accounts can’t be in a pending or changing state, and the latest version of their paid and free agreements must be accepted. [...] The app must have had at least one version that's been approved for distribution. Given the context from the rest of the page, it seems valid to assume (and I've confirmed this through speaking with technical support) that apps are only eligible for transfer if they've been submitted to the App Store, so I'm considering looking into it just for the purposes of this transfer. This app has a fairly large user base and if possible we want to avoid any user disruption (and any cost inflicted on our API) as a result of a forced logout due to losing access to the previous keychain. As a bonus, it would be nice, though not necessary, if the macOS app could ship under the same entry as the iOS app. As I understand it, this would require changing the macOS app to use bundle ID X. Before going down this road, I'd like to confirm if the following plan is a sane one for accomplishing a complete app transfer that satisfies the above requirements: Distribute the app on the macOS App Store under team ID B. Transfer the app, and continue distribution on the macOS App Store under team ID A. Obtain a new Developer ID certificate for using bundle ID Y with team ID B. Resume distribution of the Developer-ID-signed app with team ID B, without loss of keychain access. If loss of keychain access is not possible, can someone confirm if it is at least possible to keep the same bundle ID after performing the steps above? Many thanks in advance for your help - there is much conflicting information online and in this forum, and little documentation when it comes to Developer ID transfers. I've even spoken to several Apple employees who have directed me here.

The documentation for the defaultPath property of NEProvider is as follows: This NWPath object contains information about which physical network interface will be used by connections opened by the Network Extension provider. You can determine when this physical interface changes by observing this property using KVO. However, I have noticed that it is deprecated as of iOS 18. Is there any existing replacement for this functionality since it has been deprecated, or is a new replacement on the horizon? This is very useful for network extensions in order to detect changes to the network, for instance when moving from WiFi to mobile data.