That's what I was wondering, glad is sounds sane.

I clearly missed that!

I still can't find it. 😩

I found some sample code elsewhere, and -- unless I'm missing something, which is quite likely -- it will not work with a CLI tool, because it needs to know the bundle name.

I was so tired this weekend that I couldn't go into that; I know it's possible (using it at work for a couple of daemons), but I just couldn't think. 😄 I was trying to make a little CLI utility that could look at the data a SwiftUI app dealt with.

Oh, that's very nice. What we ended up doing was to build twice -- once for x86_64 and once for arm64. After both builds finish, I then have a script go through the set of executables I expect, and use lipo and codesign to create a universal bundle.

Ok, I created FB12959624 with the trace bundle attached.

And now, during automated tests, we're apparently not getting prompted to install a new root CA. Sometimes. This is being done via Installer/installer, and a post-install script that uses the security command to install the root CA as trusted. We're installing using /usr/bin/security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ${APP_SUPPORT_PATH}/root.crt and /usr/bin/security remove-trusted-cert -d ${APP_SUPPORT_PATH}/root.crt to remove it.

That makes sense, but it also seems to make it difficult to tell where in a trace memory is being allocated -- we're trying to figure out why our memory footprint goes up by a lot in some cases, and this behaviour doesn't make Instruments particularly helpful in that regard, no?

It seemed so wrong to me that I wrote a test application, and FB13152737 with it attached.

I did eventually get it working, but it's annoying. The sort is an @State 'cause I am playing around and experimenting, which is why this particular failure was frustrating.

Wellllllll I fired up the Sonoma VM (which is some 5000 miles away from me), and it works there, therefore this seems to be a bug in macOS 13.

I asked here because we want to block a single udp port while our app is running, which means making a packet filter extension seems overkill. But I'm thinking that we may not have a lot of choice.

Ok, back to adding a second network extension I guess. (First one being a Transparent Proxy Provider, as oft mentioned. I know I can in fact put a packet filter into the same executable [although I have no idea if that's supported], but the management got annoyingly complicated.)

Found it -- DerivedFile directory was set to the same for both.