After upgrading the virtual machines used for building and testing our macOS application, it seems that something new in Sequoia is preventing virtual machines from running anything signed with a Mac Development certificate. At first glance the issue seems very similar to this thread, but it could be unrelated. We are using the tart toolset to build and run our VMs. People seem to be having related issues there with Sequoia in particular. I have added the VM's hardware UUID to the Devices list of our account. I have included that device in the devices list of our Mac Development provisioning profile. I have re-downloaded the profile, ensured that it is properly getting built into the app, and ensured that the hardware UUID of the VM matches the embedded provisioning profile: Virtual-Machine App.app/Contents % system_profiler SPHardwareDataType | grep UUID Hardware UUID: 0CAE034E-C837-53E6-BA67-3B2CC7AD3719 Virtual-Machine App.app/Contents % grep 0CAE034E-C837-53E6-BA67-3B2CC7AD3719 ../../App.app/Contents/embedded.provisionprofile Binary file ../../App.app/Contents/embedded.provisionprofile matches However, when I try to run the application, it fails, and while I have searched the system logs to find a more informative error message, the only thing I can find is that the profile doesn't match the device somehow: Virtual-Machine App.app/Contents % open ../../App.app The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x6000039440f0 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}} Virtual-Machine App.app/Contents % log show --info --debug --signpost --last 3m | grep -i embedded.provisionprofile 2025-01-21 16:33:32.369829+0000 0x65ba Error 0x0 2872 7 taskgated-helper: (ConfigurationProfiles) [com.apple.ManagedClient:ProvisioningProfiles] embedded provisioning profile not valid: file:///private/tmp/builds/app/.caches/Xcode/DerivedData/Build/Products/Debug/App.app/Contents/embedded.provisionprofile error: Error Domain=CPProfileManager Code=-212 "Provisioning profile does not allow this device." UserInfo={NSLocalizedDescription=Provisioning profile does not allow this device.} I don't understand why the provisioning profile wouldn't allow the device if the hardware UUID matches. I have also attempted to add the Provisioning UDID in the devices list instead, but the form rejects that value because it's a different format (the form specifically requests a hardware UUID for macOS development, and a provisioning UDID for everything else). If there is any debugging tool that lets me check a provisioning profile against the running hardware and print a more verbose reason for why it's not allowed on the device, please let me know. Otherwise I'd have to conclude that, since I haven't experienced this issue before on an earlier OS, it has something to do with virtual machines running macOS Sequoia. (The same Mac Development-signed application runs just fine on my MacBook Pro running 15.2, as well as the VM host, which is also running 15.2.) I have also tried resetting the VM's hardware UUID and adding that one to the devices list, to no effect. This is obviously seriously impacting our CI/CD pipelines to allow for proper UI testing of our application. If anyone is aware of any workarounds, I would love to hear them!

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.

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 .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.

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?

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?

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.