I will have to try that! That would simplify things greatly!

And I tried it again, and once again am hit by the fact that I can't delete a certificate once it's been created, so now I have two that are indistinguishable, and neither of the works. 😭

sigh. It ate my reply. Having horrible success with Apple today :(. Trying to rewrite it from memory: I can load the extension. I have another network extension in the app -- a transparent proxy provider, while this new one is a content filter provider. I can save the preferences for the TPP, but when I try to save it for the packet filter extension, I get permission denied (error 10). The application is in /Applications (thus allowing both extensions to load). Quinn's debug post does not cover that issue. I had a test program that worked, but after the issues (described elsewhere today) with my Developer ID Application certificate, I can't build it at all anymore. And Xcode keeps revoking my certificate because the private key isn't in a keychain, which does nothing, so it keeps trying to do that, and I can't get it back to building. sob

Yes I discovered the problem with not being able to delete certificates the hard way. This is an epic failure on Apple's part, I still maintain. As is the inability to identify them in the portal. However: I created a request using Certificate Assistant; I uploaded it into the portal; I downloaded the certificate, and opened it via Finder. And it was unable to import it. I tried importing it on another machine. I think I was able to import it into the System keychain, which is not a good idea at all, but then it didn't have a matching key. I followed the instructions. It failed badly. I have no idea what to do next. Xcode revoked a bunch of certificates, it claims, but I have no idea which ones, and now I cannot build.

And.... after a reboot, it was still not working. Then I went out to go to the immigration office, and when I came back... there were the two Developer IDs I created, and both had private keys now. And now Xcode builds my test app for me. Debug & Release. I am completely flabbergasted Quinn.

I have never tried to have a different file used in building based on configuration, but I assume that's what I have to do, yeah? Although it turns out I have no idea how to do that for the entitlements file.

Ok! Figured it out. This is, however, fairly annoying, but I suspect filing an enhancement request won't go too far. (It didn't help that I've had a bad headache much of today.)

It doesn't appear to be. But! We have two network extensions, and they both show up with the same name, so could that be the problem? If so, how would I ensure that the content filter gets a different configuration name than the transparent proxy provider one?

For one, I duplicated it in Finder; for the other, I saw that Xcode's File menu had that as well, so did it that way. Then I opened them up in vi and changed them. Then I changed the build settings for the two targets, so that Debug and Release use different entitlement files.

It was easy enough to do in CMake, since it has support for processing an input file, and that was so easily done I forgot about it until just now. 😄 (Is there a similar way to do that with the entitlements file in Xcode? I'm thinking not, based on everything.)

Weirdly, although it's still giving me that error, it seems to have activated the packet filter. I still have no idea what's going on there!

Hm, no, I tried that, and it fails with openssl -- looks like it's trying to compile x86 assembly for arm64 architecture. 😩

So, if I'm understanding this, #Predicate can not use @Model objects, but only members? (And if a member is itself a @Model object, this recurses infinitely?) (And, on top of that, cannot use any method parameters or struct/class members, but can capture local variables?)

I can do relationships -- but only one level. In my example above, $0.room?.id works, but $0.room?.home?.id does not.

In practice, I was using completion to do the context.save() so I can deal with workarounds. But it... seems to totally defeat the purpose of @Bindable and requiring a context.save() if you can't get back to an earlier state.