thank you!

Thank you! Could you please confirm if the installation of a Network Extension strictly required a GUI application and there is no other options without an MDM? (Note: I understand that without an MDM profile, the user will still be prompted to manually approve the system extension in System Preferences/Settings) Thank you for your help!

Thank you for the help! Our cross-platform DLP solution is deployed via a standard .pkg installer and must support macOS 11 and later. The installer sets up a LaunchAgent which is responsibe for system monitoring and launching container app (which bundles NE) when necessary. Once activated, the Network Extension communicates with independently deployed LaunchDaemon via XPC (https://developer.apple.com/forums/thread/820631). To avoid confusing users with unnecessary UI, this container app must run in the background without a Dock icon. Is it officially supported to configure the Network Extension's containing .app as a background-only application by setting LSUIElement = YES in its Info.plist? Is it supported for our independently deployed LaunchAgent to programmatically launch this background-only .app? (Note: I understand that without an MDM profile, the user will still be prompted to manually approve the system extension in System Preferences/Settings) Thanks!

Thank you for the advice! I'm working on a project where this daemon acts as an XPC service, and its main job is to analyze network data provided by a Network Extension. Unfortunately, writing meaningful unit tests for the actual data flow is quite problematic. I believe the best way to debug is the attach-to-process approach (using waitFor / WaitForDebugger). Thanks again for your help!

Thank you for the help!

thank you for the help!

Thank you for the detailed explanation! Regarding the order of transparent proxies: if the application is installed directly by the end-user (meaning it is unmanaged and not deployed via a device manager / MDM), is there any programmatic way to influence which proxy receives the flow first? If not, is the order strictly undefined (e.g., based on the order of installation or activation), and should we just architect our app assuming it could end up anywhere in the proxy chain. Thank you for the help!

Thanks a lot for the help! Since both the Launch Daemon and the Network Extension start at boot-time before user login, is there a guaranteed initialization order between them? Specifically, is one guaranteed to be fully bootstrapped before the other, or should I treat their startup as a race condition? Thank you again.

Thanks for the detailed explanation and tips! Could you please help with two architectural follow-up questions regarding the lifecycle and data flow: Boot-time execution and User Sessions: In Apple's examples, the Network Extension is initially installed and activated via a Container App running within a user session. However, the extension itself runs as root. Assuming the user has approved the extension and the configuration is saved, will macOS automatically bootstrap this Network Extension at boot-time (before any user logs in)? We need to ensure that our global launchd daemon and the Network Extension can establish this App Group-based XPC connection and start filtering traffic regardless of active user sessions. Confirming the IPC Roles: Given your suggestion to set the MachServices property in the launchd daemon, am I correct in assuming the recommended architecture is strictly: Launch Daemon = XPC Listener / Server (handling complex analysis) Network Extension = XPC Client (acting purely as a data provider pushing intercepted flows to the daemon) Is there ever a valid use case where these roles should be reversed in a system-wide filtering context, or is the Daemon-as-Listener the absolute standard here? Thanks a lot for your help!

thank you!

Thank you for response! Our IPC implementation is based on Boost.Asio, and I am encountering the sockaddr_un size limitation when using the user's home directory. I am considering using NSTemporaryDirectory() instead. Are there any guarantees the path returned by this function will always fit within the buffer sockaddr_un? Additionally, are there any other locations for IPC sockets that avoid this path length restriction? Thank you in advance!

Thank you a lot for the help!

thank you a lot for the help!

thank you a lot for the help!

thank you a lot for the response and tips!