I have two privileged service(s) and a desktop app. The privileged services are packaged into /Library/*** and are run using launchd at runtime. The desktop app is just dropped into /Applications. The desktop app connects to one of the services (let's say service "B") via XPC. That is, B is running an XPC listener (using libxpc). Both applications are written in golang with xpc interaction via CGO. This is all working fine: The desktop app is receiving notifications over XPC from service B. However, during our build we dump the built and signed apps (before .pkg'ing) into a dist folder. When we run the app (using a makefile target), we copy the services from dist to another location as root, then execute the binaries directly. This is problematic for the desktop app, because my understanding is that XPC requires launchd to assert the namespace it's under. Thus, when service B is launched this way, it says "operation not permitted." We also want to reserve the ability to run a production version of our app on the same machine (drink our own champagne and all that), and I would like to avoid having development versions running on startup, so I don't want to use the same launch configurations. MacOS is one of three platforms we support (linux, windows as well). Our IPC implementation under MacOS uses XPC via golang build tags. Questions: Is it possible to start the XPC server without using launchd, or by using launchd but without registering it as an actual service? Is this a use case where using a unix domain socket would be better (albeit i feel like securing the socket between the privileged / unprivileged process would be ... fun). Additional / somewhat unrelated questions: is it possible for me to somehow restrict another process from chatting with service B over XPC (restrict to my other desktop app)? This is an app bundle question, so very unrelated: The service "app" that contains services A and B is in /Library, with the plist pointing to A, but B resides in Contents/MacOS next to A. Should this be split out into its own app bundle under Frameworks, or is this fine?

We have a MacOS application that we plan on distributing standalone (it'll be installed through MDM or directly, not through the app store). We utilize endpoint security and full disk access for this (enterprise) app. I have a makefile that uses codesign to sign the app inside-out. All that appears to work (i.e., when I try to run the app directly it functions as I expect it to). What's the recommended way to allow the developers in my team to also sign the app for local development so it functions as close as possible to production? My first thought is to distribute the developer identity to their machines using MDM. However, ideally i'd like to rule out the ability for a developer who has the MDM profile assigned to export the keys. That really only leaves a centralized solution in place or disabling SIP on their system (which I don't want to do). Alternatively, would creating a separate identity for production make more sense, so that in the case the developer certificate is revoked, the production releases continue to function as normal (however, I assume this would also require creating two different profiles for the endpoint security entitlement--one for each certificate). Thanks! Derek

Hello. I have a MacOS application to be distributed in a .pkg that is signed and notarized. For the application to work, it needs some settings defined by us (non-secret strings that differ per client). My thought has been to use a .mobileconfig to send these settings using the com.apple.ManagedClient.preferences PayloadType. I can see these settings land correctly into the /Library/Managed Preferences directory (in the correct domain) when distributed using Apple Business Essentials as the MDM. However, I cannot read the settings using NSUserDefaults OR CFPreferences in objective-c (i've tried with my app unsigned and signed, but not signed ant notarized so far). I've seen some posts here and there about managed preferences being deprecated, so I'm not sure if this is my issue or if i'm simply reading the preferences incorrectly. I'll admit the conflict of some of these posts has me a bit confused about how the preferences subsystem works / whether it should be used at all. I'm on MacOS 15.3. Two questions: Does anything stand out as to why I wouldn't be able to read these properties? Is there a better method I should be using to allow sending config via MDM to set application settings? Thanks in advance!