Runloop.main.run() What behaviour did you see? Did that call return? Or did it just not deliver events? The application runs until I stop the Runloop, my function to add the Monitors for the Mouse events gets called with no errors but I don’t get the any of the events. If you nest your tool, or your background-only app, within a standard app then the system will likely consider that app to be responsible for your process and use it to prompt for, and track, your TCC privileges. I need to research this, it sounds like is what we need to do but I’m not sure if it can work with our existent code in cSharp. Thank you for your help.

Do you know if there is a way to start Appkit from within my swift dylib?

I can start NSApplication.shared like this: let delegate = AppDelegate(mController) NSApplication.shared.delegate = delegate NSApplication.shared.run() // _ = NSApplicationMain(CommandLine.argc, CommandLine.unsafeArgv) Note: I tried with NSApplicationMain but I get the error "No Info.plist file in application bundle or no NSPrincipalClass in the Info.plist file, exiting" even after creating a Info.plist file and adding the path to BuildSettings/Packaging/Infor.plist File/). That works, It keeps the process going until I terminate it, I get all NSEvents and I can use any NS library but this creates another problem now. My cSharp code is unable to call code living in my swift dylib which works if I don't call NSApplication.shared.run (I get no errors or anything). This is how it works. In my cSharp file [DllImport("libvmylibrary.dylib")] public static extern void myFunction(); main { myFunction(); } in my swift dylib @_cdecl("myFunction") public func myFunction() {} Then I just compile my cSharp code and then I run the .exe with mono. I need to be able to keep the dynamic library running so I can use AppKit but I also need to be able call my swiftDylib from my cSharp code.

After further testing, I see that NSApplication.shared.run() just blocks the main thread and that is why the rest of my function weren’t being called. But if trigger more functions after NSApp is running they do work. So from what we gave discussed is safe to say that: Anything related to Appkit will not work unless I have called NSApplication.shared.run() The best way to keep my app running in the background is with LSBackgroundOnly? I’m stuck here, it is an info plist value right? But how do I embed an Info.plist file into my dylib?

With regards your “cSharp program”, what type of program is this? An app that the user launches from the Finder? A command-line tool? Or something else? It is going to be a mono.exe, that is why we thought of making a dylib so it works with it. If you want to use AppKit’s event handling system you’ll need to create a background-only application. That requires: App-like packaging Starting up AppKit by calling NSApplicationMain on the main thread If I do that is there a way to expose methods so my mono app can call them? Or is there other way to access Appkits event handling?

