You're saying I'm right, but you think I'm using the wrong words (which is likely true), so you're being more precise. That's how I read it, anyway.

Yes, but if it only handles TCP and UDP, then why does .any cause it to break things? That should still only be TCP and UDP, shouldn't it?

You mean in Xcode? Or in App Store Connect? ’cause App Store Connect Help > Add, Edit, and delete users > Add and edit users is pretty clear that individual teams can’t add extra developers. It wasn't clear to me, and it hasn't been clear to people I've asked, so much so that I have filed a TSI. They’re working on the Mac, where this requirement isn’t so tightly enforced. I'm working on a Mac, and this seems pretty tightly enforced. Maybe I picked the wrong model for the app when generating the profile.

I disagree. Apple platforms track apps by their bundle ID. Apps from different teams are by definition different, and thus they have to have a different bundle ID. I am trying to figure out how to set up a team. That's in the question, it really is. You mean in Xcode? Or in App Store Connect? ’cause App Store Connect Help > Add, Edit, and delete users > Add and edit users is pretty clear that individual teams can’t add extra developers. That is correct. It says: All users receive access only to App Store Connect and are not considered part of your team in the Apple Developer Program. So how do I add members to my team in the Apple Developer Program? (Also, a bit related: how do I remove an app from the App Store Connect? Since I was told to try doing that, and now there's an app I'd like to remove. 😄) Requiring people to change project when working on a project together means that every single commit has to be checked, and possibly at least partially un-done. This doesn't scale, and I am in fact pretty sure that distributed teams don't do that. Again: if the answer is "well clearly everyone sets up an organization account," I have to again ask "And how do open-source projects do this? Most aren't going to be able to get a DUNS number." But, you know, I would be happy to accept that (I then have to get my group to do that, and it is a pretty significant burden) -- but the documentation needs to be updated. So how do I do this? It is clearly done. I'm assuming it's such a basic, obvious thing I did wrong that it hasn't occurred to anyone.

Oh my! I had tried changing it to $(TeamID).$(BUNDLE_IDENTIFIER), but I hadn't thought about changing the bundle identifier. (As I have just woken up, I will be testing later.)

I'm fine if the answer is "needs to be an organization," but nothing says that anywhere. Changing the bundle identifier is a hack. Clearly something can be done, because there are open-source macOS/iOS projects.

I keep getting terminology wrong -- downside to talking to myself a lot. 😄 So everything should be in, say, /Applications/Mediocre.app but we can (using MDM) have things pre-installed, including a LaunchDaemon or LaunchAgent or whatnot, right? Thank you again. 😄

Ok, so this is mostly solved now! I did in fact need an organizational account, which involved some hoops to jump through. I want to point out that dev support people have been remarkably helpful and patient. I've now got people invited to the team, and building seems to be normally. However, it seems that it is simply not possible to fix the "I accidentally and ignorantly added an app to App Store Connect that will never, ever, every be sent for approval and now that bundle ID is forever taken." I guess most developers don't make the mistakes I do. blush

Ha ha, sorry, I was not clear: I can have a LaunchDaemon, that would normally be installed as part of the app, installed via MDM stuff, and, completely separately, the app could be installed via the same mechanism to /Applications and would not need to be run a first time to install the daemon. The answer to that sounds like a confident yes, which pleases me.

Amusingly, the forum software doesn't let me insult myself. 😄 Good for it, I say.

Then shouldn't that be mentioned somewhere? 😄 Especially since I can read a lot more than that off a socket, and the VPN extensions present themselves as data, not IP, based?

The answer is: it's "behaving correctly," because the command is deprecated, and removed in Monterey.

Well, part of my uncertainty there was, how do I unit-test the methods that are supposed to be delegates of system APIs? As an example, handleNewFlow. I'm guessing that won't particularly be doable? Although since the data going back and forth is actual data, not IP packets, that makes writing tests for those easier. 😄

Oooh! CSIdentityQueryCreateForCurrentUser looks like it, maybe? I will experiment! Thank you! 😄 Edited to Add Yes, that worked! My code here is really ugly, but it does seem to work. So thank you very much! { CSIdentityQueryRef query; CFErrorRef error; CFArrayRef identityArray; // create the identity query based on name query = CSIdentityQueryCreateForCurrentUser(kCFAllocatorDefault);   // execute the query if (CSIdentityQueryExecute(query, kCSIdentityQueryGenerateUpdateEvents, &error)) { printf("Success!\n"); // retrieve the results of the identity query identityArray = CSIdentityQueryCopyResults(query); printf("Got %lu entries in the array\n", CFArrayGetCount(identityArray)); for (size_t indx = 0; indx < CFArrayGetCount(identityArray); indx++) { CSIdentityRef identity = (CSIdentityRef)CFArrayGetValueAtIndex(identityArray, indx); CFStringRef name = CSIdentityGetPosixName(identity); const size_t maxSize = 1024; char *buffer = (char *)malloc(maxSize); if (CFStringGetCString(name, buffer, maxSize,       kCFStringEncodingUTF8)) { printf("Current user = %s\n", buffer); } else { printf("Could not get user string?\n"); } } // do something with identityArray //     return (CSIdentityRef)CFArrayGetValueAtIndex(users, 0);     } CFRelease(query); }

Oh darn it! No, that doesn't work! I forgot to test while actually using FUS, and in the one session, it continues to show the same user, even if I switch to between users. :(