Thanks Matt! Looks like it is not enforced for remote connections either. Filed a ticket FB9716553. From some logs we came through it looks like the Network framework tried to upgrade the connection to HTTPS and failed (expected because we didn't enable HTTPS on the target host during the test) and then it just fell back. Still to our own concern - being this close to release we don't expect this behavior to change in GA right? ;p

Answering my own question here in case anyone comes across the same. I figured out this crash happens if we call [[NSStatusBar systemStatusBar] statusItemWithLength:NSSquareStatusItemLength] when a graphic session is not available. E.g. if the code is executed through an ssh session without the same user on any active GUI session. Interesting that I tried the same with older macOS versions I don't see the crash (while I do see some error messages printed on console). It matches the fact that our crash reports have all been coming from macOS 12. What I still don't understand is that how come our code has been executed if there is no GUI (it is registered as a LaunchAgent) but I've opened a new post for that discussion (https://developer.apple.com/forums/thread/696859).

Thank you The Eskimo as always!

Thanks for the pointer to the Technote Eskimo! It was good reading. I presume that you’re not in touch with any of these users? That is unfortunately true. From crash logs alone we currently have no means to backtrack to the specific users. We'll have to wait for the users to come contacting us instead. Given that the crash is likely only happening without a GUI session it's likely they would not notice it for quite a while (or maybe not at all). For now I think my interpretation of your answer is that from the OS point of view, there is no official way (at least no known one) to be able to launch an agent under the Aqua type (and yes our launchd.plist doesn't specify LimitLoadToSessionType) while denying it access to the graphic context. So the users must have somehow either "monkeyed" with the system, or like you suggested, with our config. Assuming our hypothesis is true and there is no good option to prevent end users from doing what they are doing, currently our team has come up with an idea of detecting this situation (no GUI context) during our agent's startup in hoping to skip the entire AppKit entry call. Specifically we are thinking of calling CGWindowListCopyWindowInfo(kCGWindowListOptionAll, kCGNullWindowID) before we engage all UI related stuff. We verified that if we call this without graphic context we would get nil while otherwise we would get an array with something, which serves as an indicator to us. Does this sound like a practical idea or is there perhaps anything we overlooked?

SessionGetInfo sounds like a great idea! I'll forward it to our team. can you post a full crash report? Yes I can help with that. We already have a radar ticket on the original AppKit crash. Let me ask my colleague who filed it about the number and get back here. It's around the holidays though I might not be able to reach him soon. And in the likely case I don't post any feedback until New Year just want to wish you Happy Holidays Eskimo (and of course to anyone who stumbles on this post around this time of year), your help and advice are always appreciated!

Radar ticket for this - FB9800999

Happy New Year eskimo! The crash logs we collect from our customers are generated by PLCrashReporter I believe. It somehow yanks the system symbols out (sounds like a PLCrashReporter thing) and we don't have a convenient way to re-symbolicate that part. That said I'm fairly confident if we would symbolicate output_18765164.log it would produce exactly the same crashed stack as the bash one (apart from the fact of different parent processes). One more detail we recently figured out - we noticed that currently our crash reporter has a restriction built in our code that it's only able to properly process & upload crash logs if it's running with root access. Since we are getting these crash logs, it proves those processes have been launching as the root user, which seems to conflict with the fact that they are (at least supposed to be) registered as Launch Agent and should be running as the current logged in user? Again to me it still doesn't pinpoint the issue any further than our current speculation - it could still be a system bug/software bug/user tampering, but I thought to mention this new detail.

Watched and learned. Thanks The Eskimo, always a pleasure!

Thanks Jason, I posted a question there too. However, I wanted to say the reason I put it here (dev forum) was because our software has a VPN functionality and we are seeing this popup on Ventura and know it's gonna impact our customers' user experience. For a few reasons I also posted in the question on the Support website, I really suspect this is a Ventura bug. The popup isn't from a 3rd party VPN software, it's from an Apple process called "VPN" (/System/Library/ExtensionKit/Extensions/VPN.appex). The popup DOESN'T happen if I do not open System Settings > Network > VPN & Filters settings tab in the first place. For example, if I close the System Settings dialog, then no matter how I manipulate a VPN software, I won't see this prompt. The popup DOESN'T change anything either - no matter if I accept it or just cancel it, 3rd party software can still manage its VPN profile just fine. When we allowed the VPN software to create a VPN profile in the system in the first place, we already saw another system prompt asking for user consent to allow this app to monitor network traffic. Right now I'm very sure our software is not trying to do any modifications (not trying to create any new VPN profile), it's only trying to start or stop the VPN connection. It doesn't seem to be a very good user experience if I got a prompt out of blue every time when trying to connect or disconnect the VPN (even though the popup doesn't really block our functionality).

It's using the NEPacketTunnelProvider API, which creates a VPN profile in System Settings > Network. The first time when our app creates that profile, we see a prompt saying "App XYZ would like to filter network content. Allow/Don't Allow", but that's not what we are talking about here. Instead let's assume we've already allowed the profile to be created, and then what happens is that (1) when our code is operating on that profile, e.g. starting/stopping the VPN connection, or (2) the user is manually operating on that profile, we have a chance to see this new popup in question. And also it only happens if we currently have the System Settings > Network > VPN & Filters tab opened (again this is Ventura only).

Thanks The Eskimo! I've submitted FB11985759.

Sounds good thanks The Eskimo! FYI one of the use cases I can definitely think of is - some organizations may have SOE images with a user 501 like "soe_admin", who is responsible of pre-installing all software required. For our software, the installer can trivially register a login item or launch agent bound to the current user (501) using SMAppService via a postinstall script. However the actual device users will not be 501 so the login item or launch agent will not load properly for them unless they manually intervene (which we don't want because our software is largely silent/background). Our software also has a launch daemon, which is loaded cross-user properly. I thought of using the daemon helper to ensure the login item/launch agent is registered properly across different gui sessions - but alas the daemon runs under the system domain, so it cannot read or write the user/gui domain (from SMAppService's header file I understand this is by design). So unless we have the proper support of global login item/launch agent I think we'll be forced to detour. Feedback# is FB13137999, I've included the use case above in it as well.

Hi @eskimo a follow-up question here.. I fully understand that Apple doesn't want to divulge whether an enhancement request has been prioritized, or when it can be available. For now if our product decides that the capability of registering a global launch agent is important to us, that we'd like to keep doing the "launchctl" way, is that still accepted by Apple? I did notice a line on this page that says "In apps that target macOS 13 and later, your app needs to only use the property list locations outlined above" and my own interpretation was that if our app's minimum deployment target was marked as 13.0, then we absolutely had to switch over to the SMAppService interface. Did I misinterpret that? On the other hand, can we lower our app's minimum deployment target to macOS 12.0 to circumvent that restriction?