Hello! Thank you for the prompt response. The resources provided and your explanation really helped me (I'm still reading through them to understand them better) but I do have some questions I would love your clarification on. The system will then start an instance of this (my NSApplication?) in each GUI login session Does this mean that I have access to libraries like NSEvent, AVFoundation and all the good that comes with NSApplication? I wonder this because my application currently saves the new recording file but it is empty for some reason? That can use IPC (preferably XPC) to connect to your daemon, tell it about the state of the GUI login session it’s loaded in, and also perform work on the daemon’s behalf. So is my agent or the demon going to be doing the work related to the ui? (getting screen frames, sevenths, etc). Muchas gracias again.

Thank you for confirming those thoughts. I have made good progress but now I find my self facing new ones and with some new hypothesis. When in the LoginView, I'm not able to capture the key strokes after the user clicks on the password textview. Which I'm assuming is a security measure? or am I doing something wrong?  From the comments before  In the specific case of the pre-login context, you’ll find that the agent is started as root when the login window context starts up and then, when the user logs in, that instance is terminated and a new one is started as that user.  Why is that my AppDelegate function "applicationWillTerminate" does not get called the root's instance for the LoginWindow is terminated to start a new one as the user? — gamakaze less than a minute ago

I'm back again! Thank you for your previous pointers, I have spent a good amount looking at the launchd.plist man page but I was not able to find anything about the life cycle. I did try other ways to keep it alive longer like queueDirectories but I was unsuccessful. Maybe it has something do with how I'm doin things so I'm going to elaborate more. Everything I'm trying to do is in a swift dylib that communicates with cSharp code (executable file) I run using the mono framework. Currently I start the process with terminal mono cSharp.exe that calls a function in my swift dylib that starts my NSApplication like this. let appDel = AppDelegate() let appStarter = AppStarter() @_cdecl("startNSApplication") public func startNSApplication() {     appStarter.startNSApplication(appDel) } //In my AppStarter class func startNSApplication(_ appDel: AppDelegate) {         NSApplication.shared.delegate = appDel         NSApplication.shared.run()  } The "Program Parameters in my LaunchAgent.plist is an executable file that just runs: mono cSharp.exe (with the right paths) This way I can record the LoginScreen (and when user is logged in) successfully when I manually close the app (through a button) because NSApplication.terminate gets called and it triggers "applicationWillTerminate" allowing me to properly shutdown things. So the issue I'm facing is that whenever the app is shutdown by the user loggin in or out, when the process get terminated through terminal, everything gets shut down suddenly and without calling NSApplication.shared.terminate. I have read about the key in the Info.plist <key>NSSupportsSuddenTermination</key> <true/> but that leads me to my next question. How could I add an info plist to my swift.dylib? I assume the answer to that is to put it in an .app file but where exactly do I need to put it so the OS finds it when the application is opened? Sorry for the super long comment but I figured I would get more help by providing more info.

Hola de nuevo! Following up on getting the keyboard events from the password textfield in the LoginView. In my LaunchAgentApp: "IsSecureInputEventEnabled" during LoginView always returns false but the documentation in the Carbon.HIToolboox.CarbonEventCore states: This API returns whether secure event input is enabled by any process, not just the current process. Secure event input may be disabled in the current process but enabled in some other process; in that case, this API will return true. Shouldn't it return "true" since the password textfield has enabled SecureEventInput? "EnableSecureEventInput" gives me a "noErr" OSStatus and it effectively stops me from receiving the keyboard events even outside the password textfield, and "DisableSecureEventInput" gives a -50 error. Which is "paramErr" I believe this is because "IsSecureEventInputEnabled" is false? After trying things out it seems that the password textfield in the LoginView is of type "NSSecureTextField" and that it is the password textview who enables the "SecureInputEvent" on itself? If so, only the textField itself can call DisableSecureInputEvent on itself? is there a way to access the textField in the LoginView to disable it? or am I completely off track here? lol

**NOTE: I feel like I need to add more context so the question is easier to answer. My end goal is that once the user "turns on" the app it will be opened during and after login, that's where I need my prelogin agent. But also when the user "turns off" the app I need it to stop getting launched which is when I need to remove my prelogin agent in order to prevent this.

Did you ever figured this out? I'm running into the same issue. I'm able to capture the screen during LoginWindow but CGEvents for mouse and keyboard aren't working.

Thank you for the prompt response! I have some more questions if you don't mind. The agent is instantiated for each relevant session — remember that you can have multiple GUI login sessions running simultaneously — and each instance connects to the daemon via an IPC mechanism of your choice (although I generally recommend XPC) and do work on behalf of the daemon in each GUI context. Does this mean that in general my application should be done in two parts, and xpc service that deals with the networking, that can run without interruption in any session (login and logged in user), and then my NSApplication to deal with the very little UI I need and to capture user screen and other input? The standard pattern is have a launchd daemon that manages the network connection and then have a launchd agent that’s set up to both pre-login (LoginWindow) and GUI login (Aqua) sessions. As I mentioned before, it is a remote control application I'm working on and this is how I understand the standard patter would work. my daemon: It would be launched and kept alive through any session (LoginWindow and when user is logged in) it would be in charge of my networking code, connecting to my client and receiving input from the client may agent one for LoginWindow and one when the user is launched. takes care of the NSMenu my application represent it captures all the screen, user input and sends it to my daemon which will then send it to the client. Right now my application works and it is all contained within the same project, but it sounds like it would be better to split it and have a xpc service and a agent? this way The XPC Service can run and maintain connection with the client "non stop"?

Running on latest Monterey version

Hello Eskimo! I have a few more questions. I was looking for some steps or more info on how everything would work, mainly the LaunchDaemon. This is how I understand things as of right now. LaunchDaemon - daemon for managing the network and centralised command and control. It is a remote control application so this means that the daemon will not get shut down and I can keep the connection to my client alive when moving from login to user context? LaunchDaemon - launches service in and stays alive when going from login context to user context? Once in user context, daemon can launch the app to provide ui to configure the service. I was trying to start my service executable through my plist saved in LaunchDaemons (same plist as when I was starting the app from LanchAgents) but that does not work. Is there any specific requirements for the service executable? My end goal is to provide a smooth transition when going from login to user context, which means not shutting down my service in order to maintain the connection with my client.

Thank you for clarifying that, it makes sense now. As far as the launch daemon, I need it to run the code that connects to my client so I’m assuming this would be by compiling my code into an executable? If so, how would I go about embedding the libraries I need into the executable? This is probably a whole different topic but any pointers would be greatly appreciated.