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

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?)

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

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!

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

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

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

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.

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.

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.

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

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

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

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