Yesterday, I was playing with an accessibility feature in visionOS to make it easier to see what buttons the user (me) is looking at. You might want to check it out (I'm sure I found it in System Settings), and see if it helps at all. I think, for privacy reasons, Apple prevents an app from capturing a user's gaze information.

The problem is using TestFlight with an app with a network system extension. In the last two days, I Released an app via the Mac App Store. Used Apple Configurator to restore a Mac mini to macOS 13.6 and Safari 16.6 Installed the app with network system extension from the App Store and installed the network system extension. Upgraded from Safari 16.6 to 17.2.1 (which had caused problems when deployed with TestFlight). No problem. Upgraded from macOS 13.6 to 13.6.3 (which had caused problems when deployed with TestFlight). No problem. Upgraded from macOS 13.6.3 to 14.2.1 (which had caused problems when deployed with TestFlight). No problem. Verified the problem still exists today by sending out the released program via TestFlight, and it killed networking when doing one of the upgrades. As of this writing (2024-01-04), I would not recommend using TestFlight for testing an app with a network system extension.

Current work around Shot a few seconds of video on iPhone at 30 fps Exported video to file system Created new iMovie project Added iPhone video to iMovie project first Added screen grab video after it Added blank sound track to screen grab portion Deleted original iPhone video from project Export video from iMovie Video has a frame rate of 29.97 fps (yay) Progress, but new error: "Your app preview is too large" From QuickTime Player Inspector: Resolution: 1920 x 1080 (which matches requirements) Current Size: 3456 x 1944 (in QuickTime Player) Video size: 21.6 MB (I thought this was within requirements) Still working on this... (ah, exceeded 30 second maximum length)

I have filed another feedback, FB13468019, this one targeted at TestFlight.

The bug may be tied to TestFlight. I ran another test. Created another instance of macOS 14.1.2. Deployed my app with a Development provisioning profile for the main app and network system extension. Upgraded to macOS 14.2. Everything proceeded smoothly. No loss of networking. No complaints of invalid profile. Everything just worked. I started the process of testing a 3rd distribution method using Developer ID and content-filter-provider-systemextension instead of content-filter-provider, but the process looked complicated. I'll wait to see if Apple gives any guidance (or fixes) TestFlight.

Bundle IDs follow the correct form. I use Xcode's archive to sign and submit the code to the App Store. This morning, I repeated the experiment: install a fresh copy of macOS 14.1.2 install app and then its network system extension but this time I uninstalled the network system extension before upgrading to 14.2 Upgraded to 14.2 This time networking worked from the beginning, but I still could not run the main application. It looks like Apple is following a "fail secure" approach when a network system extension fails (i.e., if a network system extension fails, no networking is allowed) as opposed to a "fail open" approach. As a user and a 3rd party developer, I would prefer a "fail open" approach. I will test alternative distribution approaches ((1) test version using the computer's registered UUID, and (2) independent distribution after notarizing the app) to see how the system behaves.

Here are some additional console messages if it helps: Disallowing com.xxxxxxxxxxxxxxxx.networkagent because no eligible provisioning profiles found /Library/SystemExtensions/ACB1E368-5355-4959-9800-737ED2BE9EDC/com.xxxxxxxxxxxxxxxx.networkagent.systemextension/Contents/MacOS/com.xxxxxxx.xxxxxxxxxnetworkagent not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=file:///Library/SystemExtensions/ACB1E368-5355-4959-9800-737ED2BE9EDC/com.xxxxxxxxxxxxxxxx.networkagent.systemextension/, NSLocalizedDescription=No matching profile found} mac_vnode_check_signature: /Library/SystemExtensions/ACB1E368-5355-4959-9800-737ED2BE9EDC/com.xxxxxxxxxxxxxxxx.networkagent.systemextension/Contents/MacOS/com.xxxxxxxxxxxxxxxx.networkagent: code signature validation failed fatally: When validating /Library/SystemExtensions/ACB1E368-5355-4959-9800-737ED2BE9EDC/com.xxxxxxxxxxxxxxxx.networkagent.systemextension/Contents/MacOS/com.xxxxxxxxxxxxxxxx.networkagent: Code has restricted entitlements, but the validation of its code signature failed. Unsatisfied Entitlements: proc 2260: load code signature error 4 for file "com.xxxxxxxxxxxxxxxx.networkagent" ASP: Security policy would not allow process: 2260, /Library/SystemExtensions/ACB1E368-5355-4959-9800-737ED2BE9EDC/com.xxxxxxxxxxxxxxxx.networkagent.systemextension/Contents/MacOS/com.xxxxxxxxxxxxxxxx.networkagent

Update: I am having a very similar problem updating to the beta of macOS 14.2. When the beta (via TestFlight) of my app is installed with the network system extension installed with Sonoma 14.1.2, and then I update to the beta of macOS 14.2, I lose all networking. Once I remove the network system extension, networking immediately returns. I can then re-install the network system extension with no problems. Having the network system extension installed when updating breaks networking. Perhaps it is because the network system extension was distributed through TestFlight (?). Filed feedback: FB13458972

This weekend I'll try building SImpleFirewall again using another one of my accounts that does not have endpoint capabilities. Maybe I'll be able to duplicate the issue then.

Interesting. I'll see if I can get similar errors, but I'm short for time today. Some of the many mistakes I make include: (1) Forgetting to run the application in the /Applications folder (2) Leaving behind an old System Extension from a previous run. From the Terminal, run systemextensionsctl list to see what is there and enabled. I think I've had problems when the build number for the network system extension that is installed is older than the current build number for the new network system extension. Sometimes, when I get a lot of old ones, I reboot my Mac to clean out the terminated system extensions. (3) Making sure "System Extension" capability is added to the main app's Signing & Capabilities section (it should be for the SimpleFirewall app already) (4) Run it only on the machine you compile it on, or go through a dance of getting and installing provisioning profiles (including specifying the machines that you want to test on). (This may be only needed for the endpoint system extensions; not certain). (5) I think I once ran into a situation where my devices I added to the provisioning profile had expired, but I don't see expiration dates on the devices now at the portal. Regarding disabling SIP, I think (but not certain again) that may only be needed with the endpoint system extension until your organization gets the endpoint capability granted from Apple. I am confused about the warning about "com.apple.developer.endpoint-security.client" you received. I don't think that is needed for network system extension for the firewall.

I got it running with some simple modifications (and I turned it into a network logger instead of blocking some connections). It might serve as a starting point for a richer firewall capability. (1) In the project's "Info" tab, I changed the macOS Deployment Target to 11.0 (because of something I wanted in os_log()) (2) For both targets, in "Signing & Capabilities" tabs, I changed the Team to my organization. (3) At some point Xcode gives a lot of warnings about changes that should be made to bring it up to date with latest Swift, I let it do that. (4) I simplified FilterDataProvider.swift to make it a simple logger (it doesn't actually block any connections) override func startFilter(completionHandler: @escaping (Error?) -> Void) { completionHandler(nil) } and override func handleNewFlow(_ flow: NEFilterFlow) -> NEFilterNewFlowVerdict { var localName: String = "" var remoteName: String = "" var remotePort: String = "" guard let socketFlow = flow as? NEFilterSocketFlow else { return .allow() } if let remoteEndpoint = socketFlow.remoteEndpoint, let localEndpoint = socketFlow.localEndpoint { if let hostEndpoint = localEndpoint as? NWHostEndpoint { localName = hostEndpoint.hostname } if let hostEndpoint = remoteEndpoint as? NWHostEndpoint { remoteName = hostEndpoint.hostname remotePort = hostEndpoint.port } } os_log("firewall log \(localName, privacy: .public) -> \(remoteName, privacy: .public) : \(remotePort, privacy: .public)") return .allow() } (5) I built it and then dragged the application into the Applications folder and ran it from there. (6) Then I used the Console app to look for the connection logs. I did this by setting a filter to "firewall" (1), then set the filter type to "process" (2), hit the play button (3), and then looked for the log statements (4).

I think there may have been an issue with a software update installer (and not the OS update itself) and network system extensions. I was able to replicate the problem with Ventura 13.6.1 with Safari 16.6, and then apply the update to Safari 17.1.2 - I got the loss of all networking. But starting Sunday morning, the problem seemed to go away. I could not replicate the issue with Sonoma because I could not rollback to an older version of Sonoma that needed to be updated. (Is there a way to download an older version of Sonoma or Ventura than the latest version you can download from the Mac App Store?) I documented the Ventura experiments here: https://developer.apple.com/forums/thread/742505

This morning I repeated the experiment, and there was no loss of networking. Again, experiment began with a clean install of macOS Ventura 13.6.1 and Safari 16.6, network system extension installed, and then upgraded Safari to 17.1.2. This time everything worked! There were no problems Maybe Apple modified one of the installer script (e.g., I see things like Perl running in the background during the upgrade process)? I hope Apple can provide some clarity to me, so I know what to look out for in the future.

FYI: I posted a feedback on this: FB13437047

Ah! Not being the Account Holder, I do not even see the "Developer ID Installer" option when creating a certificate in the developer portal. I'll get the account holder to generate this for me